Comment 14 for bug 1262710

Seth,

Lua module upstream has outright said 5.2 isn't supported, I poked around there for the Lua module and they said so.

I'm researching alternatives.

------
Thomas

*Sent from my iPhone. Please excuse any typos, as they are likely to happen by accident.*

> On Mar 5, 2014, at 14:44, Seth Arnold <email address hidden> wrote:
>
> Sarah, thanks for the reminder; I had my one remaining outstanding
> question answered to my satisfaction: http://mailman.nginx.org/pipermail
> /nginx-devel/2014-February/005038.html -- in short, I hadn't realized
> X509_NAME_oneline() would escape the ascii NUL character when converting
> from ASN.1 to a C-representable string.
>
> We're currently stuck because the Debian-derived packaging includes an
> out-of-tree module that builds against lua-5.1. It cannot compile
> against lua-5.2 (the lua-5.2 changes are drastically not backwards
> compatible with lua-5.1), but lua-5.2 is the lua package that is going
> to be supported in Ubuntu trusty tahr.
>
> If it were up to me alone, I'd disable the lua module. Lua 5.2 has been
> out for over two years and if this module hasn't updated yet, there's no
> reason for me to suspect they will update before we need to release
> 14.04.
>
> Thanks
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1262710
>
> Title:
> [MIR] nginx
>
> Status in “nginx” package in Ubuntu:
> Confirmed
>
> Bug description:
> Availability:
>
> nginx is built and available on all current architectures in Trusty
> (I'm not considering ppc64el "current" yet).
>
> Rationale:
>
> nginx is increasingly relevant to the Web 2.0 crowd, who are key users
> of Ubuntu Server. apache2 exists and we want to keep it in main also,
> there seems to be a split in userbase between those who use Apache
> (traditional) and those who use nginx (newer stacks). nginx seems to
> have gained a reputation for being fast and lightweight. This may or
> may not be true when compared against Apache, but many stacks today
> are deployed on nginx, and we are hearing that this is what users want
> and are running today. Therefore, we should have nginx in main to keep
> Ubuntu Server relevant to these users.
>
> Security:
>
> nginx supplies a public-facing daemon and listens on a privileged
> port, so needs a more in-depth security review. I hear that nginx was
> previously declined in main due to security concerns, but have been
> unable to find a previous MIR. I understand that the security team are
> prepared to re-review and determine how nginx's security status may
> have changed if I file this new MIR to track such a review.
>
> This list of CVEs is not comprehensive; nginx has an extensive
> security history and this MIR requires an detailed security review.
>
> A recently discovered vulnerability was CVE-2013-4547. This was
> addressed in Debian within a couple of days (http://bugs.debian.org
> /cgi-bin/bugreport.cgi?bug=730012) and Thomas Ward took care of it in
> Ubuntu (https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1253691).
>
> Other oustanding CVEs:
> * CVE-2011-4968: this is a security-related missing feature, rather than a vulnerability per se. It's certainly debatable. It can only sensibly be addressed upstream. Debian don't deem it necessary to fix; I don't think Ubuntu needs to either.
> * CVE-2013-0337: in progress in Debian for the upgrade path.
> * CVE-2013-2070: Debian status in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708164; doesn't affect Trusty.
>
> Stronger SSL configuration by default: pending testing and upload in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730142
>
> Quality assurance:The Debian maintainers appear active and responsive
> to bug reports. Thomas Ward has been active watching the Ubuntu
> package, cherry-picking fixes from Debian, keeping an eye on security
> fixes and generally keeping the nginx package in Ubuntu up-to-date. If
> nginx enters main, then Thomas has said that he'll continue to look
> after the package as best he can, and the rest of the Ubuntu Server
> Team has committed to back him up where necessary.
>
> Some non-standard packaging behaviour that is not mandated otherwise by policy:
> * The service doesn't start automatically when the nginx package is first installed; you must use "sudo service nginx start" the first time. But the service does automatically restart on upgrade, etc, if the daemon was already running. invoke-rc.d is used correctly. This packaging behaviour appears to be intentional.
> * /var/www is not the default document root, nor /var/www/html (the proposed new standard). Instead, it is/usr/share/nginx/html. Active debate at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730382. It appears that nginx maintainers are keen to follow Debian policy, but it is not specific enough and the apache2 maintainers are following a different interpretation. This means that the package isn't immediately usable on first install as a static web server; instead of placing files directly into the default document root and have them served, the FHS-compliant sysadmin must reconfigure the daemon to use a default document root first.
>
> Apart from this, the package works straight away as a typical nginx
> user would expect.
>
> No debconf templates. No major long-term outstanding bugs. As a
> popular package there are a number of long-term outstanding bugs, but
> these all appear to relate to edge case behaviours or feature requests
> that do not affect the majority of nginx users.
>
> nginx appears active both upstream and in Debian and appears to be
> maintained well, with regular uploads in Debian over 2013, including
> wheezy security updates. A debian/watch file exists, appears
> functional, and the latest upstream version is packaged. There does
> not appear to be a relevant upstream test suite.
>
> -dbg packages exist. Question: do these need ddeb generation for
> Ubuntu instead? What is our policy here?
>
> UI standards: N/A for this server package
>
> Dependencies:
>
> * Build-Depends: liblua5.1-dev is only fulfilled by universe. Removing this will clearly drop lua support, but nginx will still work fine. Can lua support be dropped from nginx without disproportionate impact to users?
> * The nginx-naxsi-ui binary package depends on daemon, which is in universe, but nothing depends, recommends or suggests nginx-naxsi-ui. Can nginx-naxsi-ui be kept in universe, with the other components in main?
>
> FHS compliance: the packaging appears FHS compliant. Debian policy
> compliance: nginx claims compliance to 3.9.4; current policy is 3.9.5.
> The packaging uses traditional debhelper and appears do be done in a
> straightforward way; though necessarily a little more complicated than
> usual due to the multiple binary packages with different build
> configurations, as might be expected with this sort of package.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715435 appears to
> state that nginx-naxsi-ui doesn't work, and that this is a serious
> policy violation. This package doesn't fit our rationale to be in
> main., and has the daemon dependency that is in universe as described
> above. Can nginx-naxsi-ui remain in universe?
>
> ~ubuntu-server will commit to monitor and maintain nginx in main, with
> the help of Thomas Ward.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/+subscriptions