Hi Jeff: Am 14.03.17 19:47 schrieb(en) Jeffrey Stedfast via balsa-list:
Yea, I do remember this... I think it's one of the reasons that I made the GMime API's return more complete info about signers rather than just good/bad/etc for 2.6.
Balsa uses (in libbalsa/gmime-gpgme-signature.h) a GMimeGpgmeSigstat object, collecting various gpgme data items. IMHO it wouldn't make sense to invent new data types for things already being defined properly in gpgme.
In the end, it just makes sense to use gpgme now due to the fact that it is now installed pretty much everywhere, even my Mac (via homebrew)!
Exactly!
Hopefully you'll be able to reduce your usage of gpgme directly now that GMime uses gpgme 😊
The GMime interaction is wrapped into a few source files (libbalsa/gmime-*.[hc], with the exception of gmime-stream-gio.[hc]). The latter would be a nice extension to GMime, too, in particular as the GIO streams are really powerful. Actually, you could also implement some of the other streams on top of GIO. Feel free to use any part of it... Large parts of the gpgme interaction in Balsa are for proper dealing with keys and certificates (key/cert selection, data display, etc.). As I mentioned above, IMO it would *really* simplify life if GMime would use e.g. gpgme_key_t directly.
When I was moving to gpgme, I noticed that the always_trust flag was one of the gpgme_encrypt_flags_t, so it made sense to use a similar mapping (GMimeEncryptFlags).
I suggest to use the gpgme_encrypt_flags_t enum. I don't see any benefit of just wrapping the existing gpgme values into a new data type!
Of course, ALWAYS_TRUST is currently the only flag for encrypting
GPGME_ENCRYPT_NO_COMPRESS may make sense even for a MUA, at least if the message size is small (not implemented in Balsa yet, though). Symmetric encryption should be supported if you want to keep GMime a universal tool, not strictly limited to a MUA. Again, why re-invent the wheel? ;-)
while EXPORT_SESSION_KEY is the only GMimeDecryptFlags flag. Currently GMimeVerifyFlags has no enum values available (the only one that would have made sense from the old GMime API would be auto-key-retrieve but gpgme doesn't seem to have a mapping for that except, perhaps, if I use the gpgme API for manipulating the configuration, but even then I'm not sure it'd work).
I fully agree with you here, as I don't think that these options (including TOFU as the latest cool invention) should be configured on the MUA level. But you really shouldn't limit gpgme's capabilities - if gpgme has an useful interface, you should /really/ consider to just use it, instead of doing the same just in a different way!
Yea, I've thought about this off and on for at least the past decade... I just haven't done it because it'd make the API's more awkward with another argument. Plus GMime is mostly focused on mail clients that need to do their best to interoperate with everything as opposed to spam traps which might want to use that info for holding mail back.
Well, GMime is also a perfect toolset for dissecting malware spam...
The other problem is that GMime's GMimeParser really only parses the stream into field/value header pairs and individual mime-parts. Parsing of the header values doesn't occur until later, inside of the GMimeObject implementation and so there's no way to pass that info back to the GMimeParser to give back to its caller. I sort of did this with MimeKit (my C# re-implementation fop GMime) using exceptions. E.g. if you set the ParserOptions to use strict(er) rules, it would throw an exception giving you the offset of the beginning of the token, the offset of the error byte, and a description of the error, but C doesn't have exceptions...
A trivial suggestion: as everything in GMime is derived from GObject, just define a signal (e.g. "parse-error") which is emitted with the appropriate data (error code, stream position if available) whenever a recoverable error occurs. This doesn't require any additional parameters, the internal overhead is minimal, but it would add /a lot/ of value to the library.
The main thing I did was to try and work around more common brokenness, such as having addresses like: To: Warren Worthington, Jr. <warren worthington com> (notice the unquoted , and .) Also worked around are things like the ones mentioned in https://tools.ietf.org/html/rfc7103#section-7 I don't think I managed to support *all* of the broken address forms listed in section 7, but I managed to add support for a number of them.
I see. However, I wonder if detecting (and mitigating) them is really necessary for a MUA. Most are an indication for badly crafted spam or malware (as well as some rfc violations coming from MUA's like Lookout, which you also might want to describe as badly crafted malware ;-). It would be highly valuable for detecting spam/malware messages, though, so the information which RFC 7103 rule has been detected would be really cool.
Ah! Thanks for the catch! I'll fix that up...
You're welcome...
The GMimeParser just adds those lines to the list of boundaries it checks for since it's already checking for strings starting with -- 😊 There's no harm in checking for them - it doesn't actually do anything with them.
I don't think it is a security hazard passing these malware office documents into gpgme - it's extremely robust afaict. Anyway, a MUA would probably check only for such headers in text/* parts. Did you think about decrypting/signature checking such (text) parts in GMime? It might be a little difficult as such parts might result in one up to three resulting parts: optionally some unencrypted/unsigned matter before the opening header (missing if the header starts at the very beginning of the part), the signed/encrypted stuff, and optionally some extra data behind the closing header (typically if a mailing list processor adds some lines). Balsa can only handle the case where the part starts with the opening and ends with the closing header (i.e. only one resulting part). If GMime could deal with it, this would be cool. Cheers, Albrecht.
Attachment:
pgpxx8xWuxn5S.pgp
Description: PGP signature