fedora-devel-list

2008/12/8 Kevin Kofler <[EMAIL PROTECTED]>

>
> 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
> [EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
 Richard your comments

-- 
fedora-devel-list mailing list
[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/fedora-devel-list