Le jeudi 1 décembre 2016 23:47:40 UTC+1, Volker Braun a écrit : > > On Linux, you can build Sage with and without openssl. If you ever hit the > network >
Who doesn't ? I can see two (quite marginal) use cases : - Military high-security un-networked machine users (who install and update their software via sneakernet) ; - Monks (probably not even a plurality of them). As far as I can tell, everybody else will have someday to hit the network (at least for PIP packages...). > 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. > That's more or less what I propose. You seem to be less affirmative than I would. 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, > Unacceptable, for practicability reasons (see above) > > 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. > Hardly acceptable (how longer the PIP and R repositories will remain reachable without 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. > Dubious : where can one get "its own copy of the root certs" ? How secure *this* would be ? (And I have dark doubts on the possible consequences of the licensing issues...). The logical conclusion would be to avoid Macs for this kind of use. (But I have to confess an old and deeply ingrained prejudice about these nice but way overpriced machines and Apple's shenanigans that forever try to chain you to ONE supplier, namely themselves...). Should we discourage Sage potential users to buy Macs ? Note that we *could* also (at least theoretically) try to replace Python's __ssl module with our own, more accommodating one, linked to our own TLSv12-enabled library. Somehow, I don't see *that* happen in a foreseeable future :-). HTH (but I doubt it...) -- Emmanuel Charpentier 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.
