Hi Jeff: Thank you so much for this information!
I believe your new lib will simplify many parts in Balsa (but we probably still need to support the old GMime 2.6 based stuff until all LTS distos switched to the new one). Some comments below... Am 13.03.17 23:38 schrieb(en) Jeffrey Stedfast via balsa-list:
2. Next up is the replacement of the old custom GnuPG back-end with GpgMe. Also included with this change is full support for S/MIME via both multipart/signed and application/pkcs7-mime content-types using gpgsm (via GpgMe).
That's cool! You may recall that I never used your GMime GnuPG implementation in Balsa, but implemented my own solution on top of GpgME more than 10 years (IIRC) ago, which is working just fine afaict... ;-)
During this change, I also took the liberty of simplifying the crypto API's a bit and so I was able to make it such that g_mime_multipart_signed_verify(), for example, no longer requires you to pass it a GMimeCryptoContext. Instead, GMime parses the Content-Type's protocol parameter and uses that to instantiate the correct crypto context (GMimeGpgContext for PGP and GMimePkcs7Context for S/MIME).
Also very nice!
Many of the various state properties have been replaced with bitflags that can be passed to encrypt() and decrypt(). The sign() method now also takes a detach argument (might make this into a bitflag instead?) in order to support encapsulated signing.
Do you have some more documentation about this? It would be interesting to know how this approach could fit with the current GpgME-based implementation in Balsa.
4. New in GMime 3.0 is the GMimeParserOptions struct which can be passed to GMimeParser and other parser functions exposed in the lower-level API's. This structure helps define how strict/forgiving the various parsing routines should be with the input. This replaces the need for g_mime_init()'s flags so you can change these settings on the fly now.
It would be *really* cool if the parser could optionally collect and provide information about violations of the various rfc's encountered during the parsing process. Maybe something like a linked list containing the stream offset, a unique code and a comment, or something similar, with an upper limit of items collected. This might provide valuable information for spam and/or malware checking (and would be *a lot* more performant than the perl/python based parsers typically used, I guess). Not related to Balsa, but to an other project I'm working on...
6. Brand new rfc822 address parser which is more tolerant than the previous generation parser. What's not to love?
Same as above - please provide more information about the rfc violations...
7. And finally we get to a nifty feature that I just hacked up while waiting for some other code to compile (hey, it takes an hour to compile... I needed something to do!) which is that GMimeParser now scans for -----BEGIN PGP MESSAGE-----/-----END PGP MESSAGE----- and -----BEGIN PGP SIGNED MESSAGE-----/-----END PGP SIGNED MESSAGE----- markers while looking for MIME boundaries and sets some state on the corresponding GMimePart that you can use to quickly decide if the part contains encapsulated OpenPGP data
That's also a nice feature (and again something I implemented in Balsa more than a decade ago). In case of a cleartext signed message, the header lines to look for are (in this order) "-----BEGIN PGP SIGNED MESSAGE-----", "-----BEGIN PGP SIGNATURE-----" and "-----END PGP SIGNATURE-----", btw. (see RFC 4880, sect. 7). You might want to limit the check to text parts; malware spammers recently added fake OpenPGP blocks to M$ office documents containing malicious macros. Looking forward to the new release, Cheers, Albrecht.
pgpo07thTv2Lm.pgp
Description: PGP signature
_______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
