On Fri, Apr 17, 2020 at 01:01:52AM -0000, Demi M. Obenour wrote: > We need to ensure that security updates reach stable within hours of an > upstream advisory. Technically, we can create a critical security repository that will be composed and published on every new package build. But since rsync mirrors use a pull model, it's unrealistic to expect that the content will be delivered to users in a timely manner. It would mean that all these updates would be downloaded by users directly from Fedora primary mirror. Is Fedora infrastructure able to handle the network load? > Finally, some packages should have all updates considered as security > updates. This includes anything based on a web browser (Firefox, > Thunderbird, SeaMonkey, Chromium, webkit2gtk, etc), as well the Linux kernel > itself. Virtually every update of these packages fixes security > vulnerabilities, so updates to them should be considered security updates > and treated as such. Placing them directly to the stable repository is a bad idea. Despite the fact that any new version fixes the security flaws, it sometimes brings a regression. Especially in case of Linux, the security flaw can be in a module that is not in use, but the regression can affect a code in use. Don't forget that packages in the stable repository are replaced, not accumulated. A user cannot roll back because the previous build was removed from all repositories. I really think the urgent updates should go to a dedicated repository and at the same time undergo normal testing phase in updates-testing repository. After stabilizing, they would be moved to the stable repository and removed from the dedicated repository. Wheter the dedicated urgent repository should be enabled or disabled by default is a good topic for a flame war on this list. (My opinion: if enabled, the package managers, especially the Gnome one, should provide an easy way for reverting the urgent update.) -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
