On 03/14/2014 06:29 AM, Alessandro Ghedini wrote: > "Avoid making git unredistributable" doesn't sound that silly to me (having > these kind of problems in the first place kind of is though). > > There's also the chance that switching to libgnutls28 would break packages > that > directly or indirectly depend on libgnutls26 (that is, the inverse of the > libapache2-mod-gnutls problem).
i'm hoping we can drop libgnutls26 entirely before jessie releases, so i
don't think this will be an issue.
>> If libcurl-gnutls really has licensing concerns about moving to
>> libgnutls28, and that causing problems for GPLv2 code that links against
>> this version of libcurl, one possibility is to introduce
>> libcurl4-gnutls28 -- there are already 3 TLS-library flavors of libcur,
>> what is one more? :P
>
> That's not going to happen. If anything libgnutls-dev and libgnutls28-dev
> can't
> be installed at the same time, and just because curl's packaging is already a
> mess doesn't mean it's ok to make it even more messier.
This wasn't a serious suggestion, which i tried to indicate with the :P
sorry that it wasn't clearer.
> On the bright side, I was looking into reducing the libcurl flavors to just
> the
> libnss one, but that's not yet possible, as long as #726116 doesn't get fixed.
that would be an interesting approach.
>> There is no good reason i can see for libapache2-mod-gnutls to prefer
>> the older version with less robust algorithm availability and weaker
>> configuration options.
>
> Well, "making it work, i.e. fix #741557, and avoid having it removed from
> testing" sounds like a pretty good reason to me. Granted, it's really not that
> much of a good solution, but it would hopefully be only temporary.
"making it work" for a security-oriented tool should *not* mean
"sacrificing the only believed-to-be-secure ciphersuites and protocol
versions just for the sake of shipping code". I don't think mod-gnutls
should be removed from testing, but i'd rather that it be removed from
testing than force building against libgnutls26.
Clint, another option is for you to rebuild libmsv against
libcurl4-nss-dev until the libcurl4-gnutls mishegas is sorted out. the
irony here is that libmsv doesn't actually use TLS for its outbound
connections at all, so the choice of what to use here isn't actually
relevant :/ for the sake of libmsv, i'd be happy to build against a
libcurl4-no-tls-dev package! (Alessandro, i'm not actually suggesting
this a serious suggestion for libcurl; it's just an observation about
the frustrating pointlessness of all this wrangling).
--dkg
signature.asc
Description: OpenPGP digital signature
