Highlights from Git 2.34

Highlights from Git 2.34
github.blog

Comments from the last time: https://news.ycombinator.com/item?id=28207168

For those who don’t know: GitHub is owned by Microsoft, a historical (and current) adversary of all things not Microsoft, particularly Linux¹. Git, the tool, is not made by GitHub; GitHub is a web service which is using Git. Git, the tool, was originally made by the person who also originally made (and currently manages) Linux, and the purpose of Git was to manage the development of Linux itself.

1. https://en.wikipedia.org/wiki/Halloween_documents

When auditing a source repository you want to see how commits are signed over time. In other words you have a key X which is valid at time Y. As Y changes, key X will change as well. To audit a repo, you need to know the history of what key X was valid at time Y.

With GPG you can set up a hierarchy of commit signing keys which have defined lifetimes and are all subordinate to a master key which you do not use for signing (and hopefully keep somewhere secure). One irritant is that the major git-as-a-service products, i.e. github + gitlab, do not respect the use of GPG keys as something varying over time or subordinate to a master key. Instead they let you set a current active key and mark on their own if it was verified at the time. If you want to validate the repository's security yourself, you don't have the proper information to do so.

The use of ssh keys as signing keys furthers this incorrect usage of a single key as something that does not vary over time. You can use ssh certificates as a way to have a hierarchy, but that still doesn't acknowledge that there is historical data of note.

Now, a logical question is: If each git commit is the summation of everything before, why does historical data matter? Why can't I just trust the git{hub,lab} when it says it was "Verified" at the time? A few reasons:

- Github allows someone logged in to make edits via their web editor which they helpfully sign with a universal github key that is always verified. So if your AuthN is bad, that is a problem.

- You are trusting that your git-as-a-service provider will never have their repositories tampered with and your org will just download the newest version of the repo.

- It relies on git-as-a-service providers to track this. If you aren't using a managed service provider you need to roll your own auditing tools.

It's pretty clear they're talking about a separate project.

I understand your reasoning and the idea behind GPG and everything, but here's my challenge to all of this: Has this ever happened?

Like, the scenario we're talking about is that at some point some bad code, maybe a backdoor, got introduced into a code repo, and it later is discovered and someone launches an investigation. And they find out "this was committed by XYZ but XYZ claims he didn't do it".

I don't remember any such incident ever. Given that I feel a slightly weaker form with SSH keys may still be justified. (And it is still easily conceivable to have some out-of-band-metadata, e.g. a project that feels this is important could just have a list of developer SSH key fingerprints within the repo and thus have the backlog of who's keys were relevant at what point in time.)