Re: Upcoming GMime 3.0 changes

[Jeffrey Stedfast <jestedfa microsoft com>]

Looks like there’s gpgme_result_ref/unref() and gpgme_key_ref/unref()

Jeff

On 3/14/17, 5:02 PM, "balsa-list on behalf of Jeffrey Stedfast via balsa-list" <balsa-list-bounces gnome org 
on behalf of balsa-list gnome org> wrote:

    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
    
    _______________________________________________
    balsa-list mailing list
    balsa-list gnome org
    https://mail.gnome.org/mailman/listinfo/balsa-list