Weblog entry #74 for dkg

CryptLib and the OpenSSL License
Posted by dkg on Wed 16 Mar 2011 at 04:40
I spent part of today looking at packaging Peter Gutmann's CryptLib for debian. My conclusion: it may not be worth my time.

One of the main reasons i wanted to package it for debian is because i would like to see more OpenPGP-compliant free software available to debian users and developers, particularly if the code is GPL-compatible.

Cryptlib makes it quite clear that it intends to be GPL-compatible:

cryptlib is distributed under a dual license that allows free, open-source use under a GPL-compatible license and closed-source use under a standard commercial license.
However, a significant portion of the cryptlib codebase (particularly within the bn/ and crypt/ directories) appears to derive directly from OpenSSL, and it retains Eric Young's copyright and licensing. This licensing retains the so-called "advertising clause" that is generally acknowledged to be deliberately incompatible with the GPL. (A common counterargument for this incompatibility is that OpenSSL should be considered a "System Library" for GPL'ed tools that link against it; whether or not you believe this for tools linked against OpenSSL, this counterargument clearly does not hold for a project that embeds and ships OpenSSL code directly, as CryptLib does)

This does not mean that CryptLib is not free software (it is!), nor does it mean that you cannot link it against GPL'ed code (you can!). However, you probably can't distribute the results of linking CryptLib against any GPL'ed code, because the GPL is incompatible with the OpenSSL license.

The un-distributability of derived GPL-covered works makes the CryptLib package much less appealing to me, since i want to be able to write distributable code that links against useful libraries, and many of the libaries i care about happen to be under the GPL.

I also note that Peter Gutmann and CryptLib Security Software (apparently some sort of company set up to distribute CryptLib) may be in violation of Eric Young's License, which states:

 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young (eay@cryptsoft.com)"
 *    The word 'cryptographic' can be left out if the rouines from the library
 *    being used are not cryptographic related :-).
A Google search for Eric Young's name on cryptlib.com yields no hits. I do find his name on page 340 of the Cryptlib manual, but that hardly seems like it covers "All advertising materials mentioning features or use of this software". I suppose it's also possible that CryptLib has negotiated an alternate license with Eric Young that I simply don't know about.

In summary: i think CryptLib could go into debian, but its incorporation of OpenSSL-licensed code makes it less useful than i was hoping it would be.

I have a few other concerns about the package after looking it over in more detail. I suspect these are fixable one way or another, but i haven't sorted them out yet. I'm not sure i'll spend the time to do so based on the licensing issues i sorted out above.

But in case anyone feels inspired, the other concerns i see are:

embedded code copies
In addition to embedded (and slightly-modified) copies of bn/ and crypt/ from OpenSSL, CryptLib contains an embedded copy of zlib. Debian has good reasons for wanting to avoid embedded code copies. I've got it CryptLib building against the system copy of zlib, but the bits copied from OpenSSL seem to be more heavily patched, which might complicate relying on the system version.
executable stack
lintian reports shlib-with-executable-stack for the library after it is built. I don't fully understand what this means or how to fix it, but i suspect it derives from the following set of object files that also have an executable stack:
0 dkg@pip:~/src/cryptlib/cryptlib$ for foo in $(find . -iname '*.o'); do
>  if ! readelf -S "$foo" | grep -q .note.GNU-stack ; then
>   echo "$foo"
>  fi
> done
./shared-obj/desenc.o
./shared-obj/rc5enc.o
./shared-obj/md5asm.o
./shared-obj/castenc.o
./shared-obj/bfenc.o
./shared-obj/rmdasm.o
./shared-obj/sha1asm.o
./shared-obj/bn_asm.o
./shared-obj/rc4enc.o
0 dkg@pip:~/src/cryptlib/cryptlib$ 
They probably all need to be fixed, unless there's a good reason for them to be that way (in which case they need to be documented).
non-PIC code
lintian reports shlib-with-non-pic-code on the library after it is built. I don't fully understand what this means, or how to resolve it cleanly, but i imagine this is just a question of sorting out the details.
Anyone interested in using my packaging attempts as a jumping off point can start with:
git clone git://lair.fifthhorseman.net/~dkg/cryptlib
Oh, and please correct me about anything in this post; I'd be especially happy to hear that my analysis of the licensing issues above is wrong :)

 

Comments on this Entry

Posted by Anonymous (173.50.xx.xx) on Wed 16 Mar 2011 at 05:37
Whatever happened to the OpenSSL compatibility layer in gnutls? How close does it come to full OpenSSL compatibility?

[ Parent | Reply to this comment ]

Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Wed 16 Mar 2011 at 05:52
[ View dkg's Scratchpad | View Weblogs ]
I don't think that the OpenSSL compatibility layer in GnuTLS is relevant here. As i understand it, that compatibility layer addresses the TLS/SSL API for OpenSSL.

The parts of OpenSSL that CryptLib is using (multi-precision integers in bn/ and low-level crypto primitives in crypt/) aren't part of GnuTLS anyway; GnuTLS is much more modular, and doesn't build in all these components. Older versions of GnuTLS rely on libgcrypt for these features; future versions of GnuTLS may rely on libgmp for the MPIs and libnettle for the crypto primitives.

So if your goal was to port Cryptlib to libraries with friendlier licenses, you wouldn't want to focus on GnuTLS as the source anyway. That said, even if a clean compatibility layer between libraries existed already, the fact that CryptLib embeds modified copies of code from OpenSSL instead of linking against the library itself makes the prospect of swapping out library dependencies even more dubious.

[ Parent | Reply to this comment ]

Posted by etbe (118.209.xx.xx) on Wed 16 Mar 2011 at 11:44
http://etbe.coker.com.au/2008/08/11/executable-stacks-lenny/

The executable stack flag can be checked with "execstack -q foo.so" and cleared with "execstack -c foo.so" (see the above URL for more info). You could alter the build scripts to run "execstack -c" as part of the build process, or you could alter the assembler source files to have a line such as the following:
section .note.GNU-stack noalloc noexec nowrite progbits

http://etbe.coker.com.au/2007/02/10/execmod/

A shared library with non-pic code gives an execmod issue (see the above URL for more background info).

In both these cases more access has to be granted in SE Linux to every single program that uses such a shared object, and even when not using SE Linux the executable stack setting results in a program that is more vulnerable according to paxtest. So it's good for security to get these things fixed, even though fixing the execmod problem can result in a performance loss on i386 due to assembler optimisations using all the registers and this being incompatible with relocatable code.

[ Parent | Reply to this comment ]

Posted by Anonymous (69.209.xx.xx) on Wed 16 Mar 2011 at 18:34
Just a side note: the license for CryptLib is very confusing. The "usage conditions" section very matter-of-factly states some non-free conditions, then the "detailed conditions" section states a custom license based on the Sleepycat License but apparently intended to be more AGPL-like, then "alternate usage conditions" are stated under the premise that the Sleepycat-like license does not permit commercial use. It's a big muddle. Even putting aside the code from OpenSSL, I would not be comfortable linking this to GPL-licensed code without further clarification on the CryptLib license terms.

[ Parent | Reply to this comment ]