bundle a version of gpg for Windows

[shiftkey]

MinGit does not contain a version of gpg to use for managing commit signing.

I think we can live without this for macOS and Linux (cc @smashwilson for feels).

[smashwilson]

Honestly, it makes a sense for all three platforms. Bundling a known version of gpg would definitely make some of the more arcane bits of gpg support more reliable. There are many differences between gpg 1 and gpg 2 in terms of command-line arguments, daemon management, pinentry protocols and so on that we need to account for presently, and at some point we just have to throw our hands in the air and give up.

A few of the downsides that come to mind:

• It makes MinGit less Min (naturally)
• What if we bundle a configuration of gpg that's less secure (by whatever metric) than what a user has configured themselves?
• Assuming responsibility for the distribution of crypto software opens up previously unopened cans of worms. How do we handle upgrades due to CVEs, how do we communicate security-sensitive updates to our userbases...
• Are there export regulations we'd need to comply with in redistributing cryptography?
• How do we interact with preexisting user configurations? How about an existing gpg daemon? (We already hit this with git, true, but I think git's configuration has been a bit more stable.)

[shiftkey]

It makes MinGit less Min (naturally)

Yeah, but I think it's worth it if we can avoid the hassles of setting up and enabling commit signing for a user.

What if we bundle a configuration of gpg that's less secure (by whatever metric) than what a user has configured themselves?

I wouldn't like to override a config file the user already has defined one, but then I hadn't thought of the potential compatibility issues between gpg 1 and gpg 2 if we focus on supporting gpg 2, for example.

Assuming responsibility for the distribution of crypto software opens up previously unopened cans of worms. How do we handle upgrades due to CVEs, how do we communicate security-sensitive updates to our userbases...

Excellent points. I guess we would already have to do this if Git receives a CVE, but formalizing a process behind this would be 💎 in general.

Are there export regulations we'd need to comply with in redistributing cryptography?

Probably, especially if we find ourselves building cryptography libraries from source. Will investigate.

How do we interact with preexisting user configurations? How about an existing gpg daemon? (We already hit this with git, true, but I think git's configuration has been a bit more stable.)

Yeah, Git's configuration system is definitely more resilient in this regard. But interoperating with an existing setup is something I'd like to support - particularly if it's the same major version of GPG as what we have in-the-box.