BTW, adding comments to myself, the signed commits and their
verification takes care of problems 2FA doesn't. First, ensure
authorship information (2FA doesn't leave a mark in the commit), and
protects the integrity of the downstream source: the build can ensure
that the checked out downstream project doesn't get "dirty" during and
after the build, and/or commits are not modified during and after the build.
But this doesn't solve the specific xz problem. That one requires
different kinds of defense techniques.
On 3/31/24 08:10, Carlos Rodriguez-Fernandez wrote:
Going in that same route, if 2FA becomes mandatory, then we have a
stronger defense of the GPG public key in the user profile. The attacker
would need not only the credentials, but the 2FA device to change the
public GPG.
That then makes one step further possible: enforce commit signing on the
downstream project. That makes authorship of changes non repudiateable
(that is, important changes like `sources`, all patches, specs, etc...),
and also allows the build to check that all commits between the last
release and the current build are signed by the committers of the
project. This can be done by having the build importing the public GPGs
of the committers of the downstream project from pagure/FAS and
checking, again, the commits since the last release. The downstream
project *source code* would be effectively signed, so the signed rpm
then would carry even a higher assurance: "this artifact was built by
Fedora Infrastructure", but also "all the downstream sources used to
make it are assuredly coming from the maintainers."
It is definitely an additional hassle for the maintainers, but there is
value in it, especially in this day and age.
On 3/31/24 01:58, 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...
> . 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