On Thursday, December 1, 2016 at 10:47:40 PM UTC, Volker Braun wrote: > > 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. >
Do you understand the story about root certs here? Is it a missing python code (in some package, existing or not?) that would be able to access OSX certs store? Or is it more fundamental than this? > > > 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.
