pretty_bad_protocol: Support exporting encrypted secret keys

[legoktm]

Status

Ready for review

Description of Changes

As part of the Sequoia migration, we want to export secret keys out of the GPG keyring and into our new database storage.

So, have the gpg.export_keys() function accept a passphrase to export encrypted keys that GPG wants a passphrase for. Internally we switch it to use the _handle_io function since that has support for taking passphrases; the one weird thing is that it requires an input file (e.g. if you were encrypting a file) but since there's no input here an empty temporary file works just fine.

For whatever reason I couldn't get a simple p.stdin.write(passphrase) to work, it would hang on stdout, which is probably related to the pre-existing comment about "stdout will be empty in case of failure"...

A new test generates a new GPG key pair, exports the public and secret keys from the keyring and then encrypts and decrypts a message using Sequoia to test compatibility. It also checks a few error cases
like invalid fingerprint and missing secret key.

Refs #6802.

Testing

How should the reviewer test this PR?

• Visual review
• CI passes

Deployment

Any special considerations for deployment? No

Checklist

• Linting (make lint) and tests (make test) pass in the development container
• I have written a test plan and validated it for this PR

[cfm]

The diff here looks good, @legoktm. A couple of comments:

I assume we'll get an integration test of using an actual source's secret key this way in #6802.

When we originally vendored pretty_bad_protocol in #6836, I wasn't aware (at least, I wasn't tracking) that we'd need to patch it further. In hindsight, I wish we'd used something like vendoring (however unsupported) to add another layer of separation between the upstream code we've vendored and our local patches to it; at the very least, I wish we'd marked or logged the patches in the vendored tree for easy reference. But since (a) we don't plan to vendor anything else and (b) even pretty_bad_protocol will go away in some future (breaking!) release, I'll get over it. :-)

[legoktm]

I wish we'd used something like vendoring (however unsupported) to add another layer of separation between the upstream code we've vendored and our local patches to it; at the very least, I wish we'd marked or logged the patches in the vendored tree for easy reference.

I know I used the term "vendoring" in the initial task description and PR that brought in pbp but really I think this is more of a forking rather than vendoring. There is no upstream to follow, so I don't see the value in clearly identifying patches or tooling to facilitate importing hypothetical newer versions.