On Friday, 27 October 2017 16:19:30 UTC+2, Emmanuel Charpentier wrote: > > Dear Marteen, > > Le vendredi 27 octobre 2017 16:02:03 UTC+2, Maarten Derickx a écrit : >> >> Why a separate git branch and not make it something configurable, like >> building sage with gmp vs mpir? >> > > Because those are not the same cases : > > Well, yes there clearly are differences between to the two scenarios. But your arguments are all either just a) pointing out differences between the mpir vs OpenSSL situation or b) arguments against the usefulness of being able to build sage without OpenSSL and this is not what I was asking for. What I actually was looking for were arguments for why having a branch is a better idea then making it something configurable. I think the choice between a branch and something configurable is something that is just a technical difference on how to achieve the wished end result (make it possible to compile sage without OpenSSL). So here some reasons why I think a separate branch is a worse idea then making the instalalation of OpenSSL configurable: 1) A separate branch creates way more maintenance work then making it configurable since now something needs to be done each release, instead of potentially doing something when R is updated. 2) Because a separate branch it is quite a far fetched solution compared to using configure and make and maybe some environment variables which are the standard tools for deciding how and what to build. 3) It deviates from the way sage currently behaves with respect configuring which packages to install, requiring the user to learn something new. Making the sage the distribution experience feel less coherent.
> a) there is no currently (to the best of my limited knowledge) , strong > reasons to choose one over the other, > b) they give (modulo my limited knoiwledge, again) roughly the same > possibilities to Sage, > c) there are people able, and **volunteering**, to maintaint this > alternative. > > In the case of OpenSSL not having OpenSSL: > > a) doesn't give us anything but the ability to do without a package deemed > "GPL incompatible" (in the sense that we currently cannot ship it with > Sage) > Which is a useful ability to have considering the bad experience almost al sage-devs on OS X had getting this to work. > b) deprives R and pip users of an useful ability (deemed mandatory by R > authors) > Or worded differently: gives people the option to have a working sage installation missing just two of its many features instead of no sage installation at all if getting sage to work with OpenSSL turns out to be too difficult. This is what Jeroen meant with his Koan about that an R that builds without OpenSSL can be very usefull for people not using R, since it means they can forget about the non trivial step (on some platforms) of getting OpenSSL to work. > c) forces us to maintain a patch that is of no use to what I think a > majority of Sage users. > Well I think the statement "this patch is of no use to what I think a majority of Sage users" is a very important statement since the answer to the key question: "Do we wish to support building sage without OpenSSL?" hinges on wether you consider c) to be true. Several people (including me, but also other sage developers I talked to at some sage days) have had serious trouble getting sage to build with OpenSSL so having an option to avoid these troubles at the cost of a less functional R and pip is certainly something useful for at least a significant minority of the Sage users. Additionally I think demanding something to be useful to a majority is a way to strong criterion for when to support something in sage or not, otherwise we could also probably also say: R in sage is not used by the majority of Sage users so we might as well not ship it. Now wether "this patch is of no use to what I think a majority of Sage users" is true also very much depends on how difficult it is to get sage to work with OpenSSL, if this is trivial then of course the patch is of no use. But I think at least in the current sage it is not trivial on all platforms. For this reason I am for anything that is working in the direction of making it easier to get sage to work with OpenSSL, however the proposed changes have not been implemented/let alone be battle tested. And requiring OpenSSL to build sage is a change of the status quo. Personally I certainly believe that in the long term we should just require OpenSSL, but at this moment right now I think it is also important to provide a clean migration path. Right now requiring OpenSSL is actually doing two things at once: 1) change the default from building without OpenSSL support to building with OpenSSL support. 2) remove the possibility of falling back to the old default of building without OpenSSL. I think doing these two at once is something that might very well bite us in the back causing a lot people complaining about this on the mailinglist and having no valid answer to their problems then: stick to the old version for now (like for example happend with the IPython switch from readline to promt_toolkit). Now I am not saying that this will definitely happen, but the problem is that at the moment we do not (and actually can not) know wether it will happen. However if we first do step 1) and later step 2), then we will first get feedback on what users think of the change of the default behaviour, and if they really do not like it we can just tell them how to configure sage to fall back to the old behaviour, but at the same time telling them that the old behaviour will not be supported in the future. Then once we are sure that the new default is working well enough to not cause anyone significant troubles with trying to build sage, then we can finally do step 2. Note that personally in the long term I am for not supporting building sage without OpenSSL, however right now I think we do need to support it in order not to make some people very upset. Apart from my criticism: thank you for the energy you are putting into trying to get the OpenSSL situation in sage to improve. > > The point made by William about security issues is also to be considered ; > but I'm not an expert... > > Well the solution would just disable downloading packages using pip or R, so if the downloading does not work there, there is no security issue. For the downloading standard packages the stored hashes solve the security issue, since the goal is just to be sure that the downloaded code is not tampered with. The main advantage of https enabled downloads over hashing is that his also allows you to hide the content of the packages you are downloading from a third party, but since the packages are already public knowledge this is of little extra value. -- > 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+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.
