export-filters act on subkeys?

[Phil Pennock]

This is a wishlist item for cleaning the interaction, with a driving
use-case and an example of how I work around it right now.

Problem scenario: needing to update PGP key in various places after
subkey/uid updates, but discovering all sorts of services which break
horribly when they receive PGP keys with subkeys using unsupported
types, instead of just ignoring those subkeys.  I file bug-reports, but
responses come back to "Bouncy Castle does this, too hard to fix".

So I need to be able to easily export my key with filtered subkeys, so
that I get newer RSA subkeys out there, even while not able to use the
ed25519/cv25519 subkeys.

It seems that the sanest way to do this, which would ease migration for
most users, would be to extend `--export-filter` (and `--import-filter`)
to add `drop-subkey` for both export and import; add some properties
based on the subkey, and add something to the EXAMPLES section showing
the use of a good filter expression.

Does this seem sane?  Is there a better way?

My workaround involves creating a temporary GNUPGHOME, scripting
--command-fd interaction with gpg (with a sleep hack!) and ... works.
So I'm not blocked, so not feeling enough pain to commit to implementing
the filters, but if there's support for the idea from the maintainers,
then I might see what I can do.

https://gist.github.com/philpennock/e3426d21f9beb3fbf679229cad1224aa

Folks shouldn't have to do that.  Extending to new key types is going to
be painful enough.

(Example script hard-codes filename prefix, working dir, keyid and gpg
executable name, deliberately not productionising this to be useful by
those who can't edit shell scripts, to avoid spreading bad behaviour).

Thoughts?

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: </pipermail/attachments/20160904/f9a9c990/attachment.sig>