Ban unarmored GPG keys

Start by reading issue #329 and the existing ASCII-armored GPG private-key ban. Compare the proposed file, python-magic, and self-implemented MIME matching approaches, then define a portable detection behavior and verify that unarmored private keys are rejected without incorrectly banning ordinary binary data.

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?