Hi,
A few days ago, three CVEs for Nginx and were fixed in 1.8.1. Upstream only maintain 1.8.x and above, so they didn't release any fixes for older versions of Nginx. I was able to backport the relevant commits to Nginx 1.6.x on EL7.
Unfortunately, Nginx 1.0.x on EL6 is too old; I gave it a good shot but backporting the patches reliably without creating new CVEs is beyond my expertise. Nginx 0.8.x on EL5 is prehistoric.
This leaves the package in a bit of a pickle. Leaving things as they are would leave web servers vulnerable. On the other hand, updating Nginx to 1.8.x on EL5/6/7 will inevitably break something for someone (eg, via yum-cron). I had a small discussion on fedora-devel ML about the situation [0], and the consensus was to request for an exception.
My plan: 1. Update to 1.8.x on all branches (or to as recent a version as they can go without FTBFS) 2. Leave them in epel-testing for a prolonged period, probably until the next point release of RHEL. 3. Include some migration notes with the RPMs, and also post these notes to epel-devel/epel-announce.
Sound reasonable?
[0]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Kind regards, Jamie
On Jan 29, 2016 14:52, "Jamie Nguyen" j@jamielinux.com wrote:
Hi,
A few days ago, three CVEs for Nginx and were fixed in 1.8.1. Upstream only maintain 1.8.x and above, so they didn't release any fixes for older versions of Nginx. I was able to backport the relevant commits to Nginx 1.6.x on EL7.
Thank-you for your request. I think that this is a good candidate for a break in all three channels. I will try to get enough EPSco people to look at this and give feedback while we are at FOSDEM. Hope to have a +1 for you soon
Unfortunately, Nginx 1.0.x on EL6 is too old; I gave it a good shot but backporting the patches reliably without creating new CVEs is beyond my expertise. Nginx 0.8.x on EL5 is prehistoric.
This leaves the package in a bit of a pickle. Leaving things as they are would leave web servers vulnerable. On the other hand, updating Nginx to 1.8.x on EL5/6/7 will inevitably break something for someone (eg, via yum-cron). I had a small discussion on fedora-devel ML about the situation [0], and the consensus was to request for an exception.
My plan:
- Update to 1.8.x on all branches (or to as recent a version as they
can go without FTBFS) 2. Leave them in epel-testing for a prolonged period, probably until the next point release of RHEL. 3. Include some migration notes with the RPMs, and also post these notes to epel-devel/epel-announce.
Sound reasonable?
[0]:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Kind regards, Jamie _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.or...
On 29/01/16 14:56, Stephen John Smoogen wrote:
Thank-you for your request. I think that this is a good candidate for a break in all three channels. I will try to get enough EPSco people to look at this and give feedback while we are at FOSDEM. Hope to have a +1 for you soon
Awesome. Thanks!
Kind regards, Jamie
A few days ago, three CVEs for Nginx and were fixed in 1.8.1. Upstream only maintain 1.8.x and above, so they didn't release any fixes for older versions of Nginx. I was able to backport the relevant commits to Nginx 1.6.x on EL7.
Thank-you for your request. I think that this is a good candidate for a break in all three channels. I will try to get enough EPSco people to look at this and give feedback while we are at FOSDEM. Hope to have a +1 for you soon
So for at least EL7 there's going be some fairly regular and consistent rebasing of a number of components to newer versions so it might be that some long running LTS versions might not build or work with newer rebased libraries. I'm thinking of desktop and other related stuff here, and probably some stuff around crypto. In short we might want to put together a policy for at least EL7 for rebases that covers the rebase of components for support of newer underlying components.
Peter
On Fri, Jan 29, 2016 at 6:51 AM, Jamie Nguyen j@jamielinux.com wrote:
Sound reasonable?
As an EPEL nginx user, thanks for looking into this, and you have my +1 for updating to a new secure version.
- Ken
On 29 January 2016 at 06:51, Jamie Nguyen j@jamielinux.com wrote:
Hi,
A few days ago, three CVEs for Nginx and were fixed in 1.8.1. Upstream only maintain 1.8.x and above, so they didn't release any fixes for older versions of Nginx. I was able to backport the relevant commits to Nginx 1.6.x on EL7.
Unfortunately, Nginx 1.0.x on EL6 is too old; I gave it a good shot but backporting the patches reliably without creating new CVEs is beyond my expertise. Nginx 0.8.x on EL5 is prehistoric.
This leaves the package in a bit of a pickle. Leaving things as they are would leave web servers vulnerable. On the other hand, updating Nginx to 1.8.x on EL5/6/7 will inevitably break something for someone (eg, via yum-cron). I had a small discussion on fedora-devel ML about the situation [0], and the consensus was to request for an exception.
My plan:
- Update to 1.8.x on all branches (or to as recent a version as they
can go without FTBFS) 2. Leave them in epel-testing for a prolonged period, probably until the next point release of RHEL. 3. Include some migration notes with the RPMs, and also post these notes to epel-devel/epel-announce.
Sound reasonable?
And it looks like I missed sending a final response on this. We talked about this at the EPEL Steering Committee meeting and approve of this plan. Please update to 1.8 (if you haven't already) and follow through.
On 24/02/16 23:36, Stephen John Smoogen wrote:
And it looks like I missed sending a final response on this. We talked about this at the EPEL Steering Committee meeting and approve of this plan. Please update to 1.8 (if you haven't already) and follow through.
Excellent. Thank you very much!
Kind regards, Jamie
On 24/02/16 23:36, Stephen John Smoogen wrote:
On 29 January 2016 at 06:51, Jamie Nguyen j@jamielinux.com wrote:
My plan:
- Update to 1.8.x on all branches (or to as recent a version as they
can go without FTBFS) 2. Leave them in epel-testing for a prolonged period, probably until the next point release of RHEL. 3. Include some migration notes with the RPMs, and also post these notes to epel-devel/epel-announce.
Sound reasonable?
And it looks like I missed sending a final response on this. We talked about this at the EPEL Steering Committee meeting and approve of this plan. Please update to 1.8 (if you haven't already) and follow through.
I ended up delaying this major version bump. The discussion happened at the end of February, but I realized that a new Nginx release is normally cut around April so figured it'd be better to wait until 1.10.x was released (which was yesterday).
My plan now is the same as before, but to jump to 1.10.x instead for the following reasons:
1. 1.8.x is now considered "legacy" by upstream.
2. 1.8.x only has support for SPDY and *not* HTTP/2. SPDY is scheduled to be dropped by Chrome in a few weeks (and probably other modern browsers too).
3. Upgrading straight to 1.10.x (from 1.6.x or 1.0.x or 0.8.x) doesn't pose any significantly worse problems than upgrading to 1.8.x (as manual intervention from the admin will be required in most cases anyway). I don't think there's any need for an intermediate step where we upgrade to 1.8.x first, and that would likely be more disruptive anyway.
Does this sound reasonable?
Kind regards,
27.4.2016, 14.23, Jamie Nguyen kirjoitti:
On 24/02/16 23:36, Stephen John Smoogen wrote:
On 29 January 2016 at 06:51, Jamie Nguyen j@jamielinux.com wrote:
My plan:
- Update to 1.8.x on all branches (or to as recent a version as they
can go without FTBFS) 2. Leave them in epel-testing for a prolonged period, probably until the next point release of RHEL. 3. Include some migration notes with the RPMs, and also post these notes to epel-devel/epel-announce.
Sound reasonable?
And it looks like I missed sending a final response on this. We talked about this at the EPEL Steering Committee meeting and approve of this plan. Please update to 1.8 (if you haven't already) and follow through.
I ended up delaying this major version bump. The discussion happened at the end of February, but I realized that a new Nginx release is normally cut around April so figured it'd be better to wait until 1.10.x was released (which was yesterday).
My plan now is the same as before, but to jump to 1.10.x instead for the following reasons:
1.8.x is now considered "legacy" by upstream.
1.8.x only has support for SPDY and *not* HTTP/2. SPDY is scheduled
to be dropped by Chrome in a few weeks (and probably other modern browsers too).
- Upgrading straight to 1.10.x (from 1.6.x or 1.0.x or 0.8.x) doesn't
pose any significantly worse problems than upgrading to 1.8.x (as manual intervention from the admin will be required in most cases anyway). I don't think there's any need for an intermediate step where we upgrade to 1.8.x first, and that would likely be more disruptive anyway.
Does this sound reasonable?
This change to the plans was discussed briefly in yesterday's EPEL Steering Committee meeting, and we're OK with updating straight to 1.10.x.
I believe there are a number of people who are interested in HTTP/2 support, so please do go on with this plan.
On 28/04/16 06:28, Anssi Johansson wrote:
This change to the plans was discussed briefly in yesterday's EPEL Steering Committee meeting, and we're OK with updating straight to 1.10.x.
I believe there are a number of people who are interested in HTTP/2 support, so please do go on with this plan.
Excellent, thanks.
Kind regards,
28.4.2016, 10.03, Jamie Nguyen kirjoitti:
On 28/04/16 06:28, Anssi Johansson wrote:
This change to the plans was discussed briefly in yesterday's EPEL Steering Committee meeting, and we're OK with updating straight to 1.10.x.
I believe there are a number of people who are interested in HTTP/2 support, so please do go on with this plan.
Excellent, thanks.
As a heads up, you may run into issues with missing ALPN support in OpenSSL. Some pointers:
https://bugzilla.redhat.com/show_bug.cgi?id=1276310#c6 https://forum.nginx.org/read.php?2,261880,261880#msg-261880 https://bugzilla.redhat.com/show_bug.cgi?id=1327548 https://access.redhat.com/solutions/2111901 (paywalled, no idea)
This may require an update to OpenSSL from RH.
epel-devel@lists.fedoraproject.org
-
Anssi Johansson -
Jamie Nguyen -
Ken Dreyer -
Peter Robinson -
Stephen John Smoogen