On Sun, Mar 31, 2024 at 01:58:21AM -0700, Adam Williamson wrote: > On Sat, 2024-03-30 at 09:37 +0000, Richard W.M. Jones wrote: > > I'm not pretending these will solve everything, but they should make > > attacks a little harder in future. > > I don't disagree with Richard's list. However...more in regards to some > of the grandiose ideas in later posts than Richard's list...I think > we're in danger of building castles in the sky while not cleaning up > the poop in our backyard, here. > > Before we start in on the grand fantasies about converting the world > off autotools or banning binaries in repos or centralized source depots > authenticated by a committee of Top People, can we remember: > > 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still > don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE > COMPULSORY 2FA FOR FEDORA PACKAGERS*. > > 2. Our process for vetting packagers is, let's face it, from a security > perspective almost *comically* patchy. There are 140 sponsors in the > packager FAS group. Any one of those people - or someone who > compromises any one of those 140 accounts - can grant any other person > on earth Fedora packager status. Our policy on how they should do this > is > https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection > . The words "trust" and "identity" do not appear in it. There is, > AFAIK, no policy or procedure by which inactive sponsors have this > power removed. There is no mandatory 2FA policy for sponsors. > > 3. We have no mechanism to flag when J. Random Packager adds > "Supplements: glibc" to their random leaf node package. As a reminder, > *we are a project that allows 1,601 minimally-vetted people to deliver > arbitrary code executed as root on hundreds of thousands of systems*, > and this mechanism allows any one of those people to cause the package > they have complete control over to be automatically pulled in as a > dependency on virtually every single one of those systems. This is as much a distro design problem, as a Fedora process problem. The typical Linux distro model is that everything is installed in the same namespace, and we only avoid interference (whether accidental or intentional) by careful packaging design and review. This is somewhere where the image based Linux distro model has a potential benefit, with a comparatively slim distro base, and then applications as self contained separated entities, whether server apps in podman containers, or GUI apps in flatpaks. No easy anwere here though, as the traditional Linux model isn't going away any time in the forseeable future. > 4. Our main auth system was written years ago by someone who no longer > contributes and nobody is really actively maintaining it[0]. 5. We review initial new packages in a moderate level of detail, but after that it is largely a free for all for every rebase. It is up to the maintainer's discretion what to do for new releases, and any oversight is patchy at best. The threat here was in relation to an update to an existing package, and where we have no formal process that was even /interested/ in addressing that threat, let alone capable of stopping it. Now, in this particular case, it would have been challenging to detect it the problem even with "new package" review process, so I'm sceptical we can easily build a "updated package" process that would have blocked it and yet remain practical for maintainers. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
