Ban unarmored GPG keys

In #329 we added a ban for ASCII-armored GPG private keys. But as far as I can tell we don’t have a method for detecting un-armored private keys, since they resemble unstructured binary data.

$ gpg --export-secret-keys > secrets
$ file -I secrets
secrets: application/octet-stream; charset=binary

However, that doesn’t mean they can’t be identified (evidently):

$ file secrets 
secrets: PGP    Secret Key - 4096b created on Sun Nov 17 19:37:04 2013 - RSA (Encrypt or Sign) e=65537 hashed AES with 128-bit key Salted&Iterated S2K SHA-11

It looks like the mime-type for PGP keys is defined here: https://tools.ietf.org/html/rfc3156

---

This leads to a fork in the road for implementation:

We could make a subprocess call to file.

I don’t like this for portability reasons. We don’t know that file exists and behaves consistently everywhere pre-commit will be deployed.

We could use the magic library.

This works:

$ python3
Python 3.7.1 (default, Nov  6 2018, 18:45:35) 
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import magic
>>> mime = magic.Magic()
>>> mime.from_file('secrets')
'PGP\\011Secret Key - 4096b created on Sun Nov 17 19:37:04 2013 - RSA (Encrypt or Sign) e=65537 hashed AES with 128-bit key Salted&Iterated S2K SHA-1'

But it adds a dependency on a non-standard library: python-magic.

We could try to emulate the mimetype matching ourselves.

Reinvents a wheel and the consequences of getting it wrong when users trust us to get it right could be bad.

---

What do you think?

[rpdelaney]

Yeah I didn’t put that clearly, sorry. It’s not that useful that they have examples of how to call libmagic from python. I meant more like porting C code into python. I don’t have time to dig deeper right now but I wanted to leave the comment as a reminder for when I look at this again.

[rpdelaney]

Yup. Based on the comments it looks like they implemented GPG-specific stuff if and only if it isn’t already identified by the PGP filetype definitions they had already. That’s consistent with my testing so far. I don’t see any reason why we should consider whether libmagic defines the thing as ‘GPG’ or ‘PGP’ – the idea is to ban secret keys.

After some cursory research I’m inclined to think we should ban session keys also. I can’t imagine a legitimate reason to ever commit one to a git repo.