Mailing List Archive

On Thu, 10 Feb 2000, Anthony Clark wrote:

> I recently posted to netscape.public.mozilla.crypto about OpenPGP support in
> the Mozilla mail/news components. I wanted to reuse code from gnupg (Yes, I
> am lazy!), but I was warned of probable GPL violations if I did this.

Yes, the MPL and the GPL are not compatible. But you don't have to
link them together. Just use fork/exec to run gpg - this is perfectly
legal. There is also a special interface to control gpg from another
program (see tools/shmtest.c). A more convenient way would be to use
the PGG wrapper library, this is also GPLed but maybe we can
convinmce Michael to make an exception for MPL. I am very interested
to make Mozilla (or even Netscape) OpenPGP aware.


Werner

Werner Koch wrote:

> On Thu, 10 Feb 2000, Anthony Clark wrote:
>
> > I recently posted to netscape.public.mozilla.crypto about OpenPGP support in
> > the Mozilla mail/news components. I wanted to reuse code from gnupg (Yes, I
> > am lazy!), but I was warned of probable GPL violations if I did this.
>
> Yes, the MPL and the GPL are not compatible. But you don't have to
> link them together. Just use fork/exec to run gpg - this is perfectly
> legal. There is also a special interface to control gpg from another
> program (see tools/shmtest.c). A more convenient way would be to use
> the PGG wrapper library, this is also GPLed but maybe we can
> convinmce Michael to make an exception for MPL. I am very interested
> to make Mozilla (or even Netscape) OpenPGP aware.
>
> Werner

A couple of random thoughts:

James Clark distributes expat under the MPL by default, but he allows distribution
under the GPL in special circumstances (e.g. to let expat ship with GPL software).
Couldn't GnuPG do the reverse?

Also, what are the chances that core GPG functionality will become a runtime
library? If that happened, then presumably the LGPL (which most libraries use)
would mean that Mozilla could link to it with no problems.

--
Adam Lock

On Thu, 10 Feb 2000, Adam Lock wrote:

> James Clark distributes expat under the MPL by default, but he allows distribution
> under the GPL in special circumstances (e.g. to let expat ship with GPL software).
> Couldn't GnuPG do the reverse?

I think this would be bad for GnuPG. A dual licence for the PGG wrapper
library would be OK.

This is actually a question about Open Source versus Free Software.

Regards,

Andreas Bach Aaen System Developer, M. Sc.
Ericsson Telebit A/S tel: +45 86 28 81 76
Fabrikvej 11 fax: +45 86 28 81 86
8260 Viby J Denmark e-mail: aba@tbit.dk

On Thu, 10 Feb 2000, Adam Lock wrote:

> Also, what are the chances that core GPG functionality will become a runtime
> library? If that happened, then presumably the LGPL (which most libraries use)

There will be no gpg library for security reasons. The fork/exec overhead
is not that high compared to the cryptograhic operations. And a
wrapper libray may decided to run gpg in a loop which is already done
for key managenent tasks. Basically this is a kind of CORBA service
but not implemented with an ORB but with a simpler method because the
security implications using CORBA and a security enabling software are
not well understood yet.

Werner

>>>>> "Werner" == Werner Koch <wk@gnupg.org> writes:

Werner> There will be no gpg library for security reasons.

That is a reasonable reason to veto a shared lib, but what about a
static one?

-JimC
--
James H. Cloos, Jr. <URL:http://jhcloos.com/public_key> 1024D/ED7DAEA6
<cloos@jhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Like this email? Click: <http://rootworks.com/twocentsworth.cgi?101777>

Werner Koch wrote:

> On Thu, 10 Feb 2000, Adam Lock wrote:
>
> > Also, what are the chances that core GPG functionality will become a runtime
> > library? If that happened, then presumably the LGPL (which most libraries use)
>
> There will be no gpg library for security reasons. The fork/exec overhead
> is not that high compared to the cryptograhic operations. And a
> wrapper libray may decided to run gpg in a loop which is already done
> for key managenent tasks.
>
> Werner

I'm not sure I understand the security reasons for not having GPG in a library.
Presumably someone dastardly enough to swap out the library (assuming it's dynamic
shared) for one of their own could easily do the same with the GPG executable. In
which case, where's the increased harm of having a library?

Besides, if this were an issue, then the library could be built and linked
statically. I've seen quite a few libs that can build dynamic or statically via a
configuration switch.

I understand that PGP is available as an SDK. Surely they couldn't do this either if
they were faced with the same issues concerning libraries as GPG is?

--
Adam Lock

On Thu, 10 Feb 2000, James H. Cloos Jr. wrote:

> That is a reasonable reason to veto a shared lib, but what about a
> static one?

Did you remember that GnuPG can be run suid(root) - it is quite hard to
make a secure setuid program.

Another reason is that bad code in the main program might overwrite
some data areas of gpg - when gpg runs as it's own process, this is
not possible.


Werner

On Thu, 10 Feb 2000, Adam Lock wrote:

> I understand that PGP is available as an SDK. Surely they couldn't do this either if
> they were faced with the same issues concerning libraries as GPG is?

They do it because PGP 5 or 6 is not so flexible as GnuPG ;-)

Have you ever asked yourself why gcc does not incorporate the linker
and assembler but leaves these jobs to specialized programs. Dividing
software into modules is good engineering practice and if you have the
opportunity to do information hiding you should do so. Of course
there are some application which needs as most performance as they can
squeeze out of the system and therefore the modules are linked
together. As I already mentioned, the resources needed for process
creation and IPC between a program and gpg are much less than the
resources gpg needs for its processing.


Werner

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 10 Feb 2000, Werner Koch wrote:

> program (see tools/shmtest.c). A more convenient way would be to use
> the PGG wrapper library, this is also GPLed but maybe we can
> convinmce Michael to make an exception for MPL. I am very interested

I will release PGG with a dual license next week because I'm interesed in
a wide spread usage of OpenPGP too. Please be patient.


cu
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0e (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4ovPwAJxC28xc8YIRAs+jAKCw6dCU+BZXGPdErjh3tup091GL4gCdFUph
bgB4NzuiFC76bee8dgf0zVo=
=tfQs
-----END PGP SIGNATURE-----

On Thu, 10 Feb 2000, Werner Koch wrote:

> On Thu, 10 Feb 2000, Adam Lock wrote:
>
> > I understand that PGP is available as an SDK. Surely they couldn't do this either if
> > they were faced with the same issues concerning libraries as GPG is?
>
> They do it because PGP 5 or 6 is not so flexible as GnuPG ;-)
>
> Have you ever asked yourself why gcc does not incorporate the linker
> and assembler but leaves these jobs to specialized programs. Dividing
> software into modules is good engineering practice and if you have the
> opportunity to do information hiding you should do so. Of course
> there are some application which needs as most performance as they can
> squeeze out of the system and therefore the modules are linked
> together. As I already mentioned, the resources needed for process
> creation and IPC between a program and gpg are much less than the
> resources gpg needs for its processing.

So in other words, if you need a library, write a library that
uses fork/exec to use a gpg binary?

--
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue
mailto:billy@escape.com
http://www.escape.com/~billy

On Thu, 10 Feb 2000, Billy Donahue wrote:

> So in other words, if you need a library, write a library that
> uses fork/exec to use a gpg binary?

And there is such a library, named PGG and available at the devel area
of ftp.gnupg.org and it's mirrors.

Werner

On Thu, 10 Feb 2000, Werner Koch wrote:

> On Thu, 10 Feb 2000, Billy Donahue wrote:
>
> > So in other words, if you need a library, write a library that
> > uses fork/exec to use a gpg binary?
>
> And there is such a library, named PGG and available at the devel area
> of ftp.gnupg.org and it's mirrors.

Well, that should settle it!

--
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue
mailto:billy@escape.com
http://www.escape.com/~billy