Am 08.08.04 20:43 schrieb(en) Jeffrey Stedfast:
the only problem I have with this is that it might inadvertently munge the data. GMime doesn't use tabs when folding headers, for example, for
[snip description of header folding scheme]
goes out the window (in the case that the string started unfolded with a \t and the fold just so happened to fall at that position).
Ah, I see.... Yes, this is a really interesting feature, going beyond the rfc requirements.
GMime also uses \t as a hint when folding "there's a \t here, there's a good chance this is where it was folded previously" this bit is mostly a hack to try and get the header folding to re-fold where it was originally folded for the signature validation code (was the best I could do without breaking ABI). ideally of course, each part would probably have to have a raw copy of the entire header block, but oh well.
Well, to be honest, I would actually prefer a bullet-proof abi/api for multipart/signed and have the fuss to re-write parts of balsa's crypto code. I am almost sure that the guessing code above will break in some very special cases, leading to endless complaints that balsa doesn't verify some messages properly whereas mozilla/kmail/whatever do.
BTW, an other problem seems to be that sometimes double quotes from boundary args are not passed properly downstream to the crypto engine, which looks like a much more serious (== difficult to fix w/o raw headers) problem to me. *All* my old signed messages sent with balsa 2.0 where the multipart/signed is again a multipart still report a broken signature with gmime 2.1.7! Of course, both problems would easily (from the crypto pov, not yours who had to add the code ;-)) be fixed when a raw header (or part including sub-parts) stream would be available.
I see two other points where the current abi/api may not be sufficient:* combined signed and encrypted messages according to rfc 3156, section 6.2. In this case, the sender doesn't create a multipart/signed and puts it into a multipart/encrypted, but signes the multipart/encrypted using the combined OpenPGP method. This method is used by mozilla/enigmail. So the gmime decrypt method should have a way to report a signature status as well (in balsa I use my gmime-gpgme context for that - not yet in the code/cvs, but almost ready).
* rfc 2633 (S/MIME, if you ever want to support it) may be problematic as it supports multipart/signed as well as the single-part application/pkcs7- mime protocol which may carry both signed and encrypted data. Not sure how to support it painlessly in gmime, maybe a gboolean "single part protocol" in the cipher context might help?
* *if* you decide to support any combined and/or single part protocols, rfc 2440 would be a natural enhancement. In balsa, I do this again by using my "special" gmime-gpgme methods.
Again, just my € 0.01...
Cheers, Albrecht.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Albrecht Dreß - Johanna-Kirchner-Straße 13 - D-53123 Bonn (Germany)
Phone (+49) 228 6199571 - mailto:albrecht dress arcor de
_________________________________________________________________________
Attachment:
pgpH1BlIFkFN4.pgp
Description: PGP signature