Re: Help with GPG implementation

["Peter A. Kimball" <pkimball hamilton edu>]

Hello again:

I realize that, at the very least, from a security standpoint invoking gpg as an
external program and piping things around is very, very bad (very insecure at
the least).  I have looked into ways around this for security (and simplicity)
reasons, but have not found anything useful.  I have talked with the maintainer
of gpgp, a gnome frontend for gpg, who pointed me at the Privacy Guard Glue
routines, which seem to have the same goal as glibcrypt.  I attempted to speak
with their maintainer, but have received no reply.  It appears to be a dead
project and rather than force Balsa to include a libary which is unstable and
unmaintained, I decided to look elsewhere.  In reviewing code from other
projects, notably gpgp and seahorse (both are gnome frontends for gpg, linked to
from the gpg homepage), both invoke gpg as an external program and do lots of
piping.

I did attempt to reuse code from these projects, but found that the methods used
by both projects would not work within Balsa.  The code, to me at least, seemed
overly complicated and much more involved than seemed necessary.  Seahorse even
used global variables.  Wow.  I have attempted to write code that will be
reuseable and easily replaceable, if/when a library becomes available.   With
all due respect, I checked out libgcrypt this morning, and decided it is not
worth implementing immediately.  For those of you who haven't checked / don't
know about libgcrypt, the last message on their mailing list is Carlos's message
referring to his Zurich project and asking about the status of the project,
dated 6/22.  Libgcrypt is also only available for a gpg version which is not
stable or publically released.  When it becomes widely available and stable,
then and only then can I see its inclusion in this project.

As it stands now, the code for my implementation of gpg in balsa should be very
reuseable.  After dealing with all the problems and confusion from trying to use
code from the other projects mentioned here, I really want to do things simply
and cleanly.  I am hoping to make some of the code I've done available soon, but
at the moment, as there is no GUI for the encryption pieces, a lot of stuff is
coded into the implementation for testing purposes  which should not be.
(passwords for decrpytion / signatures, outputs for debugging, fun stuff like
that).  Rest assured these will be taken care of, neatly. My goal is to have two
functions to deal with gpg: one for use when gpg needs a password, and one when
it doesn't.  They will be passed the pertinant information (which recipient(s),
message text, etc) and not rely on anything specific to balsa. This should make
them easily portable to other projects, until the glibcrypt libary renders them
useless. :)

Pawel, I think that looks like a great place to do the work.  I had tried doing
it a couple of lines up, after checking to see if the message was ready to send,
but before the bsmsg2message function.  Inside the bsmsg2message seems to be a
fine place.  As far a decryption goes, I hope to have a system implemented
eventually where you can choose whether you want your messages saved to disk in
clear-text (unsafe) or encrypted.  To start off with though, I think we'll
decrypt before writing to disk... I haven't looked at that too much (shame on
me).

Anyhow, I hope that answers any questions you might have.  I've tried to answer
stuff as best I can, if you need clarification or just need to flame, feel free
to say something. :)

Peter Kimball
pkimball@hamilton.edu



Carlos Morgado wrote:

> On Mon, 03 Jul 2000 12:52:16 Pawel Salek wrote:
> >
> > On 2000-07-03 11:04 Carlos Morgado wrote:
> > > What are you doing ? Invoking gpg as an external program ? That is
> > Wrong.
> > > Actually, that is wrong in 2 ways. Way 1 is you shouldn't (need to)
> > invoke
> > > gpg. There is something called libgcrypt on gpg1.1 that adresses
> > that.
> > > Way 2 is you shouldn't just be writting support for balsa. It's almost
> > as easy
> > > to write gpg support for gnome.
> >
> > <flame>Whatever the method is, it's much better than vapourware
> > :-)</flame>.
>
> nod :) that's what i said towards the end :)
> i'm pretty much tied by the grinding halt of libgcrypt :\
>
> this is the way used by spruce and one the main spruce guys, i forget
> which, agrees this is the wrong way.
>
> > Frankly, I hope that you Peter use the "right" method that can be also
> > used in the future by other projects. Code reuse is a dream of zillions of
> > programmers :-).
> >
> > Concerning the right place for encryption (when sending), I think one
> > could place it just after src/sendmsg-window.c:1252 (bsmsg2message()
> > funct)
> >
> >   body->buffer = gtk_editable_get_chars(GTK_EDITABLE (bsmsg->text), 0,
> >                                       gtk_text_get_length (
> >                                          GTK_TEXT (bsmsg->text)));
> >
> > The question is of course, if the attachments are to be crypted too (I
> > admit I am not very familiar with the methods/possibilities). The
> > alternative place is just after bsmsg2message() invocation but I am not so
> sure
> > about this one.
>
> the mutt approach seems nice (UI). mutt creates the email (attach list,
> attachs) and then encrypts the whole thing. you could also give the option
> to crypt attachments separetly (there zurich would come in handy - i'm
> planning a "save this file crypted" service)
>
> >
> >  I don't know really where to place the decryption call; AFAIK balsa
> > decodes messages to /tmp directory so it would be better to decrypt AFTER
> > reading decoded messages from disk.
> >
> you need to save a decrypted tmp to disk and then open that. ideally you pipe
> the mail to gpg and pipe it back to balsa without disk tmps
>
> > /Pawel
>
> /chbm/more_words_than_code :)
>
> --
> Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/
> -- gpgkey: 0x1FC57F0A
> http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
> Software is like sex; it's better when it's free. - Linus Torvalds
>
> _______________________________________________
> balsa-list mailing list
> balsa-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/balsa-list