Dear Thierry, Thank you for this answer : you have done a large work that I planned for my next opportunity. Comments below :
Le jeudi 1 décembre 2016 22:56:15 UTC+1, Thierry (sage-googlesucks@xxx) a écrit : > > Hi, > > On Sun, Nov 27, 2016 at 03:52:59AM -0800, Emmanuel Charpentier wrote: > > OK. Let's try again : > > I have two questions : > > > > 1. What are the parts (standard, optional or experimental, except, of > > course, the openssl package itself) of Sage that need (directly or > > indirectly) a secure transport layer but would accept either openSSL > or > > reasonable substitutes such as Gnu TLS or Mozilla's NSS ? > > 2. What are the parts (standard, optional or experimental, except, of > > course, the openssl package itself) of Sage that (directly or > indirectly) > > need openSSL, no substitute accepted ? > > > > My favorite itch to be scratched (namely R), seems to fall in the first > > category, but I have trouble proving it : I would need a reasonable test > > machine with no openSSL library to check whether R installs or not using > > only Gnu TLS. All the Linux *desktop* installation I tried install > > openSSL, one way or another (even Debian, which is notably prudish about > > licensing). I would have to install an ultra-basic virtual machine. This > > setup could be used to prove or disprove the dependencies of various > parts > > of Sage. > > A priori (?), openssl package should not interfere if you do not have > libssl-dev installed. > > I tried building Sage 7.3 on a VM without libssl-dev, but with both > libgnutls28-dev and libgnutls-openssl27 installed (on a Debian jessie). > Sage builds and tests fine, but i do not have SSL support when using pip: > > ./sage -pip search blah > SSLError: Can't connect to HTTPS URL because the SSL module is not > available. > This seems a serious problem, given the increasing dependency of Sage on pip packages. This is also one aspect of more and more services migrating to secured protocols (the new https requirement of R, which started this epopea, is another example). I think that your experiment demonstrates that GnuTLS does not (yet) offer a substitute to (at least some) OpenSSL functionalities. My experiments with R led me to think the same thing. So I think it's time to bite the bullet, acknowledge that we depend on OpenSSL and document it. We should also test for it when building Sage. For the first task, I think that the right places are : - README.md in the root directory ; - The developer's guide. For the second task, the most logical place would be in the toplevel configure file, after checking for a "minimal" toolset (C compiler, make, etc..). Since at this point, we do not have pkg-config, we have to use the Great White Shark method : bite and see what happens. In this case,, compile, link and run a minimal program festing the existence and basic functionality of of libssl. Ideas on what to test an how are much welcome : I'm a bit out of my depth here... We could also wait for the installation of Sage's pkg-config, which makes the ssl test trivial, but, IIRC that comes a bit late (i. e. after Sage's python compilation), and we leave the user with partially unusable Sage's parts, that whould have to be recompiled after a correct OpenSSL installation. It's probably better to fail early. Again, your advice, criticisms and ideas are welcome. > Ciao, > Thierry > Again, thank you ! -- Emmanuel Charpentier > > > > > There are only two possible results, and two sets of action : > > > > 1. If no part of Sage depends on openSSL exclusively : fine. package > and > > ship Gnu TLS as a standard package, and be done with the damn thing > > 2. If some part of Sage need openSSL exclusively : since we *can* use > a > > systemwise installation but cannot (pseudo-legally) *ship* it, we > just > > *have to* depend on this systemwide installation. Add it to the > > prerequisites, and be done with it. > > > > > > So this inventory is crucial. > > > > What do you know about these dependencies ? > > > > -- > > Emmanuel Charpentier > > > > Le lundi 21 novembre 2016 12:21:31 UTC+1, Emmanuel Charpentier a écrit : > > > > > > Dear list, > > > > > > The fact that we can't ship openSSL (see uncountable theads in > sage-devel > > > and others) seems to pose more and more difficulties. See for example > this > > > thread < > https://groups.google.com/forum/#!topic/sage-support/rDV9uGT2ViM> > > > on sage-support, and especially Dima's answer > > > <https://groups.google.com/d/msg/sage-support/rDV9uGT2ViM/GuKDbhSKAwAJ>, > > > > as well as this annoying ticket < > https://trac.sagemath.org/ticket/21767>, > > > discussed in this saga > > > <https://groups.google.com/forum/#!topic/sage-devel/QaBdHSNJuKg> . > > > > > > Could'nt we add OpenSSL as a prerequisite to Sage, and it"s > development > > > files as a prerequisite to building Sage ? This would require of the > user > > > to install OpenSSL systemwide, thus making it "system software" and > > > satisfying the strange licensing requirements that bother us. > > > > > > One could even do that indirectly, by requiring a systemwide libcurl > > > supporting https : this would de facto enforce the systemwide > installation > > > of OpenSSL (or a reasonable facsimile). That's what I was trying to do > in this > > > proposal <https://trac.sagemath.org/ticket/21767#comment:41>... > (IIRC, > > > the problem with libcurl is also bound to OpenSSL : libcurl itself is > not a > > > problem. But I'll have to check : if this is true, we can require > OpenSSL > > > and ship libcurl which will then compile cleanly). > > > > > > Comments ? Especially wrt Macs, which seem to be further encumbered by > > > Apple's dirty tricks... > > > > > > Should we have a vote ? > > > > > > -- > > > Emmanuel Charpentier > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+...@googlegroups.com <javascript:>. > > To post to this group, send email to sage-...@googlegroups.com > <javascript:>. > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
