On Linux, you can build Sage with and without openssl. If you ever hit the network you really should build with openssl(-devel) available, it will be picked up automatically. But its not a requirement. Though we should probably strongly recommend it in the installation instructions.
GnuTLS and other implementations won't solve our problem, as Python's _ssl module is specifically written against OpenSSL and can't be linked against anything else. On OSX, you can do either a) nothing => no https support, a) supply the (missing) openssl headers for the system openssl. This is still a shitty solution as it doesn't (and probably will never) support TLSv12. c) compile your own openssl implementation AND bring your own copy of the root certificates as your self-compiled openssl will not be able to access the OSX certificate store. Distributing the resulting binary has some license issues. On Thursday, December 1, 2016 at 11:25:42 PM UTC+1, Emmanuel Charpentier wrote: > > 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. >> > To post to this group, send email to sage-...@googlegroups.com. >> > 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.
