5:53 p.m.
On Sat, Apr 18, 2015 at 12:35 PM, Jerry Bratton <JerryLBratton(a)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...
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.
--
Chris Murphy
7:04 p.m.
> 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...
>
> 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?
7:23 p.m.
Am 19.04.2015 um 00:53 schrieb Chris Murphy:
On Sat, Apr 18, 2015 at 12:35 PM, Jerry Bratton
<JerryLBratton(a)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...
>
> 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
5:15 a.m.
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
6:44 a.m.
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)
3296
days inactive
3297
days old
security@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Chris Murphy -
Jerry Bratton -
Reindl Harald