[cmake-developers] Unexpected bad status for file DOWNLOAD for http://*.xz URLs

[Alan W. Irwin]

On 2013-07-12 23:41+0200 Eric Noulard wrote:

> 2013/7/12 Alan W. Irwin <irwin at beluga.phys.uvic.ca>:
>>
>> I just double-checked with ldd that Debian wheezy cmake links to
>> libcurl-gnutls.so (linked to the gnutls library to provide the
>> SSL capabilities) rather than libcurl.so (linked to the openssl
>> library to provide the SSL capabilities).  The result of my test
>> with the Debian version of cmake is
>>
>> software at raven> /usr/bin/cmake -P test.cmake
>> -- [download 0% complete]
>> -- Download status = 35;"SSL connect error"
>>
>> However, note I also got this same result when I built a version of
>> CMake linked to libcurl-gnutls.so so it is likely there is currently
>> some incompatibility between CMake and libcurl-gnutls.so to cause this
>> connect error issue.
>
> I bet that this is curl SSL option.
> Now on Debian Jessie (testing) and CMake 2.8.11.1 from Jessie repo
> I get:
>
> /usr/bin/cmake -P gg.cmake
> -- [download 0% complete]
> -- Download status = 51;"SSL peer certificate or SSH remote key was not OK"
>
> which leads me to this:
> http://stackoverflow.com/questions/14192837/ssl-peer-certificate-or-ssh-remote-key-was-not-ok

What happens if you attempt that download using the curl executable on
Debian jessie?  Does it also have a similar complaint or does it
perform like the Debian wheezy version with no errors.  Assuming the
jessie version of curl is also linked against the openssl flavour of
libcurl, then that weakly (because currently only one example is involved)
supports the possibility that openssl flavours consistently have no
complaints about URL's while gnutls software flavours do have such
consistent complaints.

To do a better test of that hypothesis, would you be willing to
assemble a list of 10 or more pseudo-random https downloads that would
be worth trying to see if this issue is widespread?  I just checked,
and the jhbuild build configuration files I currently working with
have no explicit https downloads for the ~40 packages required to
build the GTK+ stack of libraries. Of course, some of them involve
https via redirects (as in my glib download test case which happened
to be the first download I tried), but the lack of definite knowledge
about whether https is involved or not would require a lot of extra
work to interpret any results I derive from that list of downloads.
Anyhow, if you could come up with a list of https URL's to try, I
would be happy to test them for the Debian wheezy version of cmake and
curl and give you a convenient script to do the same if you would
like to perform the same test on Jessie.

>
>
>> The point is CMake makes it much too easy to fall into the trap of
>> using the libcurl-gnutls.so library rather than libcurl.so.  So to
>> avoid such problems in the future I recommend that either CMake
>> blacklist use of libcurl-gnutls.so or, better yet, solve the
>> incompatibility issue with it.
>
> What makes you think that "there is" an incompatibility?
> May be the culprit IS "libcurl-gnutls.so" itself?
> Which other program you know is using it etc...

You might be correct.  However, if libgnutls was basically not working
for most https sites, I think there would have been a big stink about
it on the Debian tracker.  I did look for such a possibility for the
combined bug reports for anything to do with libgnutls at
<http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=gnutls26;dist=unstable;repeatmerged=0>,
but I did not spot anything that jumped out at me from the subject
lines of those bug reports.  But if you see something there you think
might be relevant please let me know.

>
> On Debian the curl executable seems to be linked against libcurl.so
> the openssl falvour of libcurl, so that when you test with curl you test
> with openssl not gnutls.
>
> I don't really know where the trouble is but may be it's not in the
> CMake code at all.

You might be correct.  But regardless of whether the code issue is in
CMake or not, it is telling for me that the Debian packager for curl
uses the openssl flavour of libcurl and not the gnutls flavour.  So
even if we never know the exact cause for this issue it might
eventually turn out that the solution to this mess is simply for CMake
to blacklist any gnutls flavour of libcurl.  Of course, this is early
speculation on my part and we should wait to make definitive
conclusions about this possibility until more testing is done (as
suggested above) to prove whether or not this is a consistent problem.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________