Re: [PLUG] free courses, systemd Win, hashquines

[Rich Freeman via plug <plug@lists.phillylinux.org>]

On Sun, Sep 25, 2022 at 8:49 PM Walt Mankowski via plug
<plug@lists.phillylinux.org> wrote:
>
> On Sun, Sep 25, 2022 at 08:22:47PM -0400, Rich Freeman via plug wrote:
> > So, on the topic of insecure hash algorithms, can anybody spot the
> > glaring problem with this:
> > $ git cat-file commit ec9a21e4f51de087744f2f5eb95a82cda673b07e
> > tree 0b6fab6bb7b543878e599ec60699fb005b434bbc
> I can't.

Yeah, I could have been less clickbaity.  I'll confess this is also a
bit of a soap box item for me.

Git still uses sha1 hashes, though I think they're talking about
adding support for sha256 (no, it isn't impossible to switch or even
have both).

In this example I posted a gpg-signed git commit.  Git commits and
tags can both be signed using gpg.  The problem is that the signature
only covers the commit record itself, which is just the commit
message, and pointers to the parent commit(s) and the tree which is
what leads to the actual files.  These pointers are sha1 hashes, so if
you can defeat sha1 then you can apply a git signature to a different
set of files than what was actually signed.  This is why the hash
algorithm used in any kind of cryptographic signature is critical.

Obviously the attacks available on sha1 right now make this a bit of a
niche, but you really don't want to be using insecure hash algorithms
for something like this.

I think a lot of the reluctance to change, aside from the effort
involved, was due to Linus's personal workflow for the kernel.  He
doesn't use gpg with git in a way that really makes this a problem, so
I guess in theory nobody else ought to.  Of course the kernel doesn't
really use git in the way that most projects do in general, with much
of the workflow happening in emails and private repos, not clones of
some project-wide master.

In general though I don't think that knowing whether code has been
tampered with and knowing who originated it is an exotic use case.  It
only makes sense to have gpg-signed commits with strong hashes
ensuring that the files in the repo you're syncing from haven't been
touched.

(The example in my email comes from the Gentoo stable repo, which
basically takes the master repo that devs push to, periodically
snapshots it, runs it through CI tests, checks that all commits since
the last snapshot use a valid Gentoo dev key, adds some metadata
caching, and then applies the central distribution key signoff to it.
Then users can sync using git and the package manager checks the
signature on the top commit before fast-forwarding it without needing
to maintain a copy of every dev's key.  At this point I believe this
is also what gets pushed out to the rsync mirrors.)

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug