fejj at ximian.com
Tue Jun 11 20:33:01 CEST 2002
On Tue, 2002-06-11 at 03:32, Werner Koch wrote:
> On 11 Jun 2002 02:15:27 -0400, Jeffrey Stedfast said:
> > First, I assume that Gpgme is GPL?
> > Would you be willing to change the license to LGPL? I'd be very
> No, definitely not. We did this for Libgcrypt but GPGME is a
> different thing and the general rule applies:
> Please note that in many cases it is better for a library to be
> licensed under the GPL, so that it provides an advantage for free
> software projects. The Lesser GPL is so named because it does
> less to protect the freedom of the users of the code that it
> covers. See http://www.gnu.org/philosophy/why-not-lgpl.html for
> more explanation.
disappointing, but I understand
> > Unfortunately, our Exchange Connector product is not GPL (though
> > Evolution itself is) and so I don't think we'd be able to use Gpgme
> Huh? You link you proprietary Exchange Connector with the GPLed Evo?
> > Another question I had about Gpgme (unrelated to licensing) is that it
> > seems Gpgme is planning to have some sort of S/MIME capabilities, is
> > this true? If so, definetely another plus :-)
> Sure, it is already working. The backend is called gpgsm and for now
> available in the newpg package available at
> ftp.gnupg.org/gcrypt/alpha/aegypten/. Eventually this will get merged
> into the gnupg package (as a separate binary and after gpg has been
> changed to make full use of the gpg-agent).
> > How is this S/MIME code going to work? Is it just going to
> > encrypt/decrypt/etc a block of data and leave MIME parsing up to the
> > client application? Or is Gpgme going to do some MIME parsing?
> gpgsm is similar to gpg, so it does not care about MIMEing. GPGME
> also does not know about MIME. I think it is in general better to
> utilize the existing MIME framework of a MUA (which required us to
> hackup the non-existing MIME framework of Kmail ;-).
Yes, I very much agree - which is why I asked :-)
unfortunately OpenSSL tries to do their own MIME parsing which was a
real problem (for the S/MIME stuff).
> > I'd actually prefer that it didn't (this should be the job of the
> > client), but I'll take what I can get :-)
> You should be happy. One thing is not yet implemented: gpgme
> currently copies the data or has to work on a file, but everything for
> using a FD as input or output is already in the API we only have to
> implement it. There is a way to overcome this by using gpgme I/O
> objects (GpgmeData) based on callbacks (actually this is what we are
> going to use internally for FD based data objects anyway.
Yes, I saw these - very similar to our CamelStream's. Unfortunately, I
did not see a way to create a GpgmeData object that could be written to
(other than a file or memory I suppose)?
I saw a gpgme_data_create_with_read_callback() or some such, but didn't
see one for creating with a write_callback which is what I think I'd
> BTW, GPGME will be thread-safe can can make use of GLIB's I/O system.
> Marcus is currently finishing this feature.
Thread-safeness is always good :-)
Jeffrey Stedfast <fejj at ximian.com>
More information about the Gnupg-devel