Hi,
I have built an updated glibc package for Fedora 21, with (alleged) fixes for the following security issues: * CVE-2015-7547 (CRITICAL) * CVE-2015-1781 * CVE-2015-8777 * glibc PR17269 * glibc PR18032 backported from Fedora 22 or forward-ported from CentOS 7. (To the best of my knowledge, the patches I backported do indeed address the above issues, but I cannot provide any kind of guarantees for that.)
You can find it in the following repository: https://repos.fedorapeople.org/kkofler/f21-security/ (I had to use the old repos.fedorapeople.org infrastructure because the Copr maintainers "helpfully" deleted the Fedora 21 buildroots, making Copr entirely useless for the purpose of building security updates for distributions Fedora no longer provides them for. I consider this a very bad idea and an absolutely counterproductive practice.)
As specified in the .repo file, the packages are signed with my CalcForge GPG key, available over HTTPS (with a valid certificate from Let's Encrypt): https://www.calcforge.org/RPM-GPG-KEY-calcforge
This repository is provided "AS IS", in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. In particular, NO warrants of any kind are made for completeness of security fix coverage.
Currently, glibc is the ONLY package that has an update available in the above repository.
Kevin Kofler
Why do you want to build such packages for EOLed distro?
On Fri, Feb 19, 2016, 3:36 AM Kevin Kofler kevin.kofler@chello.at wrote:
Hi,
I have built an updated glibc package for Fedora 21, with (alleged) fixes for the following security issues:
- CVE-2015-7547 (CRITICAL)
- CVE-2015-1781
- CVE-2015-8777
- glibc PR17269
- glibc PR18032
backported from Fedora 22 or forward-ported from CentOS 7. (To the best of my knowledge, the patches I backported do indeed address the above issues, but I cannot provide any kind of guarantees for that.)
You can find it in the following repository: https://repos.fedorapeople.org/kkofler/f21-security/ (I had to use the old repos.fedorapeople.org infrastructure because the Copr maintainers "helpfully" deleted the Fedora 21 buildroots, making Copr entirely useless for the purpose of building security updates for distributions Fedora no longer provides them for. I consider this a very bad idea and an absolutely counterproductive practice.)
As specified in the .repo file, the packages are signed with my CalcForge GPG key, available over HTTPS (with a valid certificate from Let's Encrypt): https://www.calcforge.org/RPM-GPG-KEY-calcforge
This repository is provided "AS IS", in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. In particular, NO warrants of any kind are made for completeness of security fix coverage.
Currently, glibc is the ONLY package that has an update available in the above repository.
Kevin Kofler
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Igor Gnatenko i.gnatenko.brain@gmail.com writes:
Why do you want to build such packages for EOLed distro?
Because he's a nicy guy and it's an important patch?
On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
Igor Gnatenko i.gnatenko.brain@gmail.com writes:
Why do you want to build such packages for EOLed distro?
Because he's a nicy guy and it's an important patch?
From my point of view, the whole concept of "EOL" is: if you use this version you acknowledge that NO security patch will arrive and therefore it's possible and very likely that you are running an unsafe system.
I think the important part is to help people to update to supported versions, not to push patches is EOL releses.
On 19/02/16 20:18 +0100, Fabio Alessandro Locati wrote:
From my point of view, the whole concept of "EOL" is: if you use this version you acknowledge that NO security patch will arrive and therefore it's possible and very likely that you are running an unsafe system.
I think the important part is to help people to update to supported versions, not to push patches is EOL releses.
He didn't push it to fedora repos, he created his own repo to share packages with people who might use them.
I don't think anyone who is still running F21 is going to think Kevin's one good deed for this important fix implies the rest of the EOL distro is safe. If they are willing to configure a separate repo to get the fix I assume they know they're running an EOL release, and know what that implies.
On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
Igor Gnatenko i.gnatenko.brain@gmail.com writes:
Why do you want to build such packages for EOLed distro?
Because he's a nicy guy and it's an important patch?
It's counter productive. It's even dangerous, by introducing false sense of safety (apart from glibc, there are lots of other packages with security vulnerabilities in F21).
On 02/19/2016 02:40 PM, Tomasz Torcz wrote:
On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
Igor Gnatenko i.gnatenko.brain@gmail.com writes:
Why do you want to build such packages for EOLed distro?
Because he's a nicy guy and it's an important patch?
It's counter productive. It's even dangerous, by introducing false sense of safety (apart from glibc, there are lots of other packages with security vulnerabilities in F21).
I don't think anyone sees it as precedent; it's more of a public health emergency measure. People who run F21 either don't care (in which case this is moot), or had a specific reason to run it in spite of lack of support.
Did you argue against providing Heartbleed patches for ancient systems?
Tomasz Torcz composed on 2016-02-19 20:40 (UTC+0100):
On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
Igor Gnatenko composed:
Why do you want to build such packages for EOLed distro?
Because he's a nicy guy and it's an important patch?
It's counter productive. It's even dangerous, by introducing false sense of safety (apart from glibc, there are lots of other packages with security vulnerabilities in F21).
The problem with 22+ is that they provide an unstable playground variously called KDE5 or Plasma5, while 21 has a nice stable fully functional KDE4. I'm pretty sure IIRC that OP is primarily a KDE user.
On Sex, 2016-02-19 at 15:11 -0500, Felix Miata wrote:
Tomasz Torcz composed on 2016-02-19 20:40 (UTC+0100):
On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
Igor Gnatenko composed:
Why do you want to build such packages for EOLed distro?
Because he's a nicy guy and it's an important patch?
It's counter productive. It's even dangerous, by introducing false sense of safety (apart from glibc, there are lots of other packages with security vulnerabilities in F21).
The problem with 22+ is that they provide an unstable playground variously called KDE5 or Plasma5, while 21 has a nice stable fully functional KDE4. I'm pretty sure IIRC that OP is primarily a KDE user.
yeah , the nice stable fully functional KDE4, continues in copr with my and Piotr repos [1] and what I'm using in F23
[1] https://copr.fedoraproject.org/coprs/peem/kde4-fedora/builds/ https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/
2016-02-19 3:35 GMT+01:00 Kevin Kofler kevin.kofler@chello.at:
Hi,
I have built an updated glibc package for Fedora 21, with (alleged) fixes for the following security issues:
- CVE-2015-7547 (CRITICAL)
- CVE-2015-1781
- CVE-2015-8777
- glibc PR17269
- glibc PR18032
backported from Fedora 22 or forward-ported from CentOS 7. (To the best of my knowledge, the patches I backported do indeed address the above issues, but I cannot provide any kind of guarantees for that.)
You can find it in the following repository: https://repos.fedorapeople.org/kkofler/f21-security/ (I had to use the old repos.fedorapeople.org infrastructure because the Copr maintainers "helpfully" deleted the Fedora 21 buildroots, making Copr entirely useless for the purpose of building security updates for distributions Fedora no longer provides them for. I consider this a very bad idea and an absolutely counterproductive practice.)
As specified in the .repo file, the packages are signed with my CalcForge GPG key, available over HTTPS (with a valid certificate from Let's Encrypt): https://www.calcforge.org/RPM-GPG-KEY-calcforge
This repository is provided "AS IS", in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. In particular, NO warrants of any kind are made for completeness of security fix coverage.
Currently, glibc is the ONLY package that has an update available in the above repository.
Kevin Kofler
/me wearing his FESCO member hat.
Please remember that F21 has reached End of Life and is *not* supported by fedoraproject.org Though these packages may fix a very critical CVE, we cannot guarantee that CVEs in other packages are also fixed.
So no warranties from fp.o if you keep using F21 with or without these packages.
/me removing his FESCO member hat
Thank you Kevin for your effort to provided a very critical bugfix to people who may use F21, though they shouldn't. At least, I appreciate that you shared your efforts with a larger set of people.
Regards, H.
Haïkel wrote:
/me wearing his FESCO member hat.
Please remember that F21 has reached End of Life and is *not* supported by fedoraproject.org Though these packages may fix a very critical CVE, we cannot guarantee that CVEs in other packages are also fixed.
So no warranties from fp.o if you keep using F21 with or without these packages.
To be clear, this is clearly stated in my disclaimer, which is also contained in my .repo file. It is clear that I cannot resurrect the whole Fedora Legacy as a one-man show.
I really wish Fedora would provide the infrastructure to push security updates for EOL releases. I still think that the one thing that killed Fedora Legacy was its insane amount of bureaucracy and that with an ACL-less free-for-all approach with no QA and with direct pushes to the repository (basically, the way the old Fedora Extras worked), it would just work. (The only restriction should be that only security updates (and fixes for regressions introduced by previously pushed security updates, if any) are allowed and that people pushing any other changes without explicit approval will be banned from the infrastructure.) Basically, the idea should be: You want a CVE fixed, you just fix it.
/me removing his FESCO member hat
Thank you Kevin for your effort to provided a very critical bugfix to people who may use F21, though they shouldn't. At least, I appreciate that you shared your efforts with a larger set of people.
Glad to be of help.
Kevin Kofler
On Sat, Feb 20, 2016 at 03:42:44AM +0100, Kevin Kofler wrote:
I really wish Fedora would provide the infrastructure to push security updates for EOL releases. I still think that the one thing that killed Fedora Legacy was its insane amount of bureaucracy and that with an ACL-less free-for-all approach with no QA and with direct pushes to the repository (basically, the way the old Fedora Extras worked), it would just work. (The
I think what killed it was that lots of people were interested in continuing on Red Hat Linux 7.x and Red Hat Linux 9 indefinitely, but not nearly as many were interested in extended life for the early Fedora Core releases. *shrug*
Matthew Miller wrote:
I think what killed it was that lots of people were interested in continuing on Red Hat Linux 7.x and Red Hat Linux 9 indefinitely, but not nearly as many were interested in extended life for the early Fedora Core releases. *shrug*
That was a problem, but without the insane amount of red tape, it wouldn't have been a showstopper. It does not take much manpower to take the patches that are being applied to the old release n, apply them to the less popular intermediate release n+1, build the result and let it be automatically pushed to stable. The problem was that: * Fedora Legacy required every update for every release to be separately QAed, kinda like Bodhi does now. This already does not work for Fedora n-1 now (just look at how long it takes to get even security updates for Fedora n-1 through Bodhi), so there is no way it can work for n-k, k≥2. * For that QA, a Bugzilla instance was used, but the builtin authentication of Bugzilla was not trusted for some reason, so all comments were required to be manually GPG-signed! (There is of course no UI in Bugzilla that automates that in any way.) Needless to say, very few testers were willing to comply with such a ridiculously high barrier to entry. If you just let the changes get pushed directly to the repository, things will just work.
Kevin Kofler
On Sun, Feb 21, 2016 at 10:45 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Matthew Miller wrote:
I think what killed it was that lots of people were interested in continuing on Red Hat Linux 7.x and Red Hat Linux 9 indefinitely, but not nearly as many were interested in extended life for the early Fedora Core releases. *shrug*
That was a problem, but without the insane amount of red tape, it wouldn't have been a showstopper. It does not take much manpower to take the patches that are being applied to the old release n, apply them to the less popular intermediate release n+1, build the result and let it be automatically pushed to stable. The problem was that:
- Fedora Legacy required every update for every release to be separately QAed, kinda like Bodhi does now. This already does not work for Fedora n-1 now (just look at how long it takes to get even security updates for Fedora n-1 through Bodhi), so there is no way it can work for n-k, k≥2.
- For that QA, a Bugzilla instance was used, but the builtin authentication of Bugzilla was not trusted for some reason, so all comments were required to be manually GPG-signed! (There is of course no UI in Bugzilla that automates that in any way.) Needless to say, very few testers were willing to comply with such a ridiculously high barrier to entry.
If you just let the changes get pushed directly to the repository, things will just work.
Kevin Kofler
I'd like to think that our processes and tools have improved considerably since the days that Fedora Legacy was active. Perhaps it could be something that could be started up as a SIG (analogous to how the openSUSE Evergreen group works for the openSUSE Project) and tried again? It would obviously be a smaller scale project initially, and deal with only the most critical of issues to fix, but we have tools to do automated tests, continuous integration, integrated external repositories, and so on.