Sadly Outlook sucks at quoting replies… so forgive me for the suckage (
On 3/15/17, 2:14 PM, "Albrecht Dreß" <[email protected]> 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
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
