Hacker News Reader

Comment by jasonh3 | Hacker News Reader

It's great that DC is making their latest laws available to everyone, however it's a little scary that the commits aren't signed, meaning that anyone who gained access to the github repo could forge them (and do more than fixing typos).

Hopefully DC (and others) will look at doing GPG signatures[0,1] so that they don't have to trust github's authentication as much. Github has a nice GUI that reflects signatures with the "Verified" tag, which you can see at[2].

0: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

1: https://help.github.com/articles/signing-commits/

2: https://github.com/QubesOS/qubes-doc/commits/master

View on HN

There are a number of technical limitations to gpg signatures. Your hypothetical attacker who has access to github can simply add his/her key and show up as a verified committer. gpg signatures have many other issues including metadata corruption, not to mention the nearly insurmountable issues around key management. As mentioned below, we have internal systems that allow us to audit/authenticate the repository. We will be rolling out a UELMA-compliant authentication scheme based on TUF in the next several months that will allow the public to authenticate the repository.

> meaning that anyone who gained access to the github repo could forge them (and do more than fixing typos).

… which would immediately be noticed by everyone using the repo. How many scenarios are there where a compromise wouldn’t include GPG keys or the attacker simply uploading their own key?

I hope you would be correct, that lots of people would notice a compromise, though I'm not convinced that this would be the case since the attacker could pretend to be the single committer.

> How many scenarios are there where a compromise wouldn’t include GPG keys or the attacker simply uploading their own key?

If the user's github credentials were compromised (lots of ways for that to happen which don't involve their system/keys being compromised, like using the same password across sites), then using GPG signatures would still allow cloners to check/detect problems since they wouldn't have the maliciously-updated github GPG key (or they might be one of the few folks still using the Web of Trust).

Furthermore, it's possible to have a local system compromise that doesn't give access to GPG keys, as keys could either be password protected or kept on a separate system that's primarily used for signatures (not extreme for a system that distributes law).

Also, signatures not only protect the latest commit, they also sign the previous commit hash(es), protecting previous commits and preventing a history rewrite. Without them, a history rewrite that left recent commits unchanged but modified some text could have the chance to go unnoticed.

EDIT: small clarity tweak

> If the user's github credentials were compromised (lots of ways for that to happen which don't involve their system/keys being compromised, like using the same password across sites), then using GPG signatures would still allow cloners to check/detect problems since they wouldn't have the maliciously-updated github GPG key (or they might be one of the few folks still using the Web of Trust).

This assumes that the attacker wouldn't simply upload their own key to public keyservers with the same email address. I would be shocked if more people would notice the use of an additional key than would notice, say, Git's warning when history changes between different repos.

The big win is having multiple copies with independent access control. I'm not opposed to using GPG but in practice the benefits are fairly minimal and there's a massive usability hit for anything involving GPG. In the case of a legal code that's probably justified but it's probably well into diminishing returns.

Considering GPG is the primary protection for the Linux distros that run most of the services we're discussing* , at some point our trust falls down to it anyhow :)

* : Last I checked, the two most popular Linux distros I'm familiar with (CentOS and Ubuntu) only make their iso hashes available via http-only served files that are GPG signed

Those distributions use GPG but they also use pre-deployed signing keys rather than, say, trusting any @debian.org key on a public keyserver. When you're centralizing trust like that anyway, the differences between that and a canonical Git repo don't seem to be especially significant from a practical standpoint.

Reply on news.ycombinator.com