Interesting. So the problem is not actually the Key-Type, but that the default key-type requires a Key-Curve parameter which has no value by default

Ingo, I concede it might be considered a bug on Request Tracker that it does not allow to specify the key as a fingerprint (or calculates it automatically from the email instead of relying on gpg doing it), but you generally want to keep expired keys around for decryption.

Sorry, Werner, but I have to disagree on this. Specifying them by fingerprint only works if you have a specific field for the key (including the case where you are just it on the config file).

Do note there could be subkeys as well.

I recently stumbled upon this as well.

I agree. Any automatic use of the embedded filename will be potentially problematic security-wise. The only safe use is probably as a value in an interactive dialog, and even then, only if the user doesn't accept a dangerous value.

This was reported again 3 years later as T4704, and finally fixed in gnupg-2.4.4, released last week.

it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

Option #1 is good from a descriptional POV, but in most cases both the main key and the subkeys will be expired, so it would end up not updating any subkey.

The surprising thing is that it works at all. I wouldn't be surprised if certain would simply reject it as "not a pdf" given that the "%PDF-1.x" marker isn't at the beginning.

It may be preferable to get that under 4.0 or later, so you don't need to contact every contributor again if in some years there is intention to switch to a newer version released by Creative Commons.

Maybe have gpg-wks-client(or also --export-filter) print a warning if the filtered result has a key expiration different than the original key? That seems the simplest way tp approach the problem.

I would add "Provide a verbose message of why the key cannot be imported".

Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)