On Sat, Apr 18, 2015 at 12:35 PM, Jerry Bratton JerryLBratton@mail.com wrote:
I'm concerned about how long it takes security updates to make it to users under Fedora's current policies (which generally allow such updates the possibility of sitting in testing for 14 days, or even longer).
Just one example is the Firefox 37.0.1 update for Fedora 20: https://admin.fedoraproject.org/updates/FEDORA-2015-5723/firefox-37.0.1-1.fc...
The currently available version of Firefox in Fedora 20 has a critical vulnerability which allows a man-in-the-middle attacker to impersonate any HTTPS website. In this context, shouldn't security concerns win out over the worry that there might be some regression? We already know there's a serious problem in the current package, so why do we have to wait 14 days just because there might be some problem in the new package?
Shouldn't this policy be revised?
I thought a packager already has the ability to push something to stable without any delay? It's just not the default. Is that incorrect?
I think in the case of an upstream like FireFox where we can pretty much be assured that they've escalated a critical security update before any other pending updates, that it's completely reasonable for the packager to take advantage of any policy that lets them bypass updates-testing.
I'm concerned about how long it takes security updates to make it to users under Fedora's current policies (which generally allow such updates the possibility of sitting in testing for 14 days, or even longer).
Just one example is the Firefox 37.0.1 update for Fedora 20: https://admin.fedoraproject.org/updates/FEDORA-2015-5723/firefox-37.0.1-1.fc...
The currently available version of Firefox in Fedora 20 has a critical vulnerability which allows a man-in-the-middle attacker to impersonate any HTTPS website. In this context, shouldn't security concerns win out over the worry that there might be some regression? We already know there's a serious problem in the current package, so why do we have to wait 14 days just because there might be some problem in the new package?
Shouldn't this policy be revised?
I thought a packager already has the ability to push something to stable without any delay? It's just not the default. Is that incorrect?
I think in the case of an upstream like FireFox where we can pretty much be assured that they've escalated a critical security update before any other pending updates, that it's completely reasonable for the packager to take advantage of any policy that lets them bypass updates-testing.
I don't know whether that's correct or not. If it is true, Stransky, could you take that approach in future instances?
In any case, this is not an issue specific to one particular update or one particular maintainer. Perhaps there should be a checkbox for "this is a security update ONLY" that would allow an update to bypass the updates testing repository?
Am 19.04.2015 um 00:53 schrieb Chris Murphy:
On Sat, Apr 18, 2015 at 12:35 PM, Jerry Bratton JerryLBratton@mail.com wrote:
I'm concerned about how long it takes security updates to make it to users under Fedora's current policies (which generally allow such updates the possibility of sitting in testing for 14 days, or even longer).
Just one example is the Firefox 37.0.1 update for Fedora 20: https://admin.fedoraproject.org/updates/FEDORA-2015-5723/firefox-37.0.1-1.fc...
The currently available version of Firefox in Fedora 20 has a critical vulnerability which allows a man-in-the-middle attacker to impersonate any HTTPS website. In this context, shouldn't security concerns win out over the worry that there might be some regression? We already know there's a serious problem in the current package, so why do we have to wait 14 days just because there might be some problem in the new package?
Shouldn't this policy be revised?
I thought a packager already has the ability to push something to stable without any delay? It's just not the default. Is that incorrect?
I think in the case of an upstream like FireFox where we can pretty much be assured that they've escalated a critical security update before any other pending updates, that it's completely reasonable for the packager to take advantage of any policy that lets them bypass updates-testing
and a interesting question is why 37.0.2 available on koji is not at bodhi at all so nobody can give karma (if easy-karma works randomly as yesterday while not most of the time for week snow)
the permanent timeouts of fedora-easy-karma are a real problem because i guess i am not the only one running updates-testing all the time don't open bodhi and seek for each installed testing updat eto give karma
Apr 17 01:43:44 Updated: firefox-37.0.2-1.fc21.x86_64
Am 19.04.2015 um 02:23 schrieb Reindl Harald:
I think in the case of an upstream like FireFox where we can pretty much be assured that they've escalated a critical security update before any other pending updates, that it's completely reasonable for the packager to take advantage of any policy that lets them bypass updates-testing
and a interesting question is why 37.0.2 available on koji is not at bodhi at all so nobody can give karma (if easy-karma works randomly as yesterday while not most of the time for week snow)
the permanent timeouts of fedora-easy-karma are a real problem because i guess i am not the only one running updates-testing all the time don't open bodhi and seek for each installed testing updat eto give karma
Apr 17 01:43:44 Updated: firefox-37.0.2-1.fc21.x86_64
the same for kernel 3.19.4-100.fc20
appeared today the first time in updates-testing, is offered with yum --update --security and was built Tue, 14 Apr 2015 01:24:35 UTC
Am 19.04.2015 um 12:15 schrieb Reindl Harald:
Am 19.04.2015 um 02:23 schrieb Reindl Harald:
I think in the case of an upstream like FireFox where we can pretty much be assured that they've escalated a critical security update before any other pending updates, that it's completely reasonable for the packager to take advantage of any policy that lets them bypass updates-testing
and a interesting question is why 37.0.2 available on koji is not at bodhi at all so nobody can give karma (if easy-karma works randomly as yesterday while not most of the time for week snow)
the permanent timeouts of fedora-easy-karma are a real problem because i guess i am not the only one running updates-testing all the time don't open bodhi and seek for each installed testing updat eto give karma
Apr 17 01:43:44 Updated: firefox-37.0.2-1.fc21.x86_64
the same for kernel 3.19.4-100.fc20
appeared today the first time in updates-testing, is offered with yum --update --security and was built Tue, 14 Apr 2015 01:24:35 UTC
and *why* are security updates built *3 weeks ago* with state "This update has reached 7 days in testing and can be pushed to stable now if the maintainer wishes" not pushed automatically?
================================================================================ libzip-0.11.2-5.fc20 ================================================================================ Update ID: FEDORA-2015-4556 Release: Fedora 20 Status: testing Type: security Karma: 0/3 Bugs: https://bugzilla.redhat.com/1204677 - CVE-2015-2331 php: libzip: integer overflow when processing ZIP archives [fedora-all] : https://bugzilla.redhat.com/1204676 - CVE-2015-2331 libzip: integer overflow when processing ZIP archives Notes: CVE-2015-2331: integer overflow when processing ZIP archives : (#1204676,#1204677) Submitter: rdieter Submitted: 2015-03-23 13:05:55 Comments: bodhi - 2015-03-23 13:06:01 (karma 0) This update has been submitted for testing by rdieter. taskotron - 2015-03-23 13:20:15 (karma 0) Taskotron: depcheck test PASSED on i386. Result log: https://taskot
ron.fedoraproject.org/taskmaster//builders/x86_64/builds/50697/step s/runtask/logs/stdio (results are informative only) taskotron - 2015-03-23 13:20:39 (karma 0) Taskotron: depcheck test PASSED on x86_64. Result log: https://task
otron.fedoraproject.org/taskmaster//builders/x86_64/builds/50697/st eps/runtask/logs/stdio (results are informative only) bodhi - 2015-03-23 17:02:10 (karma 0) rdieter has edited this update. New build(s): libzip-0.11.2-5.fc20. Removed build(s): libzip-0.11.2-4.fc20. taskotron - 2015-03-23 17:08:44 (karma 0) Taskotron: depcheck test PASSED on i386. Result log: https://taskot
ron.fedoraproject.org/taskmaster//builders/x86_64/builds/50893/step s/runtask/logs/stdio (results are informative only) taskotron - 2015-03-23 17:10:02 (karma 0) Taskotron: depcheck test PASSED on x86_64. Result log: https://task
otron.fedoraproject.org/taskmaster//builders/x86_64/builds/50893/st eps/runtask/logs/stdio (results are informative only) bodhi - 2015-03-24 21:54:19 (karma 0) This update is currently being pushed to the Fedora 20 testing updates repository. bodhi - 2015-03-26 21:44:39 (karma 0) This update has been pushed to testing bodhi - 2015-04-02 22:41:32 (karma 0) This update has reached 7 days in testing and can be pushed to stable now if the maintainer wishes
https://admin.fedoraproject.org/updates/F20/FEDORA-2015-4556
inst. RPMS: libzip-devel-0.11.2-5.fc20.x86_64 - Development files for libzip (installed 22 days ago) : libzip-0.11.2-5.fc20.x86_64 - C library for reading, creating, and modifying zip archives (installed 22 days ago)
security@lists.fedoraproject.org
-
Chris Murphy -
Jerry Bratton -
Reindl Harald