Re: Comments please: gpg/rfc 3156 support for balsa (looong)

[Albrecht Dreß <albrecht dress arcor de>]

Am 27.02.03 01:48 schrieb(en) Laurent Cheylus:
> First, Albrecht it would be better to contact me before releasing your
> patch... We could merge our effort to add GPG support to Balsa in a near
> future ?

I'm sorry if you feel offended in some way because I didn't realise that 
you are still working on this patch... I of course hat a look at your web 
page, but I could only see an old solution for 1.3.6, and as I did not 
want to complain endlessly over a missing feature (*this* is something 
many other people don't like...), I tried it myself. Of course I would be 
happy if we could put together all our knowledge to get it working!!

> I continue to work on GnuPG support for Balsa 1.4.x version (no Gnome2
> at the present time on my workstation) but I have still some problems
> with multi-threading support with GPGME :-(

Can you be more specific here? I did not *really* try multithreading, but 
there is a **BIG** warning in the manual saying that you **MUST** call 
gpgme_check_version() very early in your app if you use mt. However, this 
call is nowhere in your 1.3.6 patch (which is still on my hd). Maybe you 
can use the code snipplet for src/main.c from my solution?

> My work is based on RFC 2440 (OpenPGP in ASCII mode) : this mode (sign
> and encrypt file in ASCII message) is always the most used on Internet
> (signed messages for security alerts is a good example). It's always my
> priority to release a complete patch for Balsa 1.4.x and port it for
> Balsa 2.0.x to support OpenPGP/RFC 2440.

I basically started to work on '3156 as sylpheed uses it, and I wanted to 
have the same feature, but don't want to use sylpheed... Without knowing 
much about '2440, my first impression is that '3156 has better support for 
signing/encrypting multiple parts. Is that right? Maybe both methods 
should be implemented, at least for displaying such messages. What, up to 
your impression, is the preferred method?

> But I saw also some future problems with GPGME version 0.4.0 : some
> functions (gpgme_op_verify, gpgme_data_read...) will be modified or
> deprecated. Your patch will work only with GPGME 0.3.x versions.

If we *really* move to gmime in balsa2 (which I strongly support), we can 
forget about gpgme. gmime talks directly to gpg, and *is* able to 
painlessly encode and decode multipart messages according to '3156 (didn't 
check 2440). Compared to that, all the tricks I did with libmutt is like 
pulling a whale on the beach...

Anyway, if the gpgme api changes, it should not be *that* difficult to 
port it, as all the encoding work itself is more or less trivial. The 
*real* problem was getting a stream which is exactly like the one libmutt 
sends. In this respect, encrypting a message will be even easier as 
gpgme/gpg returns an ascii armored stream. Decryption, however, has it's 
own problems...

> I hope some good news for my patch soon and port it fast to Balsa 2.0.
> Maybe at this point, could we merge our work ?

Sure. Maybe you can have a look at my patch and see what you can use. As I 
said, I only have yours for 1.3.6. Is there any newer release of it?

Cheers, Albrecht.



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
_________________________________________________________________________