On Sat, 2024-03-30 at 15:23 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
> Once upon a time, Michael Catanzaro <mcatanzaro(a)redhat.com> said:
> > I agree that running autoreconf on our packages makes sense to start
> > doing. Still, to avoid this backdoored m4 file, we would have needed
> > to stop using release tarballs altogether and switch to using git
> > tags directly instead. That would at least force the malicious
> > attacker to commit their code to version control, making it slightly
> > harder to hide the attack.
>
> Using a signed tarball is ideally better than a git tag (it's an extra
> level of author attestation)... but where both are available, it'd be
> nice to have a way to denote in the spec file that there are two URLs
> for the source. In this case, if both URLs were listed and something
> could be run to automatically fetch and compare them, the attack code
> would have been flagged.
Tarball production should be reproducible. Then the maintainer can
both make a signature locally and make it public, and users can download
the auto-generated tarball.
In fact, github tarball generation is stable. A few years ago they tried
to improve the compression method (i.e. .tar would be still identical,
but .tar.gz would be different), and after a huge outcry this was reverted.
They still haven't officially said that it's stable, but let's hope that
it never changes, at least not without a suitable advance warning.
I do not know if this changed in the last couple of years, but tarballs
in github are not stable (or weren't up to a couple years ago), they
are cached for a period of time, so they may look stable in busy
projects where you have regular downloads that keep the cache alive,
but they are *regenerated* from the tag for seldom downloaded tarballs.
And when that happens then hashes change.
Simo.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc