On Fri, 2022-09-16 at 17:16 +0000, Dan Čermák wrote: > Hi, > > On September 16, 2022 5:03:03 PM UTC, Kevin Fenzi <kevin@xxxxxxxxx> > wrote: > > On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote: > > > Isn't peer review much better and easier solution over all? We > > > could also > > > require signed commits I guess. > > > > I think it would slow things down quite a lot to require peer > > review of > > every commit. > > It would a bit, but it is doable. openSUSE tumbleweed works like > that: every commit that is sent into the rolling distro is reviewed > by the release managers. It adds some overhead and it would most > certainly require dedicated reviewers and additional tooling. > > > I'd personally like to avoid anything where we need to support gpg. > > It's a mess and I think it would waste a lot of cycles explaining > > how to > > use it or help people get setup. ;( If there's some easier/more > > clear > > way to sign things that could be a option tho. > > > > kevin I don't think it would help in this particular case anyway. Downstream avoids malicious behavior on upstream by downloading a specific tar ball, verifying its hash, then building it on Fedora's infrastructure. That means any malicious commit will be caught by packagers. Now let's imagine the same attack scenario for downstream. They would somehow need commit privileges then to forge a commit. But I think in this scenario, they would need commit privileges, but not access to the gpg key right? So you would see an "unverified" commit. But all this signals to us is that the packager's account is compromised. Which there are other ways of determining that and there's other damage the attacker can do if they somehow compromised the account. Verifying every commit does not seem scalable either. Someone mentioned that there's 20k~ packages in the base repos. The current approach involves mostly automation, QA and validation testing to catch any bugs. How would every commit be reviewed? It makes sense on the scale of something like the Linux kernel where you have a hierarchy (Linus, his release managers, project owners, then people below that). For Fedora, it would add way too much bureaucracy and overhead and probably not even give that much benefit. With that being said, if a GPG key would be compromised, wouldn't it result in an error when trying to update the package? An end user would then report the bug, someone would see that the key does not match the signature in the gpg-distribution package, signalling that it's compromised. _______________________________________________ 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
