Re: Three steps we could take to make supply chain attacks a bit harder

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

 



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.

4. Our main auth system was written years ago by someone who no longer
contributes and nobody is really actively maintaining it[0].

These are just the ones that leap to my tired mind at this moment. I'm
sure we can think of many more things we should probably look at before
we start pontificating (or, worse, lecturing) about how things should
be done upstream of us.

[0]: https://pagure.io/ipsilon/commits/master
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx
https://www.happyassassin.net



--
_______________________________________________
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