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. > > 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. > > We certainly don't want to push maintainers away. In fact this whole > > thread is primarily about striking the right balance between security and > > the desire not to inconvenience maintainers. > > From proposal: > > > If no activity is detected within a year, try to contact them by their account email and if no reply is received after a proper delay (1 month) proceed by removing them from the packager group. > > They will need to be sponsored again. Some people are waiting for > sponsorship for months. They will not go through the normal sponsorship process, but instead something akin to a password reset (albeit public and not automated). > > Ehh, I don't think so. There are many automated emails being sent by > > our infra. If a hacker wants to send a phishing email, they might > > just as well spoof a bugzilla ticket or a pagure notification. > > None of them require you to sign in and follow any links. Well, nothing *requires* you to follow links, but many of them *contain* links, and the sites behind those links will require you to log in to e.g. post a comment. Zbyszek _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
