CUPS is now linked against OpenSSL

[Daniel Kahn Gillmor]

On 01/11/2014 11:55 AM, Didier 'OdyX' Raboud wrote:
> So as far as CUPS is concerned, I see three ways forward:
> 
> 1) revert the switch to OpenSSL and link against GnuTLS 2. This
>    basically postpones the question to the moment when GnuTLS 2 is
>    removed from Debian. As I understood the thread, GnuTLS 2 is likely
>    to be removed from testing before the freeze, right?
> 
> 2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and
>    CUPS is GPL-2 only.
> 
> 3) report RC bugs against all packages linking against libcups2
>    which licenses don't allow indirect linking to OpenSSL (mostly GPL-
>    -without-OpenSSL-exception) and hope that fixes can be found license-
>    -wise. There are >= 38 packages build-depending on libcups2-dev and
>    >= 120 packages depending on libcups2. Also, I am not aware of tools 
>    to detect this incompatibility automatically. I also doubt we'll be
>    able to find solutions for all packages; yet libcups2 is quite
>    important in desktop stacks.

There is a fourth way forward -- loath though i am to propose it --
which is to avoid enabling TLS in CUPS at all until upstream gets their
act together and does something sensible, both licensing-wise and
crypto-wise.

last i checked, cups does not support certificate validation or checking
[0], making the crypto vulnerable to any active attacker:

[0] http://www.cups.org/str.php?L1616

According to the roadmap [0] this is due on the 2.0 branch, but i
haven't seen it yet.

[1] http://www.cups.org/roadmap.php

This is a terrible solution, but an encryption layer that silently fails
open in the presence of an adversary is a bad thing too, especially if
it introduces all sorts of licensing gymnastics.

The idea of opening RC bugs against everything that links to libcups2 to
demand an OpenSSL exception sounds really, really ugly to me.  what
about the packages that link to those packages?  I'd rather see less
OpenSSL, not more, because of its mutual incompatibility  with the GPL.

Modern versions of GnuTLS could be GPL2+ if GMP relaxes their licensing,
which would also solve this situation, and would be a better win for
copyleft and free software all around.

If we're willing to go around asking folks for changes to their
licensing, my preferences would be (highest preferences first):

 0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL exception)

 1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change
in 4.2.2).  Does anyone have a strong

 2) turn off TLS support in CUPS until upstream works things out and
actually provides some cryptographic defense against an active attacker

 3) drive bamboo shoots under my fingernails

 4) patch CUPS to use some other GPL2-compatible TLS implementation
(libnss?  polarssl?)

 5) ask dozens of packages which already have reasonable copyleft
licensing to make openssl execptions, iterating until we've covered
everything contaminated with this mess.

(ok, maybe 3 and 4 are actually tied)

happy hacking,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20140111/080e7cb9/attachment.sig>