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 secretssecrets: 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 tofile.

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

We could use themagic library.

This works:

$ python3Python 3.7.1 (default, Nov  6 2018, 18:45:35) [Clang 10.0.0 (clang-1000.11.45.5)] on darwinType "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?