Re: Inactive packagers to be removed after the F37 release

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux