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? 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>).
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 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? This would be *wrong* as not the complete part is protected! Just dropping the stuff not covered by the signature would also be wrong as information is lost. IMO the only solution is to create a chain of three text/plain chunks in this case, containing the first, second and third line, respectively, and only the 2nd part would have an associated signature info. You may think of even more weird cases, like multiple signed/encrypted blocks within a single text part. However, a not too rare situation is a footer being appended outside the signed matter, i.e. only the 2nd and the 3rd part would exist in the example above.
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.
IMO its safe to limit this approach to text parts. Cheers, Albrecht.
Attachment:
pgp7Gr6fAg9zp.pgp
Description: PGP signature