2008/12/8 Kevin Kofler <kevin.kofler@xxxxxxxxx>
Richard your comments
Well, the problem here is that the update was rushed to stable when:
* the update touches a core system component which is relied on by our
update system among many other things,
* the update is not one of those obvious security fixes like preventing a
buffer overflow, it is a policy change (and thus much more likely to break
things),
* the policy crackdown is on local communication, not remote. This means:
- it is more likely to break the system and as such needs testing and
- the hole it fixes is at most a local privilege escalation, and finally
* the issue has been public for over a month! What is one more week of
testing going to change?
I think we need to be more careful with certain types of security updates,
and better let them get some QA even if it means the fix gets delayed.
Completely breaking the updates means many users will never get any updates
anymore (because they don't know how to fix their system - there's a
PackageKit update queued, but how are they going to get it without a
working PackageKit? You can't expect them to know what su -c "yum upgrade"
is), including critical security fixes. Is a low-priority security update
worth that? At the very least the maintainer should actually test the
update before rushing it out, which I strongly doubt he did because
PackageKit not working is something everybody should notice. (But I don't
think that's sufficient, I think the update should have stayed in
updates-testing for a week. And ideally both should have happened, the
maintainer should have tested it first, and only when actually working
pushed it to testing.)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
