-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I keep bothering you with more GnuPG stuff...
Attached is a patch against today's cvs which improves the detection of
broken GPG messages and adds OpenPGP (RFC2440) support. Details:
Files libbalsa/rfc3156.[hc], src/balsa-message.c, src/print.c:
libbalsa_is_pgp_signed() and libbalsa_is_pgp_encrypted() now detect if a
body is multipart/{signed|encrypted} with a correct or broken structure.
Use this information in src/balsa-message.c if a multipart/{signed|
encrypted} to pop up a warning if the structure is broken (sylpheed 0.8.0
sends such messages; thanks to Steffen Klemer for this information). src/
print.c must also be touched as the return type of these functions changed.
Files libbalsa/rfc3156.[hc], libbalsa/send.c, src/sendmsg-window.[hc]:
The bulk of changes is support for RFC2440 signing/encryption (aka
OpenPGP). This seems to work perfectly for exchanging messages with pine/
pgp4pine, but as '2440 is much less explicit than '3156, I hope I can get
some input from the experts, especially Laurent Cheylus who worked with it
for a long time.
Basically, '2440 supports signing and/or encryption for the first part of
a message only. There is *no* support for multipart messages! (Laurent, I
hope I got the principle right here? At least it's the same pine does...)
On the ui side, there are two radio items in the options menu to select
MIME (RFC 3156) or OpenPGP (RFC 2440) mode. If a user tries to send a
multipart message (like this one) in OpenPGP mode, a warning will appear.
When sending a signed message, line endings are converted to the canonical
form, then the signed message block is generated (requested by the RFC).
They are always sent in quoted-printable encoding (not a request by the
RFC as for '3156, but should be extra safe...).
Encrypted messages are *not* converted to the canonical form before
encryption, as OpenPGP doesn't request it and provides the extra armor.
This works perfectly with pine, but might disturb Winbloze clients. I
would be really interested in any experiences!
The routines for this are (from libbalsa/rfc3156.c)
libbalsa_rfc2440_sign_buffer() and libbalsa_rfc2440_encrypt_buffer(), both
called from libbalsa/send.c.
Upon reception, libbalsa_rfc2440_check_buffer() checks a body for the
characteristic '2440 strings. If they are found, the buffer is decoded
using libbalsa_rfc2440_check_signature() or
libbalsa_rfc2440_decrypt_buffer(). As we don't have an extra MIME part to
display the signature's status, it is simply appended to the message.
As libbalsa_rfc2440_check_signature() works with the decoded and
libbalsa_utf8_sanitize'd data, it *may* fail erroneously when the sending
mua used a wrong character encoding, thus leaving ?'s in the converted
buffer (the new guessing of charsets doesn't help as I have to convert it
back to it's "native" == heder defined charset for signature checking).
IMHO, this is a bug in the sending MUA, and we should not invest too much
time to compensate for that (we had to read the raw stream, possibly
decode quoted-printable, and then check the signature, just because some
other people are not willing to read RFC's!).
It might also be necessary to strip extra \r chars after decrypting.
Again, pgp4pine does *not* insert them, and I had no other mua for testing.
As always, I am interested in *any* comment on this!
Cheers, Albrecht.
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Albrecht Dreß - Johanna-Kirchner-Straße 13 - D-53123 Bonn (Germany)
Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de
_________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+jd5ln/9unNAn/9ERAhT5AJsGghXCQpt8TwXZqv788UuZkmRVNgCgh2Dj
S3OcRcRwgTBzidQS11WB1Ck=
=k4tm
-----END PGP SIGNATURE-----
balsa-rfc3156-patch-2003-04-04.bz2