On Sat, 2022-02-12 at 14:52 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Feb 12, 2022 at 12:50:58PM +0100, Vitaly Zaitsev via devel wrote: > > > Thus, if you are able to create a build that > > > is submitted as an update (i.e. either build it for rawhide, or build it > > > for other releases and create a bodhi update), this is enough to wreak > > > havoc at > > > least on machines of people who use rawhide / updates-testing. > > > > If a hacker will "updates" the foo-bar package, it will only harm users who > > have that package installed. > > Yes, that is true. But a typical installation has between a few hundred and > a few thousand packages, and there are also users who purposefully install > additional packages e.g. for QA. So such a breach would have an important > impact, even if it wouldn't impact *all* packagers. > > Also note that you can add Supplements:glibc and suddenly the package will > be installed in additional places.
Yup, we actually use this trick in openQA to get a package from an additional repo installed without changing 'real' packages or comps. It works. > > > > As you certainly know, many updates don't receive any feedback, and almost > > > all updates receive no scrutiny if they install without errors. > > > > This is another problem. We should add some kind of gamification for QA > > testers, like achievements. > > > > > Thus a > > > nefarious update would have fairly high chances of going stable too. > > > I suppose that at some point it would be noticed, and the update pulled > > > and the account deactivated, but there is no automatic process for this. > > > > Maybe instead of deleting user accounts or their memberships, we should keep > > track of such updates and block auto-stable on karma and time for them? > > We are not *deleting* user accounts, the proposal is to remove the > user from a group. We could do something more complicated, but that'd > require introducing special logic in multiple places (koji, bodhi, > probably others), and I don't see how it'd be better than the proposed > solution. If this alternative solution was implemented, for the user the > result would be equivalent to the proposed solution. Replying to Vitaly here: the Bodhi process is absolutely not intended to act as security review and I don't see that it really can. Someone who goes as far as taking over a dormant maintainer account to submit a nefarious package can almost certainly also arrange to have the update immediately approved (note you can set the push threshold for a non- critpath update to +1, so you need only one account to +1 it and it will be pushed stable). Even ignoring that, security review is a specialized skill and most of the people who review updates are not trained in it. Even people who *can* do security review and also file Bodhi feedback probably aren't doing a review of every update they +1, because it's a time-consuming task and they are not being paid for it. Bodhi functions as a quality sanity check. It's absolutely not security review. I think that while it's slightly unfortunate that this is the case, the proposal is probably necessary, and I support it. Real world supply- chain attacks are happening, regularly, and the Fedora package collection is certainly a valid target for such an attack. We should do what we can to make it more difficult to carry one out. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
