4:03 a.m.
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
4:10 a.m.
On Thu, Jan 28, 2016 at 5:03 AM, Jamie Nguyen <j(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
10:46 a.m.
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
12:25 p.m.
On Thu, Jan 28, 2016 at 8:46 AM, Jamie Nguyen <j(a)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.
1 p.m.
On Thu, 28 Jan 2016 10:03:08 +0000
Jamie Nguyen <j(a)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
1:08 p.m.
On Thu, 2016-01-28 at 12:00 -0700, Kevin Fenzi wrote:
On Thu, 28 Jan 2016 10:03:08 +0000
Jamie Nguyen <j(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:16 p.m.
On Thu, 28 Jan 2016 11:08:45 -0800
Adam Williamson <adamwill(a)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
1:35 p.m.
On Thu, Jan 28, 2016 at 11:08 AM, Adam Williamson <
adamwill(a)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.
2:01 p.m.
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
3010
days inactive
3010
days old
8 comments
5 participants
participants (5)
-
Adam Williamson -
Gerald B. Cox -
Jamie Nguyen -
Kevin Fenzi -
Neal Gompa