GNOME.org
 

RE: Upcoming GMime 3.0 changes

Hey Albrecht,


-----Original Message-----
From: Albrecht Dreß [mailto:albrecht dress arcor de]
Sent: Tuesday, March 14, 2017 4:39 PM
To: Jeffrey Stedfast <jestedfa microsoft com>
Cc: balsa-list gnome org
Subject: Re: Upcoming GMime 3.0 changes

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.


Except that the gpgme state gets wiped out in the very next operation you perform on the context (or if the 
ctx gets freed).

So it *is* useful to copy it (especially now that a # of the API's internally create their own ctx and then 
free it when they are done). Plus it provides an abstraction... which can be nice.




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]).


I'll check them out.



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...


GMime has actually had a gmime-stream-gio.[c,h] since at least 2.6 (also in 3.0).



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.


If there's a way to clone gpgme keys, I'll look into it... I just don't want them to get wiped out if you 
hold onto the keys but perform another op (or free the ctx).

Perhaps I can have a void *raw_key or something... so that you can pass that ptr directly to gpgme.




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!


Abstraction 😊




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?
;-)


I'll add NO_COMPRESS.

I was actually just looking at the GPG plugin for Mail.app on Mac and apparently they have an option to 
enable symmetric...

Maybe it makes sense to expose for mail after all?

BTW, I can probably just map the GMimeEncryptFlags 1:1 with gpgme_encrypt_flags_t - that's what I've done 
with most of the other crypto enums.




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!


I'm mostly just providing an abstraction 😊




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...


Hah 😊




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.


Hmmm... perhaps that is a good way of doing it.




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.


GMime will only parse them if the GMimeRfcComplianceMode has been set to LOOSE. If you set it to STRICT, 
it'll still fail.




Ah! Thanks for the catch! I'll fix that up...


You're welcome...


Fixed, btw, and also improved a bit so that the parser can verify that the markers come in the appropriate 
pairs and order.




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.


I added support for the simple cases already, but not for re-assembling. After decrypting/verifying, it 
currently just replaces the content of the GMimePart w/o trying to merge.

I'll looking into merging but that might only be safe if the content-type is text/plain, otherwise bad stuff 
would happen if you merged a mailing-list footer into binary content or something.

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