Re: Upcoming GMime 3.0 changes

[Jeffrey Stedfast <jestedfa microsoft com>]

Sadly Outlook sucks at quoting replies… so forgive me for the suckage (

On 3/15/17, 2:14 PM, "Albrecht Dreß" <albrecht dress arcor de> wrote:

    Hi Jeff:
    
    Am 14.03.17 22:02 schrieb(en) Jeffrey Stedfast via balsa-list:
    > GMime has actually had a gmime-stream-gio.[c,h] since at least 2.6 (also in 3.0).
    
    Ooops.  That one missed my attention, as it apparently never made it into the official docs.  Neither on 
the official web page <https://developer.gnome.org/gmime/stable/Streams.html>, nor in the dpcs package on my 
Ubuntu 16.04 LTS system (libgmime-2.6-doc ver. 2.6.20-1; 
<http://packages.ubuntu.com/xenial/all/libgmime-2.6-doc/filelist>).  Might this be a mistake, or an error in 
the Makefile?


Looks like I never added it to the docs :-\

I’ll have to fix that…

    
    Anyway, it's good news, as we can remove the redundant implementation from Balsa!
    
    > 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).
    
    You can ref and unref them (see 
<https://www.gnupg.org/documentation/manuals/gpgme/Manipulating-Keys.html#index-gpgme_005fkey_005fref>).


Yea, I knew about key refs, but not the result refs.

    
    > 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?
    
    Hmm, might also make sense for Balsa. I'll have to think about the user interface...
    
    >> 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.
    
    I can only stress thit it would be really helpful!
    
    > GMime will only parse them if the GMimeRfcComplianceMode has been set to LOOSE. If you set it to 
STRICT, it'll still fail.
    
    Actually, I wonder if there is a real use case for the strict mode.


I mostly have strict mode so I can satisfy my OCD about having a strict parser (

The defaults are all LOOSE.

    
    I think a MUA will typically try to extract as much usable information as possible.  And probably display 
a warning to the user that the contents was somewhat broken, so the result might differ from what the sender 
intended to show.  This can be achieved easily by catching the parser error signals.
    
    And my analysis tool of course /also/ wants to extract as much information as possible, so further checks 
(like semantic analysis) can be done.  The count and types of error signals occurring would be valuable input 
for the rating mechanism.
    
    > 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'm not sure if I fully understand your approach here.  Assuming you get the following text/plain part:
    
    <snip>
    Some text.
    -----BEGIN PGP SIGNED MESSAGE-----
    More text.
    -----BEGIN PGP SIGNATURE-----
    [Correct Signature]
    -----END PGP SIGNATURE-----
    Some Footer.
    </snip>
    
    would your code replace it by a /single/ text part, containing
    
    <snip>
    Some text.
    More text.
    Some Footer.
    </snip>
    
    plus the meta-information that it had a valid RFC4880 signature?


No, what I mean is that my current code would replace the existing GMimePart’s content with just what is 
armored and the rest would be dropped. In other words, “Some text.\n” and “Some footer.” Would not exist once 
you verified the part.

The code does not add any meta-information to the GMimePart content (that would be very client-specific in 
the way it decided to display that info).

Instead, the verify() method simply returns a list of signatures.

I thought what you wanted from your earlier description was the <snip> section you pasted above, but now it 
sounds like what you actually want is for g_mime_part_openpgp_verify() is to return a GMimeMultipart of 3 
text/plain parts (the lead, the verified text, and the footer).

Is that correct?

That sounds awkward, especially once you start handling multiple armored sections in the original text/plain 
part.

I guess this kills the usefulness of my current implementation as well, though, since the header/footer text 
would get lost.

I guess I had assumed that there wasn’t likely to be a header and any footer that existed would just be 
mailing-list munging which I doubt anyone cares much about keeping.

Oh well…

Jeff