Bruno Haible via Gnulib discussion list <[email protected]> writes: > Why should we mention this? The Gnulib repository doesn't use signed commits. > > And IMO it doesn't need to. Last time we discussed this, IIRC Simon noted > that enforcing signed commits hampers development by causing hassles to > the developers.
I still encourage commit signing, not because it actually solves any
real problem that we have, but rather that it encourage a stronger
ecosystem for free software distribution and helps to establish best
recommended practices generally.
But I'm pragmatic enough to see that this isn't realistic or useful to
enforce for gnulib today.
Most projects have stronger security concerns about their artifact
distribution than gnulib.
I think the simplest attack vector for gnulib is someone modifying the
git repository on savannah to inject malware.
Two things mitigate that attack:
1) we have a bunch of active committers that would likely notice any
discrepency with savannah and their local repository and e-mail the
list; together with
2) people don't blindly use the latest commit automatically, it is
normally a manual process to incorporate a particular gnulib commit
into some project and then release that project. So gnulib code
doesn't end up in the wild quickly.
I fear someone may come up with a way to accomplish 1) without us
noticing it, because our use of git builds on SHA1 which is known to be
broken, so it is conceivable that someone could inject malware on the
gnulib git repository on savannah without us noticing. A simple way to
do this today is to give out "known good" git content to Bruno and other
known committers (we all authenticate via SSH so it easy to identify us)
when we pull from Savannah, and "known bad" git content to victims that
they want to target. But there may be more clever attacks achieving
this that builds on SHA1 compromise that we could solve by moving to
SHA256. This affects all git projects though, and I don't think gnulib
need to lead the way.
Publishing a git bundle on ftp.gnu.org/gnu/gnulib/ once in a while
mitigate that attack vector. Which reminds me it should be updated
again for the 202507 branch... and hopefully maybe this time in a
bit-by-bit reproducible fashion: I think we got feedback from git
developers how to accomplish that last time I brought this up.
I also think 2) may change. I would want to automate my CI/CD builds
for my projects to build with latest gnulib commit, so that I quickly
notice any gnulib-related regressions and can report them. Then my
CI/CD builds would generate "nightly" tarball artifacts that some people
may actually end up using, which blindly use gnulib git content.
Of course, another attack vector is to propose malicious code that is
obfuscated enough so that we gnulib developers doesn't notice and commit
it. It feels absurd not to think this already happened, and I feel
certain we will have incidents like that, but the defense to that attack
is our free software philosophy that we will fix things when they are
discovered and made public. We can't hope for perfect things, we can
only aspire to continously improve things when problems are discovered.
/Simon
signature.asc
Description: PGP signature
