On Tue, Aug 09, 2005 at 11:31:22PM +0200, Daniel Stenberg wrote: > On Aug 9 2005, Steve Langasek wrote: > (I'm not on the list, I read this response elsewhere and I handicraft this > reply) > >> Even when libcurl works identically good using either library, OpenSSL > >and > GnuTLS differ not only license-wise but they also have features of > >their > own and bugs of their own. Limiting the libcurl offer to use only > >one of > them will cause grief at some point in some camp(s), that's for > >sure. > >Er, it's only SSL/TLS. The correct long-term answer to "they each have > >bugs" is "fix the bugs in [libcurl's support for] GnuTLS", not "let the > >users pick which set of bugs they like better". > I beg to differ. A lot. > 1. It is not "only" SSL/TLS. For example, OpenSSL supports SSLv2 while > GnuTLS does not. GnuTLS supports SRP while OpenSSL does not. > If an author of an application that uses libcurl cares about either of > these differences, then that author might prefer one specific of these > libs. That's a lousy justification for shipping two otherwise-identical binary packages. Unless there's a reason that GNU TLS upstream objects to supporting SSLv2, the answer is still "get SSLv2 support added to GNU TLS", not "make it everybody else's problem to support double the binaries". > 2. In the mail you replied to I was referring to bugs in the SSL/TLS > libraries, not the ones in libcurl. It is similar to (1) above, as the > authors of the libs might prioritize bugs differently or even disagree on > what a bug is or isn't etc. <shrug> Irrelevant to my argument. I had [libcurl's support for] in brackets for a reason. > 3. There are application authors who _prefer_ the license of OpenSSL in > favour if the (L)GPL ones of GnuTLS (and its associated sub-libraries). Then those application authors are insane. I try to avoid depending on software written by crazy people; you never know what else their insanity might lead them to do. > 4. As these SSL libs provide completely different APIs they allow somewhat > different things to be done with different ease or even possibilities. I > don't find it unlikely that libcurl will offer different features to > applications depending on what underlying SSL lib that is used. This > would > of course not be ideal or even wanted, but in real life it might still be > what we'll have. Which again fails under "there are bugs, fix them instead of making everybody else support your lack of effectiveness as a maintainer". -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature