Signing, key management, and signature verification: PGP, ssh-keygen, or roll my own?

`filepack` should support signing manifests, writing signatures to files alongside manifests in a `signatures/` subdirectory, and `filepack verify` should verify those signatures, optionally also asserting that a manifest was signed with a particular known key. I'm conflicted on how this should be implemented. In particular, should `filepack` use GPG/PGP which is already widely used to sign software releases, or should it use something custom? I have a lot of misgivings about both options. On PGP: - PGP supports a plethora of cryptography schemes and hash types, including weird legacy types that nobody should use. - Since PGP supports cryptography systems with super long keys, SHA1 key fingerprints are used instead. SHA1 is broken, although not broken enough to be a problem for this use case, but still. And since good modern curves like secp256k1 and ed25519 have short public keys, using key fingerprints instead is an unnecessary indirection. - The `gpg` binary does not have a good API for programmatic interaction. It has something called the "colon format", but it is insane. Do `gpg --list-keys --with-colons` to see what it looks like. - It uses base64 instead of hex for some things, and ASCII armor, which seems terrible and weird. - There's a [PGP](https://github.com/rpgp/rpgp) crate, but it's a huge dependency. - The PGP web of trust model is just not used by anyone, yet `gpg` the binary caters to it. - GPG wants you to add trusted keys to a local key store, so then when you verify a signature it can tell you that it's trusted, when in fact I think the workflow which a lot of users will want is something like `filepack verify --key PUBKEY`, where the user provides a pubkey on the command line from a project developer, and `filepack verify` will fail if there isn't a valid signature in `signatures/` with that pubkey. - Since developers can create signatures with any combination of hash and public key crypto system, it adds all possible hashes and crypto systems as dependencies, both for `filepack`, and any future reimplementations and libraries. On rolling my own: - Support for hardware signing devices would be out of scope for a long time, whereas GPG supports it. However, the [instructions for using it are insane](https://github.com/drduh/YubiKey-Guide), and I'm not sure many people actually use hardware signing devices in practice. - Rolling your own of anything related to crypto is generally frowned upon. However, in this case I wouldn't be rolling my own crypto system, merely picking an existing crypto system, like ed25519 or secp256k1. I *would* be rolling my own simple key management, signature serialization, etc. - I could use BLAKE3 as the hash function, to avoid dependencies on additional hash functions. I did a simple prototype using secp256k1: `filepack keygen` to generate keys and write them to `~/.filepack`, `filepack create --sign KEY` to sign with a key, and `filepack verify --key KEY` to assert that a manifest was signed by `KEY`, and it took like two hours and is basically 90% complete, so rolling my own is definitely the immediate path of least resistance. You can see it in PR #48, which is incomplete, and lacks any tests or error handling, but shows how simple a custom implementation is.