For Gpg4all we want to add that Kleopatra is registered for File Extensions in
Windows. For that I'm using gpgme_data_identify.
What I am missing there:
CRL detection is not really important. But detection of binary data is so that I
can properly handle .pgp and .gpg file extensions.
Detached signatures are also important so that I can look / guess for the signed
data and setup the verify operation accordingly or handle it in the GUI if no
Data is found. Maybe we can use flags for this so we don't break the current
behaviror that does not distinguish between detached signatures?
Would it be possible to also detect if data should be decrypt_verified or just
verified?
I'm having trouble with PGP MESSAGES that can be either encrypted or Opaque
Signed, or nothing.
If I do a decrypt_verify I get a No Data error in the result because decryption
failed. Should I just ignore No Data error and check for the status of the
signatures in that case?
I need to implement a partial OpenPGP parser to decide what a certain PGP
Message is about and also bot all binary OpenPGP files. Please have some patience.
Binary PGP messages are now detected. Not well tested but the run-verify test
tool can help to check the feature.
Thanks.
I've created some examples to test it. They are all done with alfa@example.com
test key. Found an issue through that.
-ba (detached ascii armored signature) is detected as PGP-Signed and not as
PGP-Signature.
examples/plain.txt.asc: PGP-signed
A discussion about KMail handling PGP/Inline encodings [1] also makes me wonder
if data_identfiy should also return the output charset of text messages if it is
provided in the Armor Header. Afaik there is currently no API in gpgme to check
this and semantically It would make sense to me to parse this in identify, too.
But this is more of a question wether or not you think it makes sense to do this
directly. I'm not strongly opinionated about this.
Fix for the difference in detection of armored vs. binary detached signatures
was trivial so I've pushed it with rev. 570bf2a
Looks good to me know. I'll start using it in Kleopatra and we will see what
breaks :-)
Have not tested different S/MIME messages yet.
I also created a set of examples messages. They are in
gnupg/tests/openpgp/samplemsgs/
I think that the charset header in the armor is not a good idea. In fact gpg
does not consider it at all. The armor headers are not protected and thus they
should not not chnage the semantics of the encrypted message. There is also no
way to keep this information after removing the armor or to re-create the header
from a binary message.
I consider a new flag for the Literal Data Packet to indicate theat the content
is a MIME message to be better. Standard MIME methods can then be used to
describe the content. Right now we only have an 'u' flag to indicate UTF-8
encoding (which to some interpretation of OpenPGP is anyway the default).
An 'm' flag would make it explicit that the content is MIME encoded and there
would be no more need to derive that info from the context.
While the detection works now to distinguish between PGP and S/MIME data it
might be more robust if it would do some more sanity checking on the packet.
E.g. PNG Graphics are detected as PGP Signatures because they start with 0x89
But this is not super neccessary as for the use case of file extension support
valid data will be detected correctly.