New gpgme 0.3 release

[Pawel Salek]

On 2003.11.23 22:41, Werner Koch wrote:
> 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  
> err

I am not sure whether I am aware of all the relevant details but if the  
task is to be able return (CODE_SHARED_BETWEEN_APPLICATIONS, 
APPLICATION_CODE) tuple, there are much more convienient ways to do  
that than adding new libraries. The same holds for consistent  
translations.

> > 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.

That's a very good idea but how does it conflict with the scheme I  
described above? Spawning a process to securely process sensitive data  
is an implementation issue of libgpg. I assume you want to avoid  
mistakes that plagued ssh or openssl but I wonder whether this approach  
just not sweeps the problem under the carpet and by decreasing  
probability of an implementation bug increases a chance that there is a  
configuration mistake or users will plainly refuse to use GPG because  
of too many configuration problems. Security problems can be avoided by  
controlling complexity and clean interface design. I can imagine that  
the interfaces become cleaner but what about complexity?

> 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.

I am not sure we have the same understanding of a linking process. Even  
if all these three libraries were in merged in a single file, only used  
objects would be linked in the gpg-agent binary and obviously unused  
modules would not affect it.


> > 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)

Accepted!

> and that we won't do any specific packaging - that's RedHat's or
> Debian's due.

My opinion is that packaging is for the user. I am now not complaining  
on behalf of redhat: I am sure if they had a problem with the spec file  
provided with gpgme they would just fixed it and moved on. I am  
complaining on behalf of an ordinary user who would like to install  
software with as little hassle as possible. I would be much happier if  
the spec files provided by Axel were merged in and distributed with the  
next release.

Pawel