Hi Daniel, and thanks for the insightful response, Le samedi, 11 janvier 2014, 14.22:28 Daniel Kahn Gillmor a écrit : > 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. That would be quite a bold move to take. The one aspect that puzzles me most is: in which ways "no TLS security" is better than "incompletely secure TLS"? Now some CUPS bugs are probably not known widely enough and we could warn about using CUPS's TLS support in the packaging, wording welcome. Also, TLS is enabled in all actually our supported src:cups uploads. Introducing this regression is a move for which I would need quite a strong encouragement to proceed with. > last i checked, cups does not support certificate validation or > checking , making the crypto vulnerable to any active attacker: > >  http://www.cups.org/str.php?L1616 > > According to the roadmap  this is due on the 2.0 branch, but i > haven't seen it yet. > >  http://www.cups.org/roadmap.php Quite bad indeed. I have pinged that bug to see whether a fix could happen earlier. > 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. Frightening can of worms. > 0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL > exception) As asking generally can't hurt, I have filed https://cups.org/str.php?L4337 on the upstream bugtracker to discuss that. I'll keep the list posted. > 1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change > in 4.2.2). Does anyone have a strong relationship with GMP > maintainers who could open this conversation with them? I don't, but would hope the libgmp maintainers could ask the question; I've hereby CC'ed Steve. > 2) turn off TLS support in CUPS until upstream works things out and > actually provides some cryptographic defense against an active > attacker For now, I will rather revert the switch to OpenSSL and … > 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. … try to see what this can of worms looks like. Cheers, OdyX
Description: This is a digitally signed message part.