On Sat, Oct 28, 2017 at 4:24 PM, Maarten Derickx <[email protected]> wrote: > > 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.
! +1 to all of the above. >> >> 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. Yes, this is along the lines of the point I made elsethread--the security in this case is being provided by services like CRAN and PyPI switching to HTTPS-only. If some user lacks HTTPS support then they cannot download packages from HTTPS-only services, so they are implicitly "protected" in this case. Erik -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
