Hi,
Distributions like RHEL and Debian have a very strict update policy (for good reason). People expect stability and don't want surprises.
When CVEs arise, patches can often be backported. Nginx 1.8.1 recently fixed three CVEs and I've backported 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.
I've had a couple of bug reports recently suggesting that I rebase Nginx to 1.8.1 on all branches. On the one hand, I want to avoid causing surprises and breaking somebody's website. On the other hand, these vulnerabilities do need to be fixed. (The approach I took with the Tor package is to always use the latest stable release on all branches, which is working well.)
What do people think? Should I go ahead and update all branches (with appropriate migration notes)?
Kind regards, Jamie
On Thu, Jan 28, 2016 at 5:03 AM, Jamie Nguyen j@jamielinux.com wrote:
Hi,
Distributions like RHEL and Debian have a very strict update policy (for good reason). People expect stability and don't want surprises.
When CVEs arise, patches can often be backported. Nginx 1.8.1 recently fixed three CVEs and I've backported 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.
I've had a couple of bug reports recently suggesting that I rebase Nginx to 1.8.1 on all branches. On the one hand, I want to avoid causing surprises and breaking somebody's website. On the other hand, these vulnerabilities do need to be fixed. (The approach I took with the Tor package is to always use the latest stable release on all branches, which is working well.)
What do people think? Should I go ahead and update all branches (with appropriate migration notes)?
Kind regards, Jamie
I personally think you should. EPEL isn't supposed to unreasonably hold back when even the upstream project no longer maintains that version. As long as all consumers of the nginx package are appropriately updated (if necessary) and the transition notes are documented, I don't see why not. However, the problem really comes in with how to do get people to read the upgrade notes, as that's pretty much the only way to make that work.
On 28/01/16 10:10, Neal Gompa wrote:
I personally think you should. EPEL isn't supposed to unreasonably hold back when even the upstream project no longer maintains that version. As long as all consumers of the nginx package are appropriately updated (if necessary) and the transition notes are documented, I don't see why not. However, the problem really comes in with how to do get people to read the upgrade notes, as that's pretty much the only way to make that work.
There isn't any way to ensure users read upgrade notes, except between new versions of Fedora/RHEL (as major changes would be expected). This will inevitably bite someone when their Nginx configuration isn't valid after the update, which could for example be via yum-cron.
Kind regards, Jamie
On Thu, Jan 28, 2016 at 8:46 AM, Jamie Nguyen j@jamielinux.com wrote:
There isn't any way to ensure users read upgrade notes, except between new versions of Fedora/RHEL (as major changes would be expected). This will inevitably bite someone when their Nginx configuration isn't valid after the update, which could for example be via yum-cron.
That unfortunately is true (even in the case new versions); however whether or not someone reads or doesn't isn't your problem. You're trying to fix a security vulnerability (kudos to you). If doing so creates fallout, so be it. Better someone has to go in and make modifications to get it working than for their system to be compromised by a security issue.
On Thu, 28 Jan 2016 10:03:08 +0000 Jamie Nguyen j@jamielinux.com wrote:
Hi,
Distributions like RHEL and Debian have a very strict update policy (for good reason). People expect stability and don't want surprises.
When CVEs arise, patches can often be backported. Nginx 1.8.1 recently fixed three CVEs and I've backported 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.
I've had a couple of bug reports recently suggesting that I rebase Nginx to 1.8.1 on all branches. On the one hand, I want to avoid causing surprises and breaking somebody's website. On the other hand, these vulnerabilities do need to be fixed. (The approach I took with the Tor package is to always use the latest stable release on all branches, which is working well.)
What do people think? Should I go ahead and update all branches (with appropriate migration notes)?
Well, this kind of question would probibly be better on the epel-devel list, but otherwise:
https://fedoraproject.org/wiki/EPEL_Updates_Policy
And you can ask for an exception. This would entail pushing the new version to testing and leaving it there a while, mailing epel-announce to note that there's an incompatible version in testing and please test and then another note before you push it stable to give them a heads up. You may want to wait and push it stable at the same time as the next .X release comes out.
kevin
On Thu, 2016-01-28 at 12:00 -0700, Kevin Fenzi wrote:
On Thu, 28 Jan 2016 10:03:08 +0000 Jamie Nguyen j@jamielinux.com wrote:
Hi,
Distributions like RHEL and Debian have a very strict update policy (for good reason). People expect stability and don't want surprises.
When CVEs arise, patches can often be backported. Nginx 1.8.1 recently fixed three CVEs and I've backported 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.
I've had a couple of bug reports recently suggesting that I rebase Nginx to 1.8.1 on all branches. On the one hand, I want to avoid causing surprises and breaking somebody's website. On the other hand, these vulnerabilities do need to be fixed. (The approach I took with the Tor package is to always use the latest stable release on all branches, which is working well.)
What do people think? Should I go ahead and update all branches (with appropriate migration notes)?
Well, this kind of question would probibly be better on the epel-devel list, but otherwise:
https://fedoraproject.org/wiki/EPEL_Updates_Policy
And you can ask for an exception. This would entail pushing the new version to testing and leaving it there a while, mailing epel-announce to note that there's an incompatible version in testing and please test and then another note before you push it stable to give them a heads up. You may want to wait and push it stable at the same time as the next .X release comes out.
FWIW, I think that policy could do with less central oversight and more maintainer responsibility.
I don't think it's at all reasonable to expect the typical Fedora maintainer to be capable of backporting security fixes to releases which are unmaintained upstream. I think it would be absolutely a better policy to give maintainers freedom to bump to a new release series when the current release series becomes unmaintained upstream, with some guidelines and pointers on a responsible way to manage this process.
Red Hat can pay dozens of engineers lots of money to work full time on maintaining code that upstream has abandoned, Fedora/EPEL cannot.
On Thu, 28 Jan 2016 11:08:45 -0800 Adam Williamson adamwill@fedoraproject.org wrote:
Well, this kind of question would probibly be better on the epel-devel list, but otherwise:
https://fedoraproject.org/wiki/EPEL_Updates_Policy
And you can ask for an exception. This would entail pushing the new version to testing and leaving it there a while, mailing epel-announce to note that there's an incompatible version in testing and please test and then another note before you push it stable to give them a heads up. You may want to wait and push it stable at the same time as the next .X release comes out.
FWIW, I think that policy could do with less central oversight and more maintainer responsibility.
Well, FWIW, I don't think there is much central oversight really. People make their case to the list and unless someone says "Oh no, you didn't think of X" people go ahead with the exception. I guess the page could make it more clear that it's not some high overhead process.
I don't think it's at all reasonable to expect the typical Fedora maintainer to be capable of backporting security fixes to releases which are unmaintained upstream. I think it would be absolutely a better policy to give maintainers freedom to bump to a new release series when the current release series becomes unmaintained upstream, with some guidelines and pointers on a responsible way to manage this process.
Well, it kinda of depends on the package(s) in question...
Red Hat can pay dozens of engineers lots of money to work full time on maintaining code that upstream has abandoned, Fedora/EPEL cannot.
Sure.
Anyhow, if you want to discuss epel policy please do post to the epel-devel list and/or bring it up at the weekly epel meeting (wed at 19UTC in #fedora-meeting).
kevin
On Thu, Jan 28, 2016 at 11:08 AM, Adam Williamson < adamwill@fedoraproject.org> wrote:
I think it would be absolutely a better policy to give maintainers freedom to bump to a new release series when the current release series becomes unmaintained upstream, with some guidelines and pointers on a responsible way to manage this process.
I don't necessarily have an issue with the update policy... I think there is an expectation that EPEL would be more restricted in that regard - and it does have an exception for security purposes. Kevin gave excellent direction here; referencing the overhead that's required for maintaining an EPEL package. That said, some people wouldn't want to deal with it - regardless of their level of expertise. That is completely understandable, and isn't a bad thing. You can maintain a package for Fedora and choose not to package for EPEL.
On 28/01/16 19:00, Kevin Fenzi wrote:
Well, this kind of question would probibly be better on the epel-devel list
Ah, I forgot about epel-devel.
And you can ask for an exception. This would entail pushing the new version to testing and leaving it there a while, mailing epel-announce to note that there's an incompatible version in testing and please test and then another note before you push it stable to give them a heads up. You may want to wait and push it stable at the same time as the next .X release comes out.
This sounds like a reasonable plan. It will be a big change for EL6, and a spectacularly big change for EL5 (jumping forward 5 major versions, assuming it will even compile), so a very prolonged period in epel-testing will be essential.
Kind regards, Jamie
-
Adam Williamson -
Gerald B. Cox -
Jamie Nguyen -
Kevin Fenzi -
Neal Gompa