Re: Upcoming GMime 3.0 changes



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.

Attachment: pgpx31iQwaJhL.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]