Exception request: major version bump for Nginx

[Jamie Nguyen]

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/[e-mail].o...

Kind regards,
Jamie

[Stephen John Smoogen]

On Jan 29, 2016 14:52, "Jamie Nguyen" <j(a)jamielinux.com&gt; 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:
>  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/[e-mail].o...
>  Kind regards,
>  Jamie
>  _______________________________________________
>  epel-devel mailing list
>  epel-devel(a)lists.fedoraproject.org
>  
http://lists.fedoraproject.org/admin/lists/[e-mail]...

[Jamie Nguyen]

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

[Peter Robinson]

> > 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

[Ken Dreyer]

On Fri, Jan 29, 2016 at 6:51 AM, Jamie Nguyen <j(a)jamielinux.com&gt; 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

[Stephen John Smoogen]

On 29 January 2016 at 06:51, Jamie Nguyen <j(a)jamielinux.com&gt; 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:
>  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? 
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.



-- 
Stephen J Smoogen.

[Jamie Nguyen]

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

[Jamie Nguyen]

On 24/02/16 23:36, Stephen John Smoogen wrote:
>  On 29 January 2016 at 06:51, Jamie Nguyen <j(a)jamielinux.com&gt;
> wrote:
> > 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?
>  
>  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,

-- 
Jamie Nguyen

[Anssi Johansson]

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(a)jamielinux.com&gt; wrote:
> >> 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?
> >
> > 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? 
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.

[Jamie Nguyen]

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,

-- 
Jamie Nguyen

[Anssi Johansson]

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.