nginx not built as Position Independent; does not use BIND_NOW

Thomas, since the fix is trivial and the benefit would be very welcome, would it be possible to do SRU this?

Simon:

This is currently marked as "Fix Committed" in Debian - that doesn't mean that this is "Fixed" up there yet, and that it's only in the git repo for it.

It also isn't fixed in Vivid. To SRU this, the commit from Debian would need to be put into Vivid, and possibly Utopic before it could end up in Trusty. Vivid is currently under feature freeze, I'd need to check with the release team to see if this would get past the freeze (although I doubt it will get in past the freeze). And since this fix isn't even in Debian I'm not sure this qualifies for an SRU right now.

Thanks for the clarifications. Please know that I'll be available to test any new build that would reach Vivid or any older versions.

After additional discussion with the server team and members of the security team, we do not believe that this qualifies as an SRU. It does not provide any significant benefit other than hardening, and does not qualify for SRU.

As such, I am setting "Won't Fix" in Precise through Utopic, but leaving Vivid alone for now. Here's some additional considerations for Vivid (and also earlier stable releases), brought up during that discussion:
* Turning on PIE in stable releases will have a detrimental performance impact on 32-bit platforms (and will likely annoy people who are using nginx on 32-bit platforms for its performance.
* While "PIE isn't turned on though expected for security-sensitive packages" would possibly be a valid reason to get a change into Vivid during the current freeze, the performance impact on 32-bit platforms would make this a possible blocking point.

It is possible/likely that Vivid+1 will have this fixed there, as Debian has 'committed' a fix that may likely be available by that time (and merged in at some point in the Vivid+1 cycle).

Why bother having nginx in main? It should have been hardened as a blocking bug when the MIR was originally put out (https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710) .

Is it even meaningful to compare the speed of apache with nginx if one is build with pie and one is not? I respect that this could represent a performance regression for precise but this really should go into vivid, vivid + 1 and 16.04 LTS.

Sindhudweep: We were not comparing Apache and NGINX speeds. With PIE, on a 32bit platform there si at least a 15% performance decrease (based on general observation between platforms with PIE enabled/disabled).

We're working on this for Vivid right now, have patience.

Additional related bugs in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781703 - nginx not using BIND_NOW security feature

Immediate binding as well as Position Independent building are both enabled with the fix that is committed right now. (Bug summary expanded to include the BIND_NOW security feature).

With regard to the Debian bug, the Debian bug linked to this bug, as well as the additional related bug linked in this comment, are both fixed by a commit now included in Debian git.

This bug was fixed in the package nginx - 1.6.2-5ubuntu3

---------------
nginx (1.6.2-5ubuntu3) vivid-proposed; urgency=medium

  * debian/rules:
    * Reversed Debian change in 1.6.2-5ubuntu2.
    * Added DEB_BUILD_MAINT_OPTIONS=hardening=+all to enable all
      dpkg-buildflags to harden the code, except for PIE flags.
    * Manually define DEB_BUILD_MAINT_OPTIONS in DEBIAN_NGINX_PERL_LDFLAGS
      to not have -fPIE conflicts in Perl flags.
 -- Thomas Ward <email address hidden> Wed, 01 Apr 2015 14:57:34 -0400

Thomas, would you consider a SRU to Trusty now? If yes, I could work on providing a debdiff if you'd like. Thanks in advance

Simon:

Please reread comment #4 here - https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1315426/comments/4

The decision on SRU stands because of the reasons stated there, with agreement from the Server and Security teams to that effect. We will not be SRUing these changes, because the agreement is that they don't bring any significant additional improvements (nor does it fix any real bugs which would impact security status of the package in older releases).