*Abstract of discussions* In this mammooth of a thread (11 post so far) in answer to call for vote, there have been a lot of interesting remarks and discussions. They have touched various domains, and are difficult to summarize easily.
I have chosen to group these reactions by theme, and to quote only the most important (salient ?) points. Feel free to correct me as much as you like. I take the result of the vote (final tally : 9 "Yes", 4 "No", 7 discussants without formal vote) as granted, and organized my abstract of discussion in function of this result. I present the practical conclusions (i. e. (announcements of) proposals) in *italics* (sorry, I do not know how this will be rendered in a pure text-only mail reader...). *I) Do we have to *Include* OpenSSL as such ?* Numerous commenters have remarked that it is sufficient to depend on a *mandatory* systemwide openssl. It is true. But we are hoisted by our own petard : from our tutorial <http://doc.sagemath.org/html/en/tutorial/introduction.html> : "The Sage download file comes with “batteries included”. In other words, although Sage uses Python, IPython, PARI, GAP, Singular, Maxima, NTL, GMP, and so on, you do not need to install them separately as they are included with the Sage distribution." I fail to see how this would not apply to OpenSSL (under the heading "and so on")... Many also have regretted that "Depending on a systemwide OpenSSL" was not an option to the vote. They are right. But I never pretended to be omniscient... *A proposal for implementation (to be posted Real Soon Now (TM)) will try to reconcile this point of view with the result of the vote.* *II What means "Clarify the licensing issue" ?* A few posts expressed reservation about the language accompanying the call for vote. Some pertinent (and some less pertinent) comments were made. This language was lifted by Dima Pasechnick from the Wget <https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ> license (Wget is a GPL-licensed GNU utility). I thought it was a good response to lingering (pseudo-legal concerns. But, again, I'm not infaillible... David Joyner suggested <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/_-iJO7SmAQAJ> that we write to OpenSSL to take their advice ; I have to say tht I don't see the point : we can avoid inclusion of OpenSSL in our repositories for as long as hosting it would be possibly contentious, and the remaining legal problems would concern OUR behaviour Re: GPL : that's what the "clarification langiuage" porposed by Dima is for... *The above-mentionned implementation proposal will contain a proposal for clarification.* Review by legally apt persons (US and non-US !) welcome... *III Security issues* It has been noted that http is ridiculously easy to hijack <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/3dfTByrIAQAJ>, and some have remarked <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/FheYtjBWAAAJ> that this potential threat also applied to the http downloads from our mirrors. *I think we should consider this issue, an plan to post (Real Soon Now) a call for discussion about this.* What is the relevant list ? Others remarked <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/podOAX89AAAJ> that a non-SSL-enabled pip, which impedes, for example, downloading from Pipy, sort-of enhanced security by suppressing a possible source of attack. No comments... *IV Problematic platforms* [ I have had trouble finding a precise source for these comments, which were made "en passant" ] It has been noted by our Mac heads (most notably Dima Pasechnick, Nicolas Thiery and John Palmeri <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/rfCahyEZBwAJ>) that Mac OS X still may be a source of trouble for OpenSSL availability. I note that *their advice will be sorely needed for the applicability of the proposal for implementation to their platform of choice.* Similarly, I am still in the dark about the ability of our Cygwin port to ensure the availability of the Cygwin-ported OpenSSL library and development files. Again, *Erik's expertise will be needed during implementation.* *V Ability to build Sage without OpenSSL* A very long and ramified thead (no links, they are too many) showed that Jeroen Demeyer insists to be able to build sage without OpenSSL ; I still don't see its point, but Erik Bray finally tended to support Jeroen's point of view, arguing that air-gaped machines could be useful in some situations, and I have learned to respect if not to follow systematically) Erik's advice... This point of view is of course incompatible with the result of the vote. However, I think that it could be easy to maintain a set of patches allowing such a compilation without SSL. This set of patches could live in a git branch (say "anchorite <https://en.wikipedia.org/wiki/Anchorite>" (a solitary kind of sage <https://en.wikipedia.org/wiki/Sage_(philosophy)>)) of our tree, and updated to create releases (in sync with Sage "official" releases ?) and related tarballs and binaries. Of course, I emphatically DON'T volunteer for this maintenance... *I'll propose a detailed plan for implementation Real Soon Now (TM), but I'll need advice from present and past release managers, in order to better understand the implications*. Again, what is the right list ? *VI (Re-)funding request to Apple* It has been noted <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/FheYtjBWAAAJ> that we should bill Apple for all the time we wasted on maintaining Sage on their platform notwithstanding the difficulties posed by the oddities of their development tools. While applauding the idea, *I am skeptical about its implementability.* Comments ? *VII Overall conclusions* The discussions seem to have been useful : a lot of various misunderstandings have been resolved. Some people changed their vote, thus demonstrating the usefulness of the discussion. I hope that the forthcoming proposals : - Implementation of OpenSSL inclusion - Security issues - Branch for compilation sans OpenSSL for air-daped machines will be as fruitful as this one. *VIII Special mention* *I hereby present Jeroen Demeyer with Charpentier's Special Prize for the Koan of the Year* for this utterance <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/-mrgKjLIAQAJ> : "A non-communicating R in Sage can be very useful if you are not using R in Sage at all (which is very likely the vast majority of Sage users)." which still stymies me : I'm not enlightened yet... -- 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.
