Hi Jeff: Am 15.03.17 19:58 schrieb(en) Jeffrey Stedfast via balsa-list:
Sadly Outlook sucks at quoting replies… so forgive me for the suckage (
No problem, I can identify your answers...
Looks like I never added it to the docs :-\ I’ll have to fix that…
For Balsa, it's done with changing exactly three lines, plus removing two files...
I mostly have strict mode so I can satisfy my OCD about having a strict parser ( The defaults are all LOOSE.
I see.
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.
Sorry, I was unclear here - of course I referred to the verification status here, and mixed up the part representation in GMime vs. Balsa.
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?
I was thinking of a way to get the verification result of the armoured part *and* an information if it covers the whole part. This is the behaviour of KMail, which keeps all text in this case, but marks the part of the text/plain which has actually been signed. Please excuse me if my description was unclear... Thinking again, three text/plain parts is also not the proper approach, as from the MIME pov it's still /one/ part. Maybe it would be possible to glue the lead, the verified part, and the footer together in the result text buffer, and to add extra fields in the verification status indicating the start and end offset of the armoured section in it (in the typical case, the start would be 0, and the end the text length). This would be absolutely sufficient for the KMail-like display.
That sounds awkward,
Yes, it is. In particular as RFC 4880 has never been designed for such a use case. With the proper method (i.e RFC 3156) these problems can never occur!
especially once you start handling multiple armored sections in the original text/plain part.
These are really pathological cases. As a pragmatic approach, you could treat just the first section as above, and keep the remainder "as is". It's then up to the caller to verify or decrypt again, until no armoured section is left. I never saw such a message yet, btw., and I don't know how other MUA's would deal with it...
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.
IMO you could keep things simple here, too. A RFC 4880 block with extra text is actually a misuse of the standard, and a mailing list processor adding text is somewhat broken. Just add a documentation about the limitations, and don't waste too much brains for a really weird case. Cheers, Albrecht.
Attachment:
pgpdU7bHocdQa.pgp
Description: PGP signature