New gpgme 0.3 release

Werner Koch wk at gnupg.org
Sun Nov 23 22:41:58 CET 2003


On Sat, 22 Nov 2003 23:12:17 +0000, Pawel Salek said:

> What about including libgpgme in libgpg-error or merging these packages  
> in some other way? libgpgme.tar.gz is less than 300kb which is very  

That would make libgpg-error pretty pointless.  It sole reason for
existance is to allow sharing error codes between different
applications and still allow to deduce the orgin of the error (a major
problem debugging the current Aegypten stuff), having conistent erro
codes and strings and finally to make translation easier.

I agree that the build process is more complicated than with gnupg 1.2
but there are other advantages.

> impression the whole design resembles a patchwork and not a good  
> engineering work (I put my asbesto suit on now! :). Much better design  

Let's see whether you are Red Adair ;-)

> would be to have a single library (call it libgpg) that would come with  
> a basic CLI frontend (program called gpg). If one wants to link
> other  

A single library is a major security problem for larger applications -
they get too complex and parts can't be tested independently. This is
also true for large applications, build from several libraries.  On
almost every OS we have a security boundary we understand pretty
welll, and that is the process.  Thus my dividing a task into separate
and independent processes we will make the entire system more
reliable: All of the smaller applications (modules) can be tested
independently, a bug in one module has a lesser probability to
propagate to other modules, exploiting bugs will get harder, modules
can be indendently audited, the IPC traffic can be audited, modules
are replaceable for specific tasks.

In reality we can't achive eberything but we try to keep the
depndencies as small as possibleand don't link applications to
libraries nt actually needed.  For example: The gpg-agent does only
link against Libgcrypt (low-level crypto) and libassuan (IPC) but not
to a GnuPG library or Libksba (for X.509) or even smartcard code.
Thus a bug in the libksba won't affect the private key management in
gpg-agent.

> libgpg-error is needed and compile and install gpgme as well. spec  
> files contained in gpgme and libgpg-error do not work out of the box on  
> RH9.0 - and Fedora as well (I think the problems are rpm-4 related;  

Please keep in mind that this is work in progess (remember 0.3, 0.4)
and that we won't do any specific packaging - that's RedHat's or
Debian's due.

> ** Message: init gpgme version 0.4.3

> ** ERROR **: Invalid engine for OpenPGP

That's true, but also the way Unix based system work.  It might have
happened that a nasty bug was introduced in sed and the system will
continued to run without problems - except for application foo which
failed on every Sunday.  This is exactly the same situation as with
the modularized GnuPG system.

> (what does it really mean?) and does not give any chance to continue  
> with the encryption support disabled (many programs have GPG support  

That's up to the application using gpgme.  At least - gpgme returns a
proper error code and the application can take any way it likes to
resolve it.

> not as a main functionality but as an add-on). And this is the release  
> recommended for use?

Yep

> 1. building process should be simplified. If people have problems  
> builing the library, they won't bother porting their programs to it.  
> Care should be taken to allow for static linking - very important in  
> case of "semi-stable" libraries with changing api. I could provide spec  
> files for building gpgme and libgpg-error on RH9.0 if there is any  
> interest.

Sorry, it is up to the Distribution to make it fit into their system.
We can't care about this - or wait: Because some of us are also Debian
maintainers we try to make sure that it can be packaged under Debian
without too much problems.

> 2. if the library initialization fails for some reason so that it  
> cannot provide its functionality, it should not abort the whole  
> program.

That's up to the application of course.


  Werner

-- 
Werner Koch                                      <wk at gnupg.org>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe                  http://fsfeurope.org




More information about the Gpa-dev mailing list