Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 25 octobre 2017 12:01:45 UTC+2, Erik Bray a écrit :
>
> On Wed, Oct 25, 2017 at 3:56 AM, William Stein  > wrote: 
> > 
> > On Tue, Oct 24, 2017 at 3:08 PM Eric Gourgoulhon  > 
> > wrote: 
> >> 
> >> Thanks Emmanuel for the discussion summary. 
> >> 
> >> 
> >> Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit : 
> >>> 
> >>> 
> >>> It is true. But we are hoisted by our own petard : from our tutorial : 
> >>> "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")... 
> >>> 
> >> 
> >> I have the feeling that the current tendency is towards a more modular 
> and 
> >> lighter Sage, which deviates from the original "batteries included" 
> >> philosophy. Maybe the latter should be rephrased as "mathematical 
> batteries 
> >> included". This would exclude standard "technical"  software like 
> OpenSSL, 
> >> which should be provided systemwide. 
> > 
> > 
> > Well said.  I’m the reason for the batteries-included full distribution 
> Sage 
> > approach, and I did it that way entirely out of necessity: very limited 
> > manpower, Python packaging was in disarray, etc., all while attempting 
> to 
> > support many environments like Solaris, Cygwin, OS X,...   Python 
> packaging 
> > has improved a lot since 2004, with conda and pip, and there are a 
> hundred 
> > times more people working on Sage.   Git now exists.  I hope we have 
> further 
> > discussions in this list about ways to realize the vision you have 
> roughly 
> > sketched above. 
>
> I'm still actively working on improving Sage's build system to 
> strongly prefer dependencies from the system wherever possible.


Seconded !!! As William pointed out, we should review what can be 
unconditionally expected systemwide, what needs checks (i. e. minimal 
version, support for specific functionality) and what really needs to be 
incorporated (e. g. specific quirks of a package not correctable in Sage's 
interface to it...).

Larger review than our current objective. May xe defer this to a "Which 
batteries ?" discussion ?
 

>  The 
> actual implementation of this is not hard at all in principle, but 
> it's slow-going just because there is a lot of prerequisite plumbing 
> work that is taking time to get reviewed, and working properly on all 
> the supported platforms. 
>

Large piece of work... "*Exigi monumentum aere perrenius*", my tired foot ! 
;-]

--
Emmanuel Charpentier
 

>
> 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 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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

I'd rathet discuss this in the to be openedReal Soon Now) proposal for 
implementation.

--
Emmanuel Charpentier

Le mercredi 25 octobre 2017 11:57:13 UTC+2, Erik Bray a écrit :
>
> (Sorry for the multiple replies--there are just a lot of disparate 
> issues touched on in this message that I think would be confusing to 
> reply to all at once). 
>
> On Tue, Oct 24, 2017 at 8:58 PM, Emmanuel Charpentier 
>  wrote: 
> > 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" (a solitary kind of sage)) 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... 
>
> a) I don't think the point of view (that it should be possible to 
> build Sage without SSL support) is incompatible with the vote.  The 
> vote was over whether or not to include OpenSSL as an spkg (optional 
> or otherwise).  It could still be required by default, but disabled by 
> a configure option, for example, if needed.  In fact, as we've 
> repeatedly discussed, the *only* package in Sage that won't compile if 
> it doesn't find OpenSSL (actually libcurl with SSL support, 
> technically) is R.  So in practice the implementation might be 
> something like: 
>
> a) Check for OpenSSL in Sage's configure 
> b) If not found, use Sage's OpenSSL spkg 
>
> But part b) could also hypothetically be disabled by a configure flag, 
> if really necessary, *except* for the fact that then the R build will 
> fail.  This takes us to the issue of "a set of patches" (in reality 
> there is only a singular patch, the patch to R's configure to allow it 
> to proceed without an SSL-enabled libcurl). 
>
> I've repeatedly said I'd be willing to take the argument about this to 
> R-devel (so I can get out of your hair about it :)  But I don't think 
> it's all that big a deal either.  In fact, the issue of building R 
> could also be resolved entirely without a patch by just tricking it 
> into thinking it has the libcurl it's looking for.  I wouldn't 
> recommend this approach, but it can certainly be done even without 
> patching :) 
>
> > It has been noted 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 ? 
>
> TBH Microsoft has a better track record these days of funding open 
> source software than Apple does :) 
>
> Best, 
> 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 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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 25 octobre 2017 11:46:38 UTC+2, Erik Bray a écrit :
>
> Hi Emmanuel, 
>
> On Tue, Oct 24, 2017 at 8:58 PM, Emmanuel Charpentier 
>  wrote: 
> > 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. 
>
> IIRC I had an off-list discussion about this with Dima, but did not 
> report back here.  But in short where Cygwin is concerned it's 
> completely a non-issue.  OpenSSL is a standard package in Cygwin--you 
> almost can't install Cygwin without getting it (you *can* actually but 
> it's installed by default).  The headers are available as well.  So 
> again, this is a non-issue for Cygwin as a supported platform. 
>

Good. One less worry. I suppose that's true of the header files, hence easy 
instructins to give in the README file.

BTW : do you think that Cygwin build instructions are now mature enough for 
inclusion in the README/Installation manual, or do you still prefer to 
maintain your Wiki page ?

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 25 octobre 2017 11:42:32 UTC+2, Erik Bray a écrit :
>
> On Wed, Oct 25, 2017 at 12:08 AM, Eric Gourgoulhon 
>  wrote: 
> > Thanks Emmanuel for the discussion summary. 
> > 
> > Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit : 
> >> 
> >> 
> >> It is true. But we are hoisted by our own petard : from our tutorial : 
> >> "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")... 
> >> 
> > 
> > I have the feeling that the current tendency is towards a more modular 
> and 
> > lighter Sage, which deviates from the original "batteries included" 
> > philosophy. Maybe the latter should be rephrased as "mathematical 
> batteries 
> > included". This would exclude standard "technical"  software like 
> OpenSSL, 
> > which should be provided systemwide. 
>
> Indeed those were my thoughts as well.  All the "batteries" listed 
> here are mathematical in nature, or at least directly related to 
> Sage's user interface (Python).  "and so on" does not include libc, 
> the kernel, etc. etc. (or several other common system libraries that 
> we've been fortunate not to have to package with Sage yet...) 
>
> I'm not opposed to including an optional package for OpenSSL either, 
> in principle, but I do think the "batteries included" heading has more 
> to do with features for users, whereas adding an optional OpenSSL 
> package is more a feature for developers so that it's easier for them 
> to gather the needed build dependencies.  Users installing binaries do 
> not care. 
>

Again, larger discussion (which seems more and more necessary, but probably 
distinct from our current point. 

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 25 octobre 2017 10:41:15 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-25 00:08, Eric Gourgoulhon wrote: 
> > I have the feeling that the current tendency is towards a more modular 
> > and lighter Sage, which deviates from the original "batteries included" 
> > philosophy. 
>
> I would like to keep "batteries OPTIONALLY included". This means: use 
> system software if possible but keep support for installing software as 
> part of Sage. 
>

This deserves a separate discussion, probably quite interesting, but whose 
terms neet a bit of forethought. Can we delay this a bit ?

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Wed, Oct 25, 2017 at 3:56 AM, William Stein  wrote:
>
> On Tue, Oct 24, 2017 at 3:08 PM Eric Gourgoulhon 
> wrote:
>>
>> Thanks Emmanuel for the discussion summary.
>>
>>
>> Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit :
>>>
>>>
>>> It is true. But we are hoisted by our own petard : from our tutorial :
>>> "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")...
>>>
>>
>> I have the feeling that the current tendency is towards a more modular and
>> lighter Sage, which deviates from the original "batteries included"
>> philosophy. Maybe the latter should be rephrased as "mathematical batteries
>> included". This would exclude standard "technical"  software like OpenSSL,
>> which should be provided systemwide.
>
>
> Well said.  I’m the reason for the batteries-included full distribution Sage
> approach, and I did it that way entirely out of necessity: very limited
> manpower, Python packaging was in disarray, etc., all while attempting to
> support many environments like Solaris, Cygwin, OS X,...   Python packaging
> has improved a lot since 2004, with conda and pip, and there are a hundred
> times more people working on Sage.   Git now exists.  I hope we have further
> discussions in this list about ways to realize the vision you have roughly
> sketched above.

I'm still actively working on improving Sage's build system to
strongly prefer dependencies from the system wherever possible.  The
actual implementation of this is not hard at all in principle, but
it's slow-going just because there is a lot of prerequisite plumbing
work that is taking time to get reviewed, and working properly on all
the supported platforms.

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 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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

(Sorry for the multiple replies--there are just a lot of disparate
issues touched on in this message that I think would be confusing to
reply to all at once).

On Tue, Oct 24, 2017 at 8:58 PM, Emmanuel Charpentier
 wrote:
> 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" (a solitary kind of sage)) 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...

a) I don't think the point of view (that it should be possible to
build Sage without SSL support) is incompatible with the vote.  The
vote was over whether or not to include OpenSSL as an spkg (optional
or otherwise).  It could still be required by default, but disabled by
a configure option, for example, if needed.  In fact, as we've
repeatedly discussed, the *only* package in Sage that won't compile if
it doesn't find OpenSSL (actually libcurl with SSL support,
technically) is R.  So in practice the implementation might be
something like:

a) Check for OpenSSL in Sage's configure
b) If not found, use Sage's OpenSSL spkg

But part b) could also hypothetically be disabled by a configure flag,
if really necessary, *except* for the fact that then the R build will
fail.  This takes us to the issue of "a set of patches" (in reality
there is only a singular patch, the patch to R's configure to allow it
to proceed without an SSL-enabled libcurl).

I've repeatedly said I'd be willing to take the argument about this to
R-devel (so I can get out of your hair about it :)  But I don't think
it's all that big a deal either.  In fact, the issue of building R
could also be resolved entirely without a patch by just tricking it
into thinking it has the libcurl it's looking for.  I wouldn't
recommend this approach, but it can certainly be done even without
patching :)

> It has been noted 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 ?

TBH Microsoft has a better track record these days of funding open
source software than Apple does :)

Best,
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 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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

Hi Emmanuel,

On Tue, Oct 24, 2017 at 8:58 PM, Emmanuel Charpentier
 wrote:
> 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.

IIRC I had an off-list discussion about this with Dima, but did not
report back here.  But in short where Cygwin is concerned it's
completely a non-issue.  OpenSSL is a standard package in Cygwin--you
almost can't install Cygwin without getting it (you *can* actually but
it's installed by default).  The headers are available as well.  So
again, this is a non-issue for Cygwin as a supported platform.

Best,
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 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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Wed, Oct 25, 2017 at 12:08 AM, Eric Gourgoulhon
 wrote:
> Thanks Emmanuel for the discussion summary.
>
> Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit :
>>
>>
>> It is true. But we are hoisted by our own petard : from our tutorial :
>> "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")...
>>
>
> I have the feeling that the current tendency is towards a more modular and
> lighter Sage, which deviates from the original "batteries included"
> philosophy. Maybe the latter should be rephrased as "mathematical batteries
> included". This would exclude standard "technical"  software like OpenSSL,
> which should be provided systemwide.

Indeed those were my thoughts as well.  All the "batteries" listed
here are mathematical in nature, or at least directly related to
Sage's user interface (Python).  "and so on" does not include libc,
the kernel, etc. etc. (or several other common system libraries that
we've been fortunate not to have to package with Sage yet...)

I'm not opposed to including an optional package for OpenSSL either,
in principle, but I do think the "batteries included" heading has more
to do with features for users, whereas adding an optional OpenSSL
package is more a feature for developers so that it's easier for them
to gather the needed build dependencies.  Users installing binaries do
not care.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-25 00:08, Eric Gourgoulhon wrote:

I have the feeling that the current tendency is towards a more modular
and lighter Sage, which deviates from the original "batteries included"
philosophy.


I would like to keep "batteries OPTIONALLY included". This means: use 
system software if possible but keep support for installing software as 
part of Sage.


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

['Julien Puydt' via sage-devel]

Hi,

Le 25/10/2017 à 00:08, Eric Gourgoulhon a écrit :
> Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit :
> 
> 
> It is true. But we are hoisted by our own petard : from our tutorial
>  :
> "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")...
> 
>  
> I have the feeling that the current tendency is towards a more modular
> and lighter Sage, which deviates from the original "batteries included"
> philosophy. Maybe the latter should be rephrased as "mathematical
> batteries included". This would exclude standard "technical"  software
> like OpenSSL, which should be provided systemwide.

I'd vote for a strict separation of sage-the-distribution and
sage-the-software : I'm not interested at all in the former, and I think
it hampers the latter for which I care.

Snark on #sagemath

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[William Stein]

On Tue, Oct 24, 2017 at 3:08 PM Eric Gourgoulhon 
wrote:

> Thanks Emmanuel for the discussion summary.
>
>
> Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit :
>>
>>
>> It is true. But we are hoisted by our own petard : from our tutorial
>>  :
>> "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")...
>>
>>
> I have the feeling that the current tendency is towards a more modular and
> lighter Sage, which deviates from the original "batteries included"
> philosophy. Maybe the latter should be rephrased as "mathematical batteries
> included". This would exclude standard "technical"  software like OpenSSL,
> which should be provided systemwide.
>

Well said.  I’m the reason for the batteries-included full distribution
Sage approach, and I did it that way entirely out of necessity: very
limited manpower, Python packaging was in disarray, etc., all while
attempting to support many environments like Solaris, Cygwin, OS X,...
Python packaging has improved a lot since 2004, with conda and pip, and
there are a hundred times more people working on Sage.   Git now exists.  I
hope we have further discussions in this list about ways to realize the
vision you have roughly sketched above.


> Eric.
>
> --
> 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.
>
-- 
-- William Stein

-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Eric Gourgoulhon]

Thanks Emmanuel for the discussion summary.

Le mardi 24 octobre 2017 20:58:17 UTC+2, Emmanuel Charpentier a écrit :
>
>
> It is true. But we are hoisted by our own petard : from our tutorial 
>  :
> "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")...
>
>  
I have the feeling that the current tendency is towards a more modular and 
lighter Sage, which deviates from the original "batteries included" 
philosophy. Maybe the latter should be rephrased as "mathematical batteries 
included". This would exclude standard "technical"  software like OpenSSL, 
which should be provided systemwide. 

Eric.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 24 October 2017 at 15:51, Emmanuel Charpentier <
emanuel.charpent...@gmail.com> wrote:

> Final tally
>
>  Yes, we should fully support OpenSSL now, and clarify the licensing issue
> : 9 unambiguous votes :
>
> 


>
>  No, we should wait until OpenSSL finishes fixing their license situation
> formally : 4 unambiguous votes.
>
> 

Other participants to discussion, which did not formally vote, or "threw
> their vote away" ((C) Michael Orlitzky) in favor of another option : 10
> people
>


> David Joyner
> Michael Orlitzky
> Nicolas M Thiéry
> Dr David Kirby
> Thierry (sage-googlesucks@xxx)
> kcrisman
> John H Palmieri
>
> The ayes still have it.
>

I think it is unjust to conclude the ayes have it, when the question was
ill posed, and the largest group did not vote for either of the "options"
you have.

There's the very real possibility that OpenSSL may never change their
license in a way that's compatible with the GPL, but your second option
assumes they will formally fix their license - a license that some OpenSSL
developers at least see does not need fixing.



Dave

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mardi 24 octobre 2017 21:34:18 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-24 20:58, Emmanuel Charpentier wrote: 
> > A non-communicating R in Sage can be very useful if you are not using R 
> > in Sage at all 
>
> I just meant to say that if you don't use R, then it's fine to have a 
> non-communicating R. I admit that the wording was a bit cryptic. 
>

No : that was oxymoric : something that you don't use can't, by definition 
and etymology, be useful...

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-24 20:58, Emmanuel Charpentier wrote:

A non-communicating R in Sage can be very useful if you are not using R
in Sage at all


I just meant to say that if you don't use R, then it's fine to have a 
non-communicating R. I admit that the wording was a bit cryptic.


--
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

*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 
 :
"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 
 
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 
 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 
,  and 
some have remarked 
 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 
 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 
) 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 " (a 
solitary kind of sage 

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Final tally

While I wasn't able to retrieve Eroik's message where he changed his vote, 
his request is consistent with his remarls.
 Hence the final tally :

 Yes, we should fully support OpenSSL now, and clarify the licensing issue 
: 9 unambiguous votes :


Dima Pasechnik 

William Stein 

John Cremona 

David Roe 

Nathan Dunfield 

Richard_L 

Marteen Derickx 

Luca de Feo 

Eric Gourgoulhon 

Emmanuel Charpentier 


 


 No, we should wait until OpenSSL finishes fixing their license situation 
formally : 4 unambiguous votes.


Jeroen Demeyer 

Ralf Stephan 

Snark  
Erik bray 

Other participants to discussion, which did not formally vote, or "threw 
their vote away" ((C) Michael Orlitzky) in favor of another option : 10 
people
David Joyner
Michael Orlitzky
Nicolas M Thiéry
Dr David Kirby
Thierry (sage-googlesucks@xxx)
kcrisman
John H Palmieri

The ayes still have it.

The remarks abstract still needs a bit of work (furthermore, RealLife (TM) 
is currently playing tricks on me). The posts resulting from the vote and 
these remarks will appear some time this week.

HTH,

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 6:31 PM, Dima Pasechnik  wrote:
> There are various https-only software repos, not only Python or R-relayed. 
> IIRC kernel.org is one of them. Without SSL headers one cannot build tools to 
> access such repos; e.g. there are no such headers in Xcode.
> One may keep repeating "optional" etc mantras, but it does not make 
> non-functioning tools functioning, SSL is one of feature creeping and 
> becoming de facto standard, just as one cannot really build a functioning 
> single-thread CPython, even though it is officially not acknowledged...

Heh, actually it has been.  In CPython 3.7dev the ability to even
build CPython without threads was quietly dropped a few weeks ago.
There was little objection.  It used to be there were very good
reasons to keep that ability, particularly for smaller devices;
microcontrollers, etc.  But now MicroPython exists as the
officially-blessed CPython fork aimed at such platforms.

Anyways, as insistent as I am on this it's still a minor point.  I'm
completely in favor of making SSL a required feature for any binary
distribution of Sage.  I just think it should not fail completely to
build without it.  I changed my vote to "No" only because after
discussion in the thread I was convinced that the proposed options
were not complete.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

There are various https-only software repos, not only Python or R-relayed. IIRC 
kernel.org is one of them. Without SSL headers one cannot build tools to access 
such repos; e.g. there are no such headers in Xcode. 
One may keep repeating "optional" etc mantras, but it does not make 
non-functioning tools functioning, SSL is one of feature creeping and becoming 
de facto standard, just as one cannot really build a functioning single-thread 
CPython, even though it is officially not acknowledged...

Dima

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 4:16 PM, Nathan Dunfield  wrote:
> On Monday, October 23, 2017 at 7:32:03 AM UTC-5, Erik Bray wrote:
>>
>> > I also balk at the idea of shipping a crippled pip.
>>
>> It's not crippled if you don't need it to install from HTTPS which not
>> everyone does.
>
>
> I agree with Emmanuel that providing "pip" without HTTPS is shipping a
> broken product.  While there are other uses for "pip", by far the most
> common is to install Python packages off PyPI, which requires HTTPS.

It is literally not a broken product.  In fact support for SSL was
deliberately made optional (minus the time it wasn't due to a bug)
because PyPI is not the only use for pip and never was the only use.
Likewise for R's package.install() it supports other sources than CRAN
and as far as I can tell always has.

If you look at my message a little further up I was explicit that in
the common case of "average users", from the Sage perspective, we
definitely want to support this functionality.  From a software design
perspective, however, it doesn't make sense to unconditionally require
SSL when all other features of the software, including package
installation from other sources, works without it.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[John H Palmieri]

By the way, on OS X, an SSL-enabled curl is installed along with Xcode, so 
if we use that in Sage, I wonder if R will work with full functionality. 
(See #24081.) If so, OpenSSL would only be "needed" for Sage's pip.

  John


On Monday, October 23, 2017 at 9:05:16 AM UTC-7, Erik Bray wrote:
>
> On Mon, Oct 23, 2017 at 5:15 PM, Emmanuel Charpentier 
>  wrote: 
> > 
> >> 
> >> Other participants to discussion, which did not formally vote, or 
> "threw 
> >> their vote away" ((C) Michael Orlitzky) in favor of another option : 10 
> >> people 
> > 
> > 
> > No : make that 7 people... 
> > 
> >> 
> >> David Joyner 
> >> Michael Orlitzky 
> >> Nicolas M Thiéry 
> >> Dr David Kirby 
> >> Thierry (sage-googlesucks@xxx) 
> >> kcrisman 
> >> John H Palmieri 
> > 
> > 
> > Thats seven indeed... Sorry for that lapsus. I was probably thinking of 
> the 
> > sum of discussant + "No" voters... 
>
> I should note that up thread I think I changed my vote to "No", but 
> really there should be a third option specifically along the lines of 
> "support SSL optionally". 
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 5:15 PM, Emmanuel Charpentier
 wrote:
>
>>
>> Other participants to discussion, which did not formally vote, or "threw
>> their vote away" ((C) Michael Orlitzky) in favor of another option : 10
>> people
>
>
> No : make that 7 people...
>
>>
>> David Joyner
>> Michael Orlitzky
>> Nicolas M Thiéry
>> Dr David Kirby
>> Thierry (sage-googlesucks@xxx)
>> kcrisman
>> John H Palmieri
>
>
> Thats seven indeed... Sorry for that lapsus. I was probably thinking of the
> sum of discussant + "No" voters...

I should note that up thread I think I changed my vote to "No", but
really there should be a third option specifically along the lines of
"support SSL optionally".

-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

 
>
> Other participants to discussion, which did not formally vote, or "threw 
> their vote away" ((C) Michael Orlitzky) in favor of another option : 10 
> people
>

No : make that 7 people...
 

> David Joyner
> Michael Orlitzky
> Nicolas M Thiéry
> Dr David Kirby
> Thierry (sage-googlesucks@xxx)
> kcrisman
> John H Palmieri
>

Thats seven indeed... Sorry for that lapsus. I was probably thinking of the 
sum of discussant + "No" voters...

--
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Vote tally

Each vote is linked (via google groups) to the last expression of the vote.

 Yes, we should fully support OpenSSL now, and clarify the licensing issue 
: 11 unambiguous votes :


Erik Bray 

Dima Pasechnik 

William Stein 

John Cremona 

David Roe 

Nathan Dunfield 

Richard_L 

Marteen Derickx 

Luca de Feo 

Eric Gourgoulhon 

Emmanuel Charpentier 


 


 No, we should wait until OpenSSL finishes fixing their license situation 
formally : 3 unambiguous votes.


Jeroen Demeyer 

Ralf Stephan 

Snark  
 
Other participants to discussion, which did not formally vote, or "threw 
their vote away" ((C) Michael Orlitzky) in favor of another option : 10 
people
David Joyner
Michael Orlitzky
Nicolas M Thiéry
Dr David Kirby
Thierry (sage-googlesucks@xxx)
kcrisman
John H Palmieri

The ayes have it ;-). One note that even if all the comments without 
explicit votes were turned into "No" votes, the ayes would still have it.

You have up to Tuesday Oct 24, 2017 14h UTC to point errors or omission in 
this tally by mail to the present thread.

A tally of the comments will (not so soon : it's complicated...) be posted 
on sage-devel. A discussion for a porposal for implementation will also be 
posted (in a separate thread).

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Nathan Dunfield]

On Monday, October 23, 2017 at 7:32:03 AM UTC-5, Erik Bray wrote:
>
> > I also balk at the idea of shipping a crippled pip. 
>
> It's not crippled if you don't need it to install from HTTPS which not 
> everyone does.
>

I agree with Emmanuel that providing "pip" without HTTPS is shipping a 
broken product.  While there are other uses for "pip", by far the most 
common is to install Python packages off PyPI, which requires HTTPS.  

For the same reasons Emmanuel lists for R, installing Python packages via 
manual download and then pip breaks down fast for all but the simplest 
packages.  I once installed "snappy" [1] into a copy of SageMath on macOS 
where Sage's pip lacked OpenSSL support via such manual downloads.  I 
succeed but it was quite painful and in any event I'm a maintainer of said 
package...

Best,

Nathan

[1] https://pypi.python.org/pypi/snappy/

-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Vote is closed.

A tally of the vote should follow more or less quickly (I have about a 
hundredth of message to review...).

A tally of the comments will take longer. Expect it at the start of a new 
thread.

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 15:44:09 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 3:28 PM, Emmanuel Charpentier 
>  wrote: 
> >> It should be possible to disable the requirement at 
> >> configure time and fallback to a different default.  It's a shame we 
> >> require a patch for this for now but I can help push for an upstream 
> >> fix to this if need be, because I think it's fairly silly. 
> > 
> > 
> > Could you explain why ? I think that the move towards authentication of 
> the 
> > download sources is a Good Idea (TM), but I may be wrong. In any case, 
> the 
> > "silliness" of this is nor obvious to my dentist's eyes... 
>
> Perhaps this should clarify:  If the CRAN service is switched to using 
> HTTPS, then it can't be accessed without HTTPS.  If the user tries to 
> access the site with software that doesn't have HTTPS support then 
> they are prevented from performing insecure downloads, QED. 
>
> In other words, the security here is being provided by the service. 
> The client is free to decide whether or not they wish to implement 
> their end in order to be able to access the service. 
>

Indeed. But since R is "the software" used to access CRAN, the authors of 
"this software" want to be sre that "saif software" is indeed able to 
access it. Sounds sound to me : not a security problem, but just plain old 
specificatin of an essential requirement.

Where is the silliness ?

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

['Julien Puydt' via sage-devel]

Le 23/10/2017 à 15:40, Emmanuel Charpentier a écrit :
> BTW : the vote closes in about 20 minutes. This is your last chance to
> take back any "too hasty" votes.

My vote: no openSSL now - wait until the license issues are solved

Snark on #sagemath

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 3:28 PM, Emmanuel Charpentier
 wrote:
>> It should be possible to disable the requirement at
>> configure time and fallback to a different default.  It's a shame we
>> require a patch for this for now but I can help push for an upstream
>> fix to this if need be, because I think it's fairly silly.
>
>
> Could you explain why ? I think that the move towards authentication of the
> download sources is a Good Idea (TM), but I may be wrong. In any case, the
> "silliness" of this is nor obvious to my dentist's eyes...

Perhaps this should clarify:  If the CRAN service is switched to using
HTTPS, then it can't be accessed without HTTPS.  If the user tries to
access the site with software that doesn't have HTTPS support then
they are prevented from performing insecure downloads, QED.

In other words, the security here is being provided by the service.
The client is free to decide whether or not they wish to implement
their end in order to be able to access the service.

-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

My vote :

|X| Yes, we should fully support OpenSSL now, and clarify the licensing 
issue.

BTW : the vote closes in about 20 minutes. This is your last chance to take 
back any "too hasty" votes.

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 3:19 PM, Emmanuel Charpentier
 wrote:
>
>
> Le lundi 23 octobre 2017 14:32:03 UTC+2, Erik Bray a écrit :
>>
>> On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
>>  wrote:
>> >
>> >
>> > Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit :
>> >>
>> >> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
>> >>  wrote:
>> >> > Dear Erik,
>> >> >
>> >> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>> >> >>
>> >> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
>> >> >>  wrote:
>> >> >> > Again : R is not only a software package but also an ecosystem.
>> >> >> > The
>> >> >> > 11638
>> >> >> > (as of today) packages available to R users are a large part of R
>> >> >> > usefulness
>> >> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine
>> >> >> > (to
>> >> >> > them, at
>> >> >> > least...).
>> >> >>
>> >> >> I'm not saying it shouldn't be possible to install R packages at
>> >> >> all,
>> >> >> any less than it should be possible to install Python packages.  My
>> >> >> point here was that with Python, for example, one can manually
>> >> >> download a package tarball or wheel from PyPI using, say, curl for
>> >> >> example (maybe if they running on an air-gapped network this was
>> >> >> done
>> >> >> on a separate machine and sneaker-netted over, etc.).  pip can then
>> >> >> install from the manually downloaded package file.
>> >> >>
>> >> >> I don't know if the same is possible with R but you'd think it
>> >> >> should
>> >> >> be.  However R installs packages the sequence still has to be
>> >> >> something like
>> >> >>
>> >> >> 1) Download package from CRAN
>> >> >> 2) Verify that package downloaded successfully (maybe it does this
>> >> >> maybe it doesn't)
>> >> >> 3) Install the package
>> >> >>
>> >> >> So it should be possible to do steps 1 and 2 manually, and then skip
>> >> >> straight to 3.  Admittedly running R on an air-gapped network is
>> >> >> probably not a situation the developers have in mind but I have very
>> >> >> little doubt that the use case exists.
>> >> >
>> >> >
>> >> > Indeed, it *is* possible to install a manually downloaded package
>> >> > (not
>> >> > as
>> >> > straightforward as  the automatic download-and-install default
>> >> > method).
>> >> > But
>> >> > the problem isn't here :
>> >> >
>> >> > There are a large number of CRAN packages (11660 as of this morning).
>> >> > More
>> >> > and more of these packages have mutual dependencies, which are easily
>> >> > accounted for bu install.packages() but are a pain to deal with
>> >> > "manually".
>> >> >
>> >> > In fact, the problem (roughly) has same magnitude as the maintainance
>> >> > of
>> >> > your operating system : it *is* indeed possible to maintain a
>> >> > Unix/Linux
>> >> > installation using only tarballs conveyed to the system via
>> >> > sneakersnet,
>> >> > but
>> >> > it' certainly a) not fun and b) chronophage to the extreme...
>> >> >
>> >> > As it happened with Linux distributions, these intermutual
>> >> > dependencies,
>> >> > which started scarce and lightweight, are getting more and more
>> >> > important.
>> >> > My prediction (or prognostication, or oracle, if you wish...;-) is
>> >> > that
>> >> > they
>> >> > will reach the level of complexity of operating system distributions
>> >> > in
>> >> > an
>> >> > amount of time short enough for this problem to be of interest to all
>> >> > but
>> >> > the oldest (i. e. closest to retirement or death) of R users.
>> >>
>> >> I understand all that, and the same is true of some Python packages as
>> >> well (which is why sometimes Sage winds up having to add quite a few
>> >> spkgs for Python packages--see for example the dependencies of Flask).
>> >> But that's simply a matter that has to be dealt with, and people do
>> >> (*I* do, even, in some cases).
>> >>
>> >> My point here is not that that that's a nice thing to foist on average
>> >> users (it isn't).  Just that it *should* be possible regardless,
>> >> without patching or anything else.  My concern is just why are we
>> >> maintaining a patch just to be able to build R without SSL...
>> >
>> >
>> > ...which is *exactly* my point !
>> >
>> > Presently, the only reason ever given to this patch (which lifts
>> > upstream
>> > R's requirement on an https-enabled library) is to be able to build Sage
>> > without OpenSSL because it's not, in some eyes, GPL-compatible.
>> >
>> > I balk at the idea of maintaining this patch again and again for this
>> > issue,
>> > which can be solved either by depending on a systemwide openssl (but
>> > there
>> > goes our "batteries included" philosophy) or including OpenSSL
>> > (currently
>> > not possible for licensing reasons, but that should change).
>>
>> I agree.
>>
>> > I also balk at the idea of shipping a crippled pip.
>>
>> It's not crippled if you don't need it to install 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 14:43:18 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 2:31 PM, Erik Bray  > wrote: 
> > The same should be true for R, 
> > and if this is not the case (and I'm not convinced it isn't) 
>
> This part I take back.  I see now that in R's configure it really does 
> refuse to proceed if it doesn't find the right libcurl with SSL 
> support.  It's not possible to disable since it's now the default 
> download method.  This is silly though, since other download methods 
> still work.


Probably not as silly as it seems : it pushes users towards SSL downloading 
(for good reasons, I think), while leaving the CRAN mirrors managers some 
time to adapt (i. e. getting an SSL certificate from an acknowledged CA).

I think that a second step is the programmed disappearance of the http 
access to CRAN mirrors. But we're not yet there.
 

> It should be possible to disable the requirement at 
> configure time and fallback to a different default.  It's a shame we 
> require a patch for this for now but I can help push for an upstream 
> fix to this if need be, because I think it's fairly silly. 
>

Could you explain why ? I think that the move towards authentication of the 
download sources is a Good Idea (TM), but I may be wrong. In any case, the 
"silliness" of this is nor obvious to my dentist's eyes...

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 14:32:03 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier 
>  wrote: 
> > 
> > 
> > Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit : 
> >> 
> >> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier 
> >>  wrote: 
> >> > Dear Erik, 
> >> > 
> >> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit : 
> >> >> 
> >> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier 
> >> >>  wrote: 
> >> >> > Again : R is not only a software package but also an ecosystem. 
> The 
> >> >> > 11638 
> >> >> > (as of today) packages available to R users are a large part of R 
> >> >> > usefulness 
> >> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine 
> (to 
> >> >> > them, at 
> >> >> > least...). 
> >> >> 
> >> >> I'm not saying it shouldn't be possible to install R packages at 
> all, 
> >> >> any less than it should be possible to install Python packages.  My 
> >> >> point here was that with Python, for example, one can manually 
> >> >> download a package tarball or wheel from PyPI using, say, curl for 
> >> >> example (maybe if they running on an air-gapped network this was 
> done 
> >> >> on a separate machine and sneaker-netted over, etc.).  pip can then 
> >> >> install from the manually downloaded package file. 
> >> >> 
> >> >> I don't know if the same is possible with R but you'd think it 
> should 
> >> >> be.  However R installs packages the sequence still has to be 
> >> >> something like 
> >> >> 
> >> >> 1) Download package from CRAN 
> >> >> 2) Verify that package downloaded successfully (maybe it does this 
> >> >> maybe it doesn't) 
> >> >> 3) Install the package 
> >> >> 
> >> >> So it should be possible to do steps 1 and 2 manually, and then skip 
> >> >> straight to 3.  Admittedly running R on an air-gapped network is 
> >> >> probably not a situation the developers have in mind but I have very 
> >> >> little doubt that the use case exists. 
> >> > 
> >> > 
> >> > Indeed, it *is* possible to install a manually downloaded package 
> (not 
> >> > as 
> >> > straightforward as  the automatic download-and-install default 
> method). 
> >> > But 
> >> > the problem isn't here : 
> >> > 
> >> > There are a large number of CRAN packages (11660 as of this morning). 
> >> > More 
> >> > and more of these packages have mutual dependencies, which are easily 
> >> > accounted for bu install.packages() but are a pain to deal with 
> >> > "manually". 
> >> > 
> >> > In fact, the problem (roughly) has same magnitude as the maintainance 
> of 
> >> > your operating system : it *is* indeed possible to maintain a 
> Unix/Linux 
> >> > installation using only tarballs conveyed to the system via 
> sneakersnet, 
> >> > but 
> >> > it' certainly a) not fun and b) chronophage to the extreme... 
> >> > 
> >> > As it happened with Linux distributions, these intermutual 
> dependencies, 
> >> > which started scarce and lightweight, are getting more and more 
> >> > important. 
> >> > My prediction (or prognostication, or oracle, if you wish...;-) is 
> that 
> >> > they 
> >> > will reach the level of complexity of operating system distributions 
> in 
> >> > an 
> >> > amount of time short enough for this problem to be of interest to all 
> >> > but 
> >> > the oldest (i. e. closest to retirement or death) of R users. 
> >> 
> >> I understand all that, and the same is true of some Python packages as 
> >> well (which is why sometimes Sage winds up having to add quite a few 
> >> spkgs for Python packages--see for example the dependencies of Flask). 
> >> But that's simply a matter that has to be dealt with, and people do 
> >> (*I* do, even, in some cases). 
> >> 
> >> My point here is not that that that's a nice thing to foist on average 
> >> users (it isn't).  Just that it *should* be possible regardless, 
> >> without patching or anything else.  My concern is just why are we 
> >> maintaining a patch just to be able to build R without SSL... 
> > 
> > 
> > ...which is *exactly* my point ! 
> > 
> > Presently, the only reason ever given to this patch (which lifts 
> upstream 
> > R's requirement on an https-enabled library) is to be able to build Sage 
> > without OpenSSL because it's not, in some eyes, GPL-compatible. 
> > 
> > I balk at the idea of maintaining this patch again and again for this 
> issue, 
> > which can be solved either by depending on a systemwide openssl (but 
> there 
> > goes our "batteries included" philosophy) or including OpenSSL 
> (currently 
> > not possible for licensing reasons, but that should change). 
>
> I agree. 
>
> > I also balk at the idea of shipping a crippled pip. 
>
> It's not crippled if you don't need it to install from HTTPS which not 
> everyone does. 
>

Unless I'm mistaken, pip won't  instamm from Pipy if https isn't enabled. 
Isn't that an important source of Python modules ?

Okay.  I think 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 2:31 PM, Erik Bray  wrote:
> The same should be true for R,
> and if this is not the case (and I'm not convinced it isn't)

This part I take back.  I see now that in R's configure it really does
refuse to proceed if it doesn't find the right libcurl with SSL
support.  It's not possible to disable since it's now the default
download method.  This is silly though, since other download methods
still work.  It should be possible to disable the requirement at
configure time and fallback to a different default.  It's a shame we
require a patch for this for now but I can help push for an upstream
fix to this if need be, because I think it's fairly silly.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
 wrote:
>
>
> Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit :
>>
>> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
>>  wrote:
>> > Dear Erik,
>> >
>> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>> >>
>> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
>> >>  wrote:
>> >> > Again : R is not only a software package but also an ecosystem. The
>> >> > 11638
>> >> > (as of today) packages available to R users are a large part of R
>> >> > usefulness
>> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to
>> >> > them, at
>> >> > least...).
>> >>
>> >> I'm not saying it shouldn't be possible to install R packages at all,
>> >> any less than it should be possible to install Python packages.  My
>> >> point here was that with Python, for example, one can manually
>> >> download a package tarball or wheel from PyPI using, say, curl for
>> >> example (maybe if they running on an air-gapped network this was done
>> >> on a separate machine and sneaker-netted over, etc.).  pip can then
>> >> install from the manually downloaded package file.
>> >>
>> >> I don't know if the same is possible with R but you'd think it should
>> >> be.  However R installs packages the sequence still has to be
>> >> something like
>> >>
>> >> 1) Download package from CRAN
>> >> 2) Verify that package downloaded successfully (maybe it does this
>> >> maybe it doesn't)
>> >> 3) Install the package
>> >>
>> >> So it should be possible to do steps 1 and 2 manually, and then skip
>> >> straight to 3.  Admittedly running R on an air-gapped network is
>> >> probably not a situation the developers have in mind but I have very
>> >> little doubt that the use case exists.
>> >
>> >
>> > Indeed, it *is* possible to install a manually downloaded package (not
>> > as
>> > straightforward as  the automatic download-and-install default method).
>> > But
>> > the problem isn't here :
>> >
>> > There are a large number of CRAN packages (11660 as of this morning).
>> > More
>> > and more of these packages have mutual dependencies, which are easily
>> > accounted for bu install.packages() but are a pain to deal with
>> > "manually".
>> >
>> > In fact, the problem (roughly) has same magnitude as the maintainance of
>> > your operating system : it *is* indeed possible to maintain a Unix/Linux
>> > installation using only tarballs conveyed to the system via sneakersnet,
>> > but
>> > it' certainly a) not fun and b) chronophage to the extreme...
>> >
>> > As it happened with Linux distributions, these intermutual dependencies,
>> > which started scarce and lightweight, are getting more and more
>> > important.
>> > My prediction (or prognostication, or oracle, if you wish...;-) is that
>> > they
>> > will reach the level of complexity of operating system distributions in
>> > an
>> > amount of time short enough for this problem to be of interest to all
>> > but
>> > the oldest (i. e. closest to retirement or death) of R users.
>>
>> I understand all that, and the same is true of some Python packages as
>> well (which is why sometimes Sage winds up having to add quite a few
>> spkgs for Python packages--see for example the dependencies of Flask).
>> But that's simply a matter that has to be dealt with, and people do
>> (*I* do, even, in some cases).
>>
>> My point here is not that that that's a nice thing to foist on average
>> users (it isn't).  Just that it *should* be possible regardless,
>> without patching or anything else.  My concern is just why are we
>> maintaining a patch just to be able to build R without SSL...
>
>
> ...which is *exactly* my point !
>
> Presently, the only reason ever given to this patch (which lifts upstream
> R's requirement on an https-enabled library) is to be able to build Sage
> without OpenSSL because it's not, in some eyes, GPL-compatible.
>
> I balk at the idea of maintaining this patch again and again for this issue,
> which can be solved either by depending on a systemwide openssl (but there
> goes our "batteries included" philosophy) or including OpenSSL (currently
> not possible for licensing reasons, but that should change).

I agree.

> I also balk at the idea of shipping a crippled pip.

It's not crippled if you don't need it to install from HTTPS which not
everyone does.

Okay.  I think I see the problem here.  We're talking about multiple
issues simultaneously and some things are getting confused--some
streams crossed.

First: There is the *general* issue of whether or not these packages
need any kind of SSL support in order to function.  This is an issue
*completely* independent from Sage (except insofar as we may or may
not need to maintain some patches to ensure that they don't require
SSL, but that is a separate issue that I will get to next).  From the
general standpoint of pip's design and functionality, it does 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier 
>  wrote: 
> > Dear Erik, 
> > 
> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit : 
> >> 
> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier 
> >>  wrote: 
> >> > Again : R is not only a software package but also an ecosystem. The 
> >> > 11638 
> >> > (as of today) packages available to R users are a large part of R 
> >> > usefulness 
> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to 
> >> > them, at 
> >> > least...). 
> >> 
> >> I'm not saying it shouldn't be possible to install R packages at all, 
> >> any less than it should be possible to install Python packages.  My 
> >> point here was that with Python, for example, one can manually 
> >> download a package tarball or wheel from PyPI using, say, curl for 
> >> example (maybe if they running on an air-gapped network this was done 
> >> on a separate machine and sneaker-netted over, etc.).  pip can then 
> >> install from the manually downloaded package file. 
> >> 
> >> I don't know if the same is possible with R but you'd think it should 
> >> be.  However R installs packages the sequence still has to be 
> >> something like 
> >> 
> >> 1) Download package from CRAN 
> >> 2) Verify that package downloaded successfully (maybe it does this 
> >> maybe it doesn't) 
> >> 3) Install the package 
> >> 
> >> So it should be possible to do steps 1 and 2 manually, and then skip 
> >> straight to 3.  Admittedly running R on an air-gapped network is 
> >> probably not a situation the developers have in mind but I have very 
> >> little doubt that the use case exists. 
> > 
> > 
> > Indeed, it *is* possible to install a manually downloaded package (not 
> as 
> > straightforward as  the automatic download-and-install default method). 
> But 
> > the problem isn't here : 
> > 
> > There are a large number of CRAN packages (11660 as of this morning). 
> More 
> > and more of these packages have mutual dependencies, which are easily 
> > accounted for bu install.packages() but are a pain to deal with 
> "manually". 
> > 
> > In fact, the problem (roughly) has same magnitude as the maintainance of 
> > your operating system : it *is* indeed possible to maintain a Unix/Linux 
> > installation using only tarballs conveyed to the system via sneakersnet, 
> but 
> > it' certainly a) not fun and b) chronophage to the extreme... 
> > 
> > As it happened with Linux distributions, these intermutual dependencies, 
> > which started scarce and lightweight, are getting more and more 
> important. 
> > My prediction (or prognostication, or oracle, if you wish...;-) is that 
> they 
> > will reach the level of complexity of operating system distributions in 
> an 
> > amount of time short enough for this problem to be of interest to all 
> but 
> > the oldest (i. e. closest to retirement or death) of R users. 
>
> I understand all that, and the same is true of some Python packages as 
> well (which is why sometimes Sage winds up having to add quite a few 
> spkgs for Python packages--see for example the dependencies of Flask). 
> But that's simply a matter that has to be dealt with, and people do 
> (*I* do, even, in some cases). 
>
> My point here is not that that that's a nice thing to foist on average 
> users (it isn't).  Just that it *should* be possible regardless, 
> without patching or anything else.  My concern is just why are we 
> maintaining a patch just to be able to build R without SSL... 
>

...which is **exactly** my point !

Presently, the only reason ever given to this patch (which lifts upstream 
R's requirement on an https-enabled library) is to be able to build Sage 
without OpenSSL because it's not, in some eyes, GPL-compatible.
 
I balk at the idea of maintaining this patch again and again for this 
issue, which can be solved either by depending on a systemwide openssl (but 
there goes our "batteries included" philosophy) or including OpenSSL 
(currently not possible for licensing reasons, but that should change).

I also balk at the idea of shipping a crippled pip.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Dear Jeroen

Le lundi 23 octobre 2017 11:24:18 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-19 17:21, Emmanuel Charpentier wrote: 
> > I do not think that a 
> > non-communicating R is useful in Sage. 
>
> 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). 
>

? You are saying that X is useful if you don't use X at all ?

Either :

   - I totally miss your point : I can't see how something can be useful if 
   you don't use it at all. Or :
   - either :
  - you are a Zen master using padoxes to enlighten your student (and 
  you failed to do so) ;
  - you are a dandy  enjoying paradoxes for the hell of it ;
  - you are preparing for a career in management or politics.
   
Would you care to explain to a dentist of very little mind ?

as for "which is very likely the vast majority of Sage users" : I do not 
know. I agree that I seem to be the only such voice on the sage-xxx lists. 
Which might be a strong argument for splitting R off Sage
 as already discussed on sage devel, and still discussed in this thread 
. But the 
last time this was discussed, the agreement seemed to be that R had to stay 
in Sage.

And that does *not* solve "our" pip's lack of functionality, nor the 
(interesting) security problem raised by Thierry.

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
 wrote:
> Dear Erik,
>
> Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>>
>> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
>>  wrote:
>> > Again : R is not only a software package but also an ecosystem. The
>> > 11638
>> > (as of today) packages available to R users are a large part of R
>> > usefulness
>> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to
>> > them, at
>> > least...).
>>
>> I'm not saying it shouldn't be possible to install R packages at all,
>> any less than it should be possible to install Python packages.  My
>> point here was that with Python, for example, one can manually
>> download a package tarball or wheel from PyPI using, say, curl for
>> example (maybe if they running on an air-gapped network this was done
>> on a separate machine and sneaker-netted over, etc.).  pip can then
>> install from the manually downloaded package file.
>>
>> I don't know if the same is possible with R but you'd think it should
>> be.  However R installs packages the sequence still has to be
>> something like
>>
>> 1) Download package from CRAN
>> 2) Verify that package downloaded successfully (maybe it does this
>> maybe it doesn't)
>> 3) Install the package
>>
>> So it should be possible to do steps 1 and 2 manually, and then skip
>> straight to 3.  Admittedly running R on an air-gapped network is
>> probably not a situation the developers have in mind but I have very
>> little doubt that the use case exists.
>
>
> Indeed, it *is* possible to install a manually downloaded package (not as
> straightforward as  the automatic download-and-install default method). But
> the problem isn't here :
>
> There are a large number of CRAN packages (11660 as of this morning). More
> and more of these packages have mutual dependencies, which are easily
> accounted for bu install.packages() but are a pain to deal with "manually".
>
> In fact, the problem (roughly) has same magnitude as the maintainance of
> your operating system : it *is* indeed possible to maintain a Unix/Linux
> installation using only tarballs conveyed to the system via sneakersnet, but
> it' certainly a) not fun and b) chronophage to the extreme...
>
> As it happened with Linux distributions, these intermutual dependencies,
> which started scarce and lightweight, are getting more and more important.
> My prediction (or prognostication, or oracle, if you wish...;-) is that they
> will reach the level of complexity of operating system distributions in an
> amount of time short enough for this problem to be of interest to all but
> the oldest (i. e. closest to retirement or death) of R users.

I understand all that, and the same is true of some Python packages as
well (which is why sometimes Sage winds up having to add quite a few
spkgs for Python packages--see for example the dependencies of Flask).
But that's simply a matter that has to be dealt with, and people do
(*I* do, even, in some cases).

My point here is not that that that's a nice thing to foist on average
users (it isn't).  Just that it *should* be possible regardless,
without patching or anything else.  My concern is just why are we
maintaining a patch just to be able to build R without SSL...

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Dear Erik,

Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>
> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier 
>  wrote: 
> > Again : R is not only a software package but also an ecosystem. The 
> 11638 
> > (as of today) packages available to R users are a large part of R 
> usefulness 
> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to 
> them, at 
> > least...). 
>
> I'm not saying it shouldn't be possible to install R packages at all, 
> any less than it should be possible to install Python packages.  My 
> point here was that with Python, for example, one can manually 
> download a package tarball or wheel from PyPI using, say, curl for 
> example (maybe if they running on an air-gapped network this was done 
> on a separate machine and sneaker-netted over, etc.).  pip can then 
> install from the manually downloaded package file. 
>
> I don't know if the same is possible with R but you'd think it should 
> be.  However R installs packages the sequence still has to be 
> something like 
>
> 1) Download package from CRAN 
> 2) Verify that package downloaded successfully (maybe it does this 
> maybe it doesn't) 
> 3) Install the package 
>
> So it should be possible to do steps 1 and 2 manually, and then skip 
> straight to 3.  Admittedly running R on an air-gapped network is 
> probably not a situation the developers have in mind but I have very 
> little doubt that the use case exists. 
>

Indeed, it *is* possible to install a manually downloaded package (not as 
straightforward as  the automatic download-and-install default method). But 
the problem isn't here :

There are a large number of CRAN packages (11660 as of this morning). More 
and more of these packages have mutual dependencies, which are easily 
accounted for bu install.packages() but are a pain to deal with "manually".

In fact, the problem (roughly) has same magnitude as the maintainance of 
your operating system : it *is* indeed possible to maintain a Unix/Linux 
installation using only tarballs conveyed to the system via sneakersnet, 
but it' certainly a) not fun and b) chronophage to the extreme...

As it happened with Linux distributions, these intermutual dependencies, 
which started scarce and lightweight, are getting more and more important. 
My prediction (or prognostication, or oracle, if you wish...;-) is that 
they will reach the level of complexity of operating system distributions 
in an amount of time short enough for this problem to be of interest to all 
but the oldest (i. e. closest to retirement or death) of R users.

I'm not old enough to not feel concerned ;-)...

> And, BTW : which is your vote ? 
>
> My vote now is for a re-vote :) 
>

Not possible,  given the terms of the vote (I can't pull an after-the-fact 
rule on the people who have already voted). But whatever the result is, 
there will remain the question of implementation, which might need a formal 
vote on sub-issues and methods

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 11:28 AM, Erik Bray  wrote:
> On Mon, Oct 23, 2017 at 11:24 AM, Jeroen Demeyer  
> wrote:
>> On 2017-10-19 17:21, Emmanuel Charpentier wrote:
>>>
>>> I do not think that a
>>> non-communicating R is useful in Sage.
>>
>>
>> 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).
>
> Or, as you and I have both pointed out, you *are* using R but would
> prefer to use a different download method than the one built into R
> (which may still use HTTPS, especially if it's necessary to access
> CRAN at all, but that doesn't mean R has to be the one doing the
> downloading).

Doing a little more research on this*, it seems that R can in fact
perfectly well install packages from compressed tarballs, etc.
(through the UI, importantly).  For downloading files it actually
supports multiple download methods, one of which is to use libcurl
(which can be built without HTTPS support; I've done so myself).  But
it also has a built-in "internal" method which may be part of the
problem.  If that can't be built without SSL support then that needs
to be fixed.  Finally, it also supports pointing to alternative
package repositories which may or may not use HTTPS.

Naturally, for the "average" user we *do* want to support transparent
package installation from CRAN with HTTPS support which is why the
OpenSSL issue needs to be resolved.  But assuming that R *can* be
built without SSL, and can work without SSL, that is acceptable too
especially for users who know what they're doing and don't need the
SSL support.  I suggest that this be allowed to proceed, just with a
loud warning (as Thierry suggested).  I'll have a look at your patch
to see what it's doing and if such a patch really needs to be
maintained or not...


* https://www.rdocumentation.org/packages/utils/versions/3.4.1/topics/INSTALL
  
https://www.rdocumentation.org/packages/utils/versions/3.4.1/topics/install.packages
  https://www.rdocumentation.org/link/download.file?package=utils=3.4.1

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 11:24 AM, Jeroen Demeyer  wrote:
> On 2017-10-19 17:21, Emmanuel Charpentier wrote:
>>
>> I do not think that a
>> non-communicating R is useful in Sage.
>
>
> 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).

Or, as you and I have both pointed out, you *are* using R but would
prefer to use a different download method than the one built into R
(which may still use HTTPS, especially if it's necessary to access
CRAN at all, but that doesn't mean R has to be the one doing the
downloading).

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-19 17:21, Emmanuel Charpentier wrote:

I do not think that a
non-communicating R is useful in Sage.


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).


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Fri, Oct 20, 2017 at 10:58 AM, Jeroen Demeyer  wrote:
> On 2017-10-19 20:07, Luca De Feo wrote:
>>
>> There you go for something crippled!  https://shattered.io/
>
>
> I don't think that this is actually relevant. This attack would only work if
> an attacker is able to provide a specially manufactured source tarball and
> get it accepted by SageMath. At that point, the attacker could instead just
> insert arbitrary code in the source tarball.

That's not true.  The whole point is that HTTP is ridiculously easy to
hijack, so an attacker need not get anything accepted by Sage.

It's an unlikely attack vector to be sure, but not impossible.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Thu, Oct 19, 2017 at 10:56 PM, Thierry
 wrote:
> Hi,
>
> On Thu, Oct 19, 2017 at 08:07:19PM +0200, Luca De Feo wrote:
>> |X| Yes, we should fully support OpenSSL now, and clarify the
>> licensing issue.
>>
>> > the way our
>> > "package manager" works allows to install an optional package without
>> > having to rely on openssl (no https), we only rely on the computation of
>> > sha1
>>
>> There you go for something crippled!  https://shattered.io/
>
> sha256 is also supported by python-hashlib compiled without openssl
> support, so we could/should easily move to using it in Sage "package
> manager" (build/sage_bootstrap/tarball.py).

+1 to switching to and/or adding support for SHA-256 hashes.  As
Thierry noted that are several SHA-256 implementations for Python, in
fact, that don't rely in any way on OpenSSL or have problematic
licenses.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Thu, Oct 19, 2017 at 5:21 PM, Emmanuel Charpentier
 wrote:
>
>
> Le mercredi 18 octobre 2017 20:36:47 UTC+2, Jeroen Demeyer a écrit :
>>
>> On 2017-10-18 19:02, Emmanuel Charpentier wrote:
>> > This option commits us to maintain (unnecessary and dangerous, IMHO)
>> > Sage-specifc SSL patches at least in R, Python and pip
>>
>> Really? Which Sage-specific SSL patches does this require in Python and
>> pip? *
>
>
> From the Python license page :
>
> The modules hashlib, posix, ssl, crypt use the OpenSSL library for added
> performance if made available by the operating system. Additionally, the
> Windows and Mac OS X installers for Python may include a copy of the OpenSSL
> libraries, so we include a copy of the OpenSSL license here:

All of this is talking about optional functionality--either modules
that are completely optional, or functionality within some modules
that are optional.  Python works just fine without SSL support.

>> It seems to me that R is the only package causing us so much trouble
>> with SSL.
>
>
> No : *I* cause "so much trouble" with SSL issues because they become
> important to R real-world usage, and I do not think that a non-communicating
> R is useful in Sage.  Python/pip SSL usage do not cause "so much trouble"
> with SSL issues because the potential users of SSL functionalities are more
> patient than I am...

Ditto William on thanking you for causing this "trouble".  I know this
is a battle you've been fighting a long time and I really hope we can
come to a resolution soon.  In pointing out that SSL is not an issue
where Python is concerned I hope it alleviates some of your concerns.
Hopefully we can browbeat R into making the same acceptance (at least
insofar as allowing offline package installs).

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
 wrote:
> Again : R is not only a software package but also an ecosystem. The 11638
> (as of today) packages available to R users are a large part of R usefulness
> to its users. So, "disabling downloads from CRAN" is *NOT* fine (to them, at
> least...).

I'm not saying it shouldn't be possible to install R packages at all,
any less than it should be possible to install Python packages.  My
point here was that with Python, for example, one can manually
download a package tarball or wheel from PyPI using, say, curl for
example (maybe if they running on an air-gapped network this was done
on a separate machine and sneaker-netted over, etc.).  pip can then
install from the manually downloaded package file.

I don't know if the same is possible with R but you'd think it should
be.  However R installs packages the sequence still has to be
something like

1) Download package from CRAN
2) Verify that package downloaded successfully (maybe it does this
maybe it doesn't)
3) Install the package

So it should be possible to do steps 1 and 2 manually, and then skip
straight to 3.  Admittedly running R on an air-gapped network is
probably not a situation the developers have in mind but I have very
little doubt that the use case exists.

> And, BTW : which is your vote ?

My vote now is for a re-vote :)

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le vendredi 20 octobre 2017 10:58:32 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-19 20:07, Luca De Feo wrote: 
> > There you go for something crippled!  https://shattered.io/ 
>
> I don't think that this is actually relevant. This attack would only 
> work if an attacker is able to provide a specially manufactured source 
> tarball and get it accepted by SageMath. At that point, the attacker 
> could instead just insert arbitrary code in the source tarball. 
>

Wrong : a MITM attack could be used to redirect you to a doctored 
repository. Ditto, BTW, for a DNS attack... HTTPS offers *some* saveguards 
against that..  

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[David Joyner]

On Sat, Oct 21, 2017 at 12:02 PM, Eric Gourgoulhon
 wrote:
> Hi,
>
> Having read the discussion, I would add a big +1 to what Thierry proposes in
> https://groups.google.com/d/msg/sage-devel/fE45025Wphs/FheYtjBWAAAJ
>
> So I guess that in terms of vote this means
>
> |X| Yes, we should fully support OpenSSL now, and clarify the licensing
> issue.
>
> BUT following Thierry's procedure:
>
> - check if libssl-dev (or similar) is installed on the OS
>   - yes:
> - use it
>   - no:
> - strongly complain about it, provide documentation on how to do it
>   (possibly provide a doc that depends on the system),
> - propose 3 options:
> - "i will install openssl from the distro, and come back later
>   (recommended)"
> - "i want Sage to install openssl optional package, i know that
>   there will be security issues"
> - "i do not want openssl support, i know that i will not be able
>   to install any R or Python package from the web"
>

I agree with this too.

On a related matter (discussed in this thread and another one), I would not
object if we dropped the distribution of R, except maybe for cocalc.com,
but supporting the interface with the system R.
As a data point: in my dept lots of people use R and lots use SageMath
but none use the R in SageMath.

> Best wishes,
>
> Eric.
>
> --
> 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.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le vendredi 20 octobre 2017 10:51:17 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-19 17:19, Emmanuel Charpentier wrote: 
> > Again : R is not only a software package but also an ecosystem. 
>
> But why? One could say the same for Python, but you can still install 
> Python without OpenSSL. 
>

There might be practical use of {Sage|Python} without having to download. 
But... 

>
> What if I simply want to use R without any external packages? Or what if 
> I want to download/install packages in a different way? 
>

You may accept to hop through flaming circles in effect to accomplish what 
is specified in the R documentation as a simple operation. Tou may also 
accept to lose the benefits of the package management system of R 
(dependencies, version checking and the like...). Mos "normal" R users 
wont't stand it.

Furthermore, by refusing to ensure the presence of a library necessary to 
R, you force the poor sod willing to maintain R (me, currently), to 
maintaint a patch that serves no useful purpose other that to protect your 
precious OpenSSL maidenhood. That's a bit rich...

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le vendredi 20 octobre 2017 10:49:40 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-19 17:24, William Stein wrote: 
> > Good, as well they should.   Like you, they likely feel a responsibility 
> > to their users to do the right thing regarding security.   I really 
> > appreciate the "so much trouble" you are "causing" Emmanuel. 
>
> I also agree here. The only options should be "use https" or "don't 
> download anything". That's exactly what pip does. 
>
> And the fly in the ointment is that, for example, "our" pip doesn't give 
us the choice. It forces us to "don't download anything'...

I'm afraid that R users will sooner or later be confronted to the same 
choice. In Hobson's variant if we don't have an https-enabled SSL library. 
Nowadays, that means OpenSSL...

--
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Eric Gourgoulhon]

Hi,

Having read the discussion, I would add a big +1 to what Thierry proposes in
https://groups.google.com/d/msg/sage-devel/fE45025Wphs/FheYtjBWAAAJ

So I guess that in terms of vote this means

|X| Yes, we should fully support OpenSSL now, and clarify the licensing 
issue.

BUT following Thierry's procedure:

- check if libssl-dev (or similar) is installed on the OS 
  - yes: 
- use it 
  - no: 
- strongly complain about it, provide documentation on how to do it 
  (possibly provide a doc that depends on the system), 
- propose 3 options: 
- "i will install openssl from the distro, and come back later 
  (recommended)" 
- "i want Sage to install openssl optional package, i know that 
  there will be security issues" 
- "i do not want openssl support, i know that i will not be able 
  to install any R or Python package from the web" 

Best wishes,

Eric.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

In fact, John pointed out that I am wrong; while openssl is supported by 
Xcode binaries, there are no headers available!
(it used to be the case that they were present in some hidden directories, 
but this seems to be not true any more)

On Friday, October 20, 2017 at 7:20:17 PM UTC+1, kcrisman wrote:
>
>
>
> On Thursday, October 19, 2017 at 6:29:46 PM UTC-4, John H Palmieri wrote:
>>
>>
>>
>> On Thursday, October 19, 2017 at 2:17:10 PM UTC-7, Dima Pasechnik wrote:
>>>
>>> the 1-click openssl install image for OSX is called Xcode, and one can 
>>> go for a long lunch while waiting for it to finish, even on a fast 
>>> network...
>>
>>
> Oh, but that's not the same thing as "it's sitting on your screen". 
>  Asking people to install all of Xcode does seem a bit excessive, given 
> that we currently don't ask people to even install the developer tools 
> unless they want to do developing (or Cython, probably).
>  
>
>> Apple should pick up the bill for these lunches, and much more, I fully 
>>> agree.
>>>
>>
>>  
> True.
>  
>
>> But I don't think that Xcode includes the openssl headers. At least I've 
>> never been able to find them. Plus perhaps their installed versions of 
>> libssl are outdated? That's what I've heard about their reasons for not 
>> including the header files.
>>
>>
>  And just having headers isn't the same as "it just works" unless they go 
> in the right place, I suppose.
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[kcrisman]

On Thursday, October 19, 2017 at 6:29:46 PM UTC-4, John H Palmieri wrote:
>
>
>
> On Thursday, October 19, 2017 at 2:17:10 PM UTC-7, Dima Pasechnik wrote:
>>
>> the 1-click openssl install image for OSX is called Xcode, and one can go 
>> for a long lunch while waiting for it to finish, even on a fast network...
>
>
Oh, but that's not the same thing as "it's sitting on your screen".  Asking 
people to install all of Xcode does seem a bit excessive, given that we 
currently don't ask people to even install the developer tools unless they 
want to do developing (or Cython, probably).
 

> Apple should pick up the bill for these lunches, and much more, I fully 
>> agree.
>>
>
>  
True.
 

> But I don't think that Xcode includes the openssl headers. At least I've 
> never been able to find them. Plus perhaps their installed versions of 
> libssl are outdated? That's what I've heard about their reasons for not 
> including the header files.
>
>
 And just having headers isn't the same as "it just works" unless they go 
in the right place, I suppose.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Maarten Derickx]

On Wednesday, 18 October 2017 18:23:53 UTC+2, Thierry 
(sage-googlesucks@xxx) wrote:
>
> Hi, 
>
> the dichotomy of the vote is not clear to me. 
>
> I am -1 to make openssl a stantard package (hence shipped with the source 
> tarball), not only regarding licensing issues but also for security 
> reasons: our "package manager" is such that packages can not be updated 
> unless Sage itself is updated (because the package version is hardcoded). 
> Hence, when a security issue is found and fixed in openssl, the user who 
> installed it from Sage won't get it until the user upgrades Sage (while 
> every decent distro will provide a hotfix). 
>
> However, i am +1 that we should do our best to let the user have an 
> openssl-enabled version of Sage (for pip, R, some cryptographic hash,...), 
> an acceptable workflow could be: 
>
> - check if libssl-dev (or similar) is installed on the OS 
>   - yes: 
> - use it 
>   - no: 
> - strongly complain about it, provide documentation on how to do it 
>   (possibly provide a doc that depends on the system), 
> - propose 3 options: 
> - "i will install openssl from the distro, and come back later 
>   (recommended)" 
> - "i want Sage to install openssl optional package, i know that 
>   there will be security issues" 
> - "i do not want openssl support, i know that i will not be able 
>   to install any R or Python package from the web" 
>
>
+1 for this.
 

> If the last point (compiling Sage without openssl support) requires a lot 
> of work, i am OK to remove it (i am not sure if this is the point of the 
> vote). 
>
> Note that that there is no chicken-and-eggs issue since the way our 
> "package manager" works allows to install an optional package without 
> having to rely on openssl (no https), we only rely on the computation of 
> sha1 which python-hashlib offers even if it is build without openssl 
> support. 
>
> By the way, Sage is not GPL-3+ but GPL-2+. 
>
>  
>
> Mac fans claim that paying a computer 1.5 the price of a random PC with 
> similar charateristics if justified by the fact that OSX is s 
> user-friendly, perhaps didn't they find the openssl one-click installer 
> right in the middle of the screen yet. 
>
> Proposal: require Apple a grant, corresponding to the huge amount of time 
> Sage developpers waste in porting Sage components (not only openssl, just 
> have a look at trac, sage-devel and ask timelines) on their broken and 
> constantly changing OS. This is not our job to help Apple pretend their 
> system is user-friendly, we are losing a lot of energy which could be 
> spent in much more interesting parts of Sage (e.g. mathematics). 
>
>  
>
> Ciao, 
> Thierry 
>
>
>
>
> On Mon, Oct 16, 2017 at 03:08:51AM -0700, Emmanuel Charpentier wrote: 
> > [ The first post started too fast... Sorry for the interruption ! ] 
> > 
> > Following numerous discussions on this list and various Trac tickets*, 
> the 
> > issue of maintaining Sage-specific patches to various components of Sage 
> > emerged again about the proposed upgrade 
> >  of R to 3.4.2 (discussed here 
> > ). 
> William 
> > again raises 
> >  
> the 
> > issue of security. 
> > 
> > Since Trac#22189 , installation 
> of 
> > a systemwide opennssl is recommended (may be too strongly 
> > , in the taste of some 
> respectable 
> > Sage developers...). The ongoing relicensing of OpenSSL should lift the 
> > last barriers to its inclusion in sage. A discussed here 
> > ,, the 
> > probability of a legal problem related to the incusion of this library 
> in 
> > Sage seems infinitesimal. 
> > 
> > It has beeen furthermore suggested 
> >  
> to 
> > add to our licensing (an adaptatin of) the following language, used in 
> Gnu 
> > Wget License (GPL) : 
> > 
> > "Additional permission under GNU GPL version 3 section 7 
> > 
> > If you modify this program, or any covered work, by linking or combining 
> it 
> > with the OpenSSL project's OpenSSL library (or a modified version of 
> that 
> > library), containing parts covered by the terms of the OpenSSL or SSLeay 
> > licenses, the Free Software Foundation grants you additional permission 
> to 
> > convey the resulting work. Corresponding Source for a non-source form of 
> > such a combination shall include the source code for the parts of 
> OpenSSL 
> > used as well as that of the covered work." 
> > 
> > 
> > The proposed inclusion would entail : 
> > 
> >- Deprecation of our OpenSSL-avidance patches 
> >- Standardization of SSL communications on OpenSSL 
> >- At compilation, research 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Luca De Feo]

> That is totally not what I said. We don't care about collision resistance,
> but we still need preimage resistance. That is still fine for SHA1 (even MD5
> as far as I know).

If that's your point, an attacker can produce two colliding packages:
a perfectly sound mathematical package and a malicious one. He gets
the mathematical package accepted by SageMath, then uses the malicious
one to perform the attack.

I'm not saying that's easy to do. The perfectly sound mathematical
package would still have to contain some weird octets, but a package
that looks like, e.g., a database of polynomials, could conceivably
evade detection.

I'm saying all this to satisfy the applied cryptographer in you. There
are certainly easier ways to insert malicious code into Sage (just
create a ticket and have a buddy positive review it), but that's not a
good reason to keep using SHA1.

Luca

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

On Friday, October 20, 2017 at 10:13:54 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2017-10-20 10:54, Dima Pasechnik wrote: 
> > Once upon a time, http was not universally supported, one needed to use 
> > ftp instead. 
>
> You misunderstood my point. It is not about http vs. https. 
>
> What bothers me is that "downloading packages from CRAN" is considered 
> so important by R that it refuses to build when that functionality is 
> not available. 


It is a good reason for stopping shipping R with  Sage, provided that we 
can still have the
needed interfaces  up and  running. Otherwise it seems not too meaningful 
to complain about R here.


Regardless of how important pip is to Python, it is still 
> possible to run Python without pip. And it should be like this: the core 
> functionality should be separated from the package manager. 
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-20 11:32, Luca De Feo wrote:

So according to your point checking the SHA1 is useless, because
attackers are not able to get malicious source tarballs accepted by
SageMath.


That is totally not what I said. We don't care about collision 
resistance, but we still need preimage resistance. That is still fine 
for SHA1 (even MD5 as far as I know).


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Luca De Feo]

>> There you go for something crippled!  https://shattered.io/
>
>
> I don't think that this is actually relevant. This attack would only work if
> an attacker is able to provide a specially manufactured source tarball and
> get it accepted by SageMath. At that point, the attacker could instead just
> insert arbitrary code in the source tarball.

So according to your point checking the SHA1 is useless, because
attackers are not able to get malicious source tarballs accepted by
SageMath.

Anyway, we're digressing. The move to SHA256 needs to be addressed in
another topic, and it is so elementary that we may as well open a
ticket and continue the discussion there.

Luca

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-20 10:54, Dima Pasechnik wrote:

Once upon a time, http was not universally supported, one needed to use
ftp instead.


You misunderstood my point. It is not about http vs. https.

What bothers me is that "downloading packages from CRAN" is considered 
so important by R that it refuses to build when that functionality is 
not available. Regardless of how important pip is to Python, it is still 
possible to run Python without pip. And it should be like this: the core 
functionality should be separated from the package manager.


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-19 20:07, Luca De Feo wrote:

There you go for something crippled!  https://shattered.io/


I don't think that this is actually relevant. This attack would only 
work if an attacker is able to provide a specially manufactured source 
tarball and get it accepted by SageMath. At that point, the attacker 
could instead just insert arbitrary code in the source tarball.


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

On Friday, October 20, 2017 at 9:51:17 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2017-10-19 17:19, Emmanuel Charpentier wrote: 
> > Again : R is not only a software package but also an ecosystem. 
>
> But why? One could say the same for Python, but you can still install 
> Python without OpenSSL. 
>
> What if I simply want to use R without any external packages? Or what if 
> I want to download/install packages in a different way? 
>

Once upon a time, http was not universally supported, one needed to use ftp 
instead.
Nowadays you often need at least http.
That is to say, this point is moot; if you do not want to use https, you're 
on your own.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-19 17:19, Emmanuel Charpentier wrote:

Again : R is not only a software package but also an ecosystem.


But why? One could say the same for Python, but you can still install 
Python without OpenSSL.


What if I simply want to use R without any external packages? Or what if 
I want to download/install packages in a different way?


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-19 17:24, William Stein wrote:

Good, as well they should.   Like you, they likely feel a responsibility
to their users to do the right thing regarding security.   I really
appreciate the "so much trouble" you are "causing" Emmanuel.


I also agree here. The only options should be "use https" or "don't 
download anything". That's exactly what pip does.


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[John H Palmieri]

On Thursday, October 19, 2017 at 2:17:10 PM UTC-7, Dima Pasechnik wrote:
>
> the 1-click openssl install image for OSX is called Xcode, and one can go 
> for a long lunch while waiting for it to finish, even on a fast network...
>
> Apple should pick up the bill for these lunches, and much more, I fully 
> agree.
>

But I don't think that Xcode includes the openssl headers. At least I've 
never been able to find them. Plus perhaps their installed versions of 
libssl are outdated? That's what I've heard about their reasons for not 
including the header files.

-- 
John

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

the 1-click openssl install image for OSX is called Xcode, and one can go for a 
long lunch while waiting for it to finish, even on a fast network...

Apple should pick up the bill for these lunches, and much more, I fully agree.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Thierry]

Hi,

On Thu, Oct 19, 2017 at 08:07:19PM +0200, Luca De Feo wrote:
> |X| Yes, we should fully support OpenSSL now, and clarify the
> licensing issue.
> 
> > the way our
> > "package manager" works allows to install an optional package without
> > having to rely on openssl (no https), we only rely on the computation of
> > sha1
> 
> There you go for something crippled!  https://shattered.io/

sha256 is also supported by python-hashlib compiled without openssl
support, so we could/should easily move to using it in Sage "package
manager" (build/sage_bootstrap/tarball.py).

Ciao,
Thierry


> SHA1 has been deprecated by any reasonable browser nowaday.
> 
> Luca
> 
> -- 
> 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.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Luca De Feo]

|X| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.

> the way our
> "package manager" works allows to install an optional package without
> having to rely on openssl (no https), we only rely on the computation of
> sha1

There you go for something crippled!  https://shattered.io/

SHA1 has been deprecated by any reasonable browser nowaday.

Luca

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[William Stein]

On Thu, Oct 19, 2017 at 8:19 AM Emmanuel Charpentier <
emanuel.charpent...@gmail.com> wrote:

> Dear Erik
>
> Le jeudi 19 octobre 2017 09:19:00 UTC+2, Erik Bray a écrit :
>
>> On Wed, Oct 18, 2017 at 8:36 PM, Jeroen Demeyer 
>> wrote:
>> > On 2017-10-18 19:02, Emmanuel Charpentier wrote:
>> >>
>> >> This option commits us to maintain (unnecessary and dangerous, IMHO)
>> >> Sage-specifc SSL patches at least in R, Python and pip
>> >
>> >
>> > Really? Which Sage-specific SSL patches does this require in Python and
>> pip?
>> >
>> > It seems to me that R is the only package causing us so much trouble
>> with
>> > SSL.
>>
>> There *was* an issue in pip (not Python itself though that I can
>> recall--Python works fine without SSL support obviously).  However,
>> the pip issue has since been fixed upstream (pip can work without SSL
>> for installing packages from sources other than PyPI, there was just a
>> bug with imports failing if the ssl module was not importable).
>>
>> If R still requires such a patch I think we should get really pushy
>> with upstream about getting them to accept it.
>
>
> No : this policy decision is recent, and the "R Core Team" seems pretty
> adamant to switch to https repositories for all of CRAN. I seriously doubt
> that they would reverse this decision on the behalf of a bunch of
> mathematicians for whom R usage may be deemed as "peripheral"...
>

Good, as well they should.   Like you, they likely feel a responsibility to
their users to do the right thing regarding security.   I really appreciate
the "so much trouble" you are "causing" Emmanuel.

 -- William
-- 
-- William Stein

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 18 octobre 2017 20:36:47 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-18 19:02, Emmanuel Charpentier wrote: 
> > This option commits us to maintain (unnecessary and dangerous, IMHO) 
> > Sage-specifc SSL patches at least in R, Python and pip 
>
> Really? Which Sage-specific SSL patches does this require in Python and 
> pip? *
>

>From the Python license  
>page 
:

The modules hashlib 
, posix 
, ssl 
, crypt 
 use the 
OpenSSL library for added performance if made available by the operating 
system. Additionally, the Windows and Mac OS X installers for Python may 
include a copy of the OpenSSL libraries, so we include a copy of the 
OpenSSL license here: 


ISTR that last year update of Python (to which you contributed mightily) 
bumped on SSL issues. But my memories are foggy.

And, BTW, "our" pip is partially nonfunctional, thanks (among other) to SSL 
issues. So it *should* be patched.
 

> It seems to me that R is the only package causing us so much trouble 
> with SSL. 
>

No : **I** cause "so much trouble" with SSL issues because they become 
important to R real-world usage, and I do not think that a 
non-communicating R is useful in Sage.  Python/pip SSL usage do not cause 
"so much trouble" with SSL issues because the potential users of SSL 
functionalities are more patient than I am...

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Dear Erik

Le jeudi 19 octobre 2017 09:19:00 UTC+2, Erik Bray a écrit :
>
> On Wed, Oct 18, 2017 at 8:36 PM, Jeroen Demeyer  > wrote: 
> > On 2017-10-18 19:02, Emmanuel Charpentier wrote: 
> >> 
> >> This option commits us to maintain (unnecessary and dangerous, IMHO) 
> >> Sage-specifc SSL patches at least in R, Python and pip 
> > 
> > 
> > Really? Which Sage-specific SSL patches does this require in Python and 
> pip? 
> > 
> > It seems to me that R is the only package causing us so much trouble 
> with 
> > SSL. 
>
> There *was* an issue in pip (not Python itself though that I can 
> recall--Python works fine without SSL support obviously).  However, 
> the pip issue has since been fixed upstream (pip can work without SSL 
> for installing packages from sources other than PyPI, there was just a 
> bug with imports failing if the ssl module was not importable). 
>
> If R still requires such a patch I think we should get really pushy 
> with upstream about getting them to accept it.


No : this policy decision is recent, and the "R Core Team" seems pretty 
adamant to switch to https repositories for all of CRAN. I seriously doubt 
that they would reverse this decision on the behalf of a bunch of 
mathematicians for whom R usage may be deemed as "peripheral"...
 

> R should at least be 
> able to function without it, even if it means disabling package 
> downloads from CRAN which is fine. 
>

Again : R is not only a software package but also an ecosystem. The 11638 
(as of today) packages available to R users are a large part of R 
usefulness to its users. So, "disabling downloads from CRAN" is **NOT** 
fine (to them, at least...). 

And, BTW : which is your 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+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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

OK. Unless you correct me, I'll tally your vote as :
|X| No, we should wait until OpenSSL finishes fixing their license 
situation formally.

--
Emmanuel Charpentier

Le jeudi 19 octobre 2017 09:26:46 UTC+2, Ralf Stephan a écrit :
>
> After the previous comments I'd like to change my vote from Yes to
>
> |X| No 
>
> Regards,
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Dear Jeroen,

Unless you correct me, I'll tally your vote as 
|X| No, we should wait until OpenSSL finishes fixing their license 
situation formally.

--
Emmanuel Charpentier

Le mercredi 18 octobre 2017 11:10:38 UTC+2, Jeroen Demeyer a écrit :
>
> First of all, I think that your email is unfair because it presents the 
> "Yes" option as something that we could just easily do. However, as 
> mentioned in another post in this thread, the "Yes" option might 
> actually be illegal. 
>
> So my vote is "No". 
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Thu, Oct 19, 2017 at 3:49 PM, kcrisman  wrote:
>
>> > For what it is worth, I strongly agree with everything you write above.
>> > +1
>>
>> Also +1 with some quibbles about  section (agree with in
>> principle, but in tone or nuance).
>>
>
>  perhaps didn't they find the openssl one-click installer
> right in the middle of the screen yet.
>
> That sounds awesome, but I have no idea what you are talking about - can you
> point us to it/add to instructions?  This seems pretty reasonable to require
> users who want this on Mac ... unless I'm totally missing some weird joke.
> At any rate, my Mac doesn't have an "install ssl" button on its screen,
> though I wish it did.  Our binary dmgs don't have such a button, do they?

I have no idea. But also keep in mind that many users have no idea
what an "OpenSSL" is and aren't going to assume they need it if they
don't know what it is.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[kcrisman]

> > For what it is worth, I strongly agree with everything you write above. 
>  +1 
>
> Also +1 with some quibbles about  section (agree with in 
> principle, but in tone or nuance). 
>
>
 perhaps didn't they find the openssl one-click installer
right in the middle of the screen yet. 

That sounds awesome, but I have no idea what you are talking about - can 
you point us to it/add to instructions?  This seems pretty reasonable to 
require users who want this on Mac ... unless I'm totally missing some 
weird joke.  At any rate, my Mac doesn't have an "install ssl" button on 
its screen, though I wish it did.  Our binary dmgs don't have such a 
button, do they?

-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Ralf Stephan]

After the previous comments I'd like to change my vote from Yes to

|X| No 

Regards,

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Wed, Oct 18, 2017 at 8:36 PM, Jeroen Demeyer  wrote:
> On 2017-10-18 19:02, Emmanuel Charpentier wrote:
>>
>> This option commits us to maintain (unnecessary and dangerous, IMHO)
>> Sage-specifc SSL patches at least in R, Python and pip
>
>
> Really? Which Sage-specific SSL patches does this require in Python and pip?
>
> It seems to me that R is the only package causing us so much trouble with
> SSL.

There *was* an issue in pip (not Python itself though that I can
recall--Python works fine without SSL support obviously).  However,
the pip issue has since been fixed upstream (pip can work without SSL
for installing packages from sources other than PyPI, there was just a
bug with imports failing if the ssl module was not importable).

If R still requires such a patch I think we should get really pushy
with upstream about getting them to accept it.  R should at least be
able to function without it, even if it means disabling package
downloads from CRAN which is fine.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-18 19:02, Emmanuel Charpentier wrote:

This option commits us to maintain (unnecessary and dangerous, IMHO)
Sage-specifc SSL patches at least in R, Python and pip


Really? Which Sage-specific SSL patches does this require in Python and pip?

It seems to me that R is the only package causing us so much trouble 
with SSL.


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Wed, Oct 18, 2017 at 6:37 PM, William Stein  wrote:
>
> On Wed, Oct 18, 2017 at 9:23 AM Thierry 
> wrote:
>>
>> Hi,
>>
>> the dichotomy of the vote is not clear to me.
>>
>> I am -1 to make openssl a stantard package (hence shipped with the source
>> tarball), not only regarding licensing issues but also for security
>> reasons: our "package manager" is such that packages can not be updated
>> unless Sage itself is updated (because the package version is hardcoded).
>> Hence, when a security issue is found and fixed in openssl, the user who
>> installed it from Sage won't get it until the user upgrades Sage (while
>> every decent distro will provide a hotfix).
>>
>> However, i am +1 that we should do our best to let the user have an
>> openssl-enabled version of Sage (for pip, R, some cryptographic hash,...),
>> an acceptable workflow could be:
>>
>> - check if libssl-dev (or similar) is installed on the OS
>>   - yes:
>> - use it
>>   - no:
>> - strongly complain about it, provide documentation on how to do it
>>   (possibly provide a doc that depends on the system),
>> - propose 3 options:
>> - "i will install openssl from the distro, and come back later
>>   (recommended)"
>> - "i want Sage to install openssl optional package, i know that
>>   there will be security issues"
>> - "i do not want openssl support, i know that i will not be able
>>   to install any R or Python package from the web"
>>
>> If the last point (compiling Sage without openssl support) requires a lot
>> of work, i am OK to remove it (i am not sure if this is the point of the
>> vote).
>>
>> Note that that there is no chicken-and-eggs issue since the way our
>> "package manager" works allows to install an optional package without
>> having to rely on openssl (no https), we only rely on the computation of
>> sha1 which python-hashlib offers even if it is build without openssl
>> support.
>>
>> By the way, Sage is not GPL-3+ but GPL-2+.
>>
>> 
>>
>> Mac fans claim that paying a computer 1.5 the price of a random PC with
>> similar charateristics if justified by the fact that OSX is s
>> user-friendly, perhaps didn't they find the openssl one-click installer
>> right in the middle of the screen yet.
>>
>> Proposal: require Apple a grant, corresponding to the huge amount of time
>> Sage developpers waste in porting Sage components (not only openssl, just
>> have a look at trac, sage-devel and ask timelines) on their broken and
>> constantly changing OS. This is not our job to help Apple pretend their
>> system is user-friendly, we are losing a lot of energy which could be
>> spent in much more interesting parts of Sage (e.g. mathematics).
>>
>> 
>>
>> Ciao,
>> Thierry
>
>
> For what it is worth, I strongly agree with everything you write above.  +1

Also +1 with some quibbles about  section (agree with in
principle, but in tone or nuance).

But big +1 for the proposed implementation, including the strong and
informative warning messages :)


>> On Mon, Oct 16, 2017 at 03:08:51AM -0700, Emmanuel Charpentier wrote:
>> > [ The first post started too fast... Sorry for the interruption ! ]
>> >
>> > Following numerous discussions on this list and various Trac tickets*,
>> > the
>> > issue of maintaining Sage-specific patches to various components of Sage
>> > emerged again about the proposed upgrade
>> >  of R to 3.4.2 (discussed here
>> > ).
>> > William
>> > again raises
>> > 
>> > the
>> > issue of security.
>> >
>> > Since Trac#22189 , installation
>> > of
>> > a systemwide opennssl is recommended (may be too strongly
>> > , in the taste of some
>> > respectable
>> > Sage developers...). The ongoing relicensing of OpenSSL should lift the
>> > last barriers to its inclusion in sage. A discussed here
>> > ,, the
>> > probability of a legal problem related to the incusion of this library
>> > in
>> > Sage seems infinitesimal.
>> >
>> > It has beeen furthermore suggested
>> >  to
>> > add to our licensing (an adaptatin of) the following language, used in
>> > Gnu
>> > Wget License (GPL) :
>> >
>> > "Additional permission under GNU GPL version 3 section 7
>> >
>> > If you modify this program, or any covered work, by linking or combining
>> > it
>> > with the OpenSSL project's OpenSSL library (or a modified version of
>> > that
>> > library), containing parts covered by the terms of the OpenSSL or SSLeay
>> > licenses, the Free Software Foundation grants you additional permission
>> > to
>> > convey the resulting work. Corresponding Source for 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Dear Thierry,

Le mercredi 18 octobre 2017 18:23:53 UTC+2, Thierry (sage-googlesucks@xxx) 
a écrit :
>
> Hi, 
>
> the dichotomy of the vote is not clear to me. 
>
> I am -1 to make openssl a stantard package (hence shipped with the source 
> tarball), not only regarding licensing issues but also for security 
> reasons: our "package manager" is such that packages can not be updated 
> unless Sage itself is updated (because the package version is hardcoded). 
> Hence, when a security issue is found and fixed in openssl, the user who 
> installed it from Sage won't get it until the user upgrades Sage (while 
> every decent distro will provide a hotfix). 
>

That's a good and important point that I (among others) had overlooked. It 
could even preclude any "licensing issues" argument...

To be discussed post-vote, with other "implementation" issues ?
 

> However, i am +1 that we should do our best to let the user have an 
> openssl-enabled version of Sage (for pip, R, some cryptographic hash,...), 
> an acceptable workflow could be: 
>
> - check if libssl-dev (or similar) is installed on the OS 
>   - yes: 
> - use it 
>   - no: 
> - strongly complain about it, provide documentation on how to do it 
>   (possibly provide a doc that depends on the system), 
> - propose 3 options: 
> - "i will install openssl from the distro, and come back later 
>   (recommended)" 
>

This one is acceptable, and does not raise any pseudo-legalistic question.
 

> - "i want Sage to install openssl optional package, i know that 
>   there will be security issues" 
>

We should first upgrade our optional package top post-1.1.0 : the build 
system has changed *incompatibly !*

Furthermore, your (important) remark about our unability to "rush" 
security-related upgrades also apply here...
 

> - "i do not want openssl support, i know that i will not be able 
>   to install any R or Python package from the web" 
>

Yikes ! Aaaarghhh ! And all that sort of things...

This option commits us to maintain (unnecessary and dangerous, IMHO) 
Sage-specifc SSL patches at least in R, Python and pip, and this until the 
Last Judgement. Or OpenSSL relicensing (whichever comes first).

Do we have such an excess of workforce that we can allow to waste on this ?

Do we want to accept the responsibility of shipping a (voluntarily) 
crippled tool ? 

If the last point (compiling Sage without openssl support) requires a lot 
> of work, i am OK to remove it (i am not sure if this is the point of the 
> vote). 
>

I'd remove it in a cinch... 

Note that that there is no chicken-and-eggs issue since the way our 
> "package manager" works allows to install an optional package without 
> having to rely on openssl (no https), we only rely on the computation of 
> sha1 which python-hashlib offers even if it is build without openssl 
> support. 
>

Indeed, but that's a point we should fix. But that needs to be sure to have 
an https-enabled download tool ;-)...

By the way, Sage is not GPL-3+ but GPL-2+. 
>
>  
>
> Mac fans claim that paying a computer 1.5 the price of a random PC with 
> similar charateristics if justified by the fact that OSX is s 
> user-friendly, perhaps didn't they find the openssl one-click installer 
> right in the middle of the screen yet. 
>
> Proposal: require Apple a grant, corresponding to the huge amount of time 
> Sage developpers waste in porting Sage components (not only openssl, just 
> have a look at trac, sage-devel and ask timelines) on their broken and 
> constantly changing OS.


Seconded ! Now, *that's* a get-rich-fast scheme... 
 

> This is not our job to help Apple pretend their 
> system is user-friendly, we are losing a lot of energy which could be 
> spent in much more interesting parts of Sage (e.g. mathematics). 
>
>  
>
Ciao, 
>
Thierry 
>

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[William Stein]

On Wed, Oct 18, 2017 at 9:23 AM Thierry 
wrote:

> Hi,
>
> the dichotomy of the vote is not clear to me.
>
> I am -1 to make openssl a stantard package (hence shipped with the source
> tarball), not only regarding licensing issues but also for security
> reasons: our "package manager" is such that packages can not be updated
> unless Sage itself is updated (because the package version is hardcoded).
> Hence, when a security issue is found and fixed in openssl, the user who
> installed it from Sage won't get it until the user upgrades Sage (while
> every decent distro will provide a hotfix).
>
> However, i am +1 that we should do our best to let the user have an
> openssl-enabled version of Sage (for pip, R, some cryptographic hash,...),
> an acceptable workflow could be:
>
> - check if libssl-dev (or similar) is installed on the OS
>   - yes:
> - use it
>   - no:
> - strongly complain about it, provide documentation on how to do it
>   (possibly provide a doc that depends on the system),
> - propose 3 options:
> - "i will install openssl from the distro, and come back later
>   (recommended)"
> - "i want Sage to install openssl optional package, i know that
>   there will be security issues"
> - "i do not want openssl support, i know that i will not be able
>   to install any R or Python package from the web"
>
> If the last point (compiling Sage without openssl support) requires a lot
> of work, i am OK to remove it (i am not sure if this is the point of the
> vote).
>
> Note that that there is no chicken-and-eggs issue since the way our
> "package manager" works allows to install an optional package without
> having to rely on openssl (no https), we only rely on the computation of
> sha1 which python-hashlib offers even if it is build without openssl
> support.
>
> By the way, Sage is not GPL-3+ but GPL-2+.
>
> 
>
> Mac fans claim that paying a computer 1.5 the price of a random PC with
> similar charateristics if justified by the fact that OSX is s
> user-friendly, perhaps didn't they find the openssl one-click installer
> right in the middle of the screen yet.
>
> Proposal: require Apple a grant, corresponding to the huge amount of time
> Sage developpers waste in porting Sage components (not only openssl, just
> have a look at trac, sage-devel and ask timelines) on their broken and
> constantly changing OS. This is not our job to help Apple pretend their
> system is user-friendly, we are losing a lot of energy which could be
> spent in much more interesting parts of Sage (e.g. mathematics).
>
> 
>
> Ciao,
> Thierry


For what it is worth, I strongly agree with everything you write above.  +1

William


>
>
>
>
> On Mon, Oct 16, 2017 at 03:08:51AM -0700, Emmanuel Charpentier wrote:
> > [ The first post started too fast... Sorry for the interruption ! ]
> >
> > Following numerous discussions on this list and various Trac tickets*,
> the
> > issue of maintaining Sage-specific patches to various components of Sage
> > emerged again about the proposed upgrade
> >  of R to 3.4.2 (discussed here
> > ).
> William
> > again raises
> > 
> the
> > issue of security.
> >
> > Since Trac#22189 , installation
> of
> > a systemwide opennssl is recommended (may be too strongly
> > , in the taste of some
> respectable
> > Sage developers...). The ongoing relicensing of OpenSSL should lift the
> > last barriers to its inclusion in sage. A discussed here
> > ,, the
> > probability of a legal problem related to the incusion of this library in
> > Sage seems infinitesimal.
> >
> > It has beeen furthermore suggested
> >  to
> > add to our licensing (an adaptatin of) the following language, used in
> Gnu
> > Wget License (GPL) :
> >
> > "Additional permission under GNU GPL version 3 section 7
> >
> > If you modify this program, or any covered work, by linking or combining
> it
> > with the OpenSSL project's OpenSSL library (or a modified version of that
> > library), containing parts covered by the terms of the OpenSSL or SSLeay
> > licenses, the Free Software Foundation grants you additional permission
> to
> > convey the resulting work. Corresponding Source for a non-source form of
> > such a combination shall include the source code for the parts of OpenSSL
> > used as well as that of the covered work."
> >
> >
> > The proposed inclusion would entail :
> >
> >- Deprecation of our OpenSSL-avidance patches
> >- Standardization of SSL communications on OpenSSL
> >- At compilation, research of a systemwide OpenSSL
> >   - If found 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Thierry]

Hi,

the dichotomy of the vote is not clear to me.

I am -1 to make openssl a stantard package (hence shipped with the source
tarball), not only regarding licensing issues but also for security
reasons: our "package manager" is such that packages can not be updated
unless Sage itself is updated (because the package version is hardcoded).
Hence, when a security issue is found and fixed in openssl, the user who
installed it from Sage won't get it until the user upgrades Sage (while
every decent distro will provide a hotfix).

However, i am +1 that we should do our best to let the user have an
openssl-enabled version of Sage (for pip, R, some cryptographic hash,...),
an acceptable workflow could be:

- check if libssl-dev (or similar) is installed on the OS
  - yes:
- use it
  - no:
- strongly complain about it, provide documentation on how to do it
  (possibly provide a doc that depends on the system),
- propose 3 options:
- "i will install openssl from the distro, and come back later
  (recommended)"
- "i want Sage to install openssl optional package, i know that
  there will be security issues"
- "i do not want openssl support, i know that i will not be able
  to install any R or Python package from the web"

If the last point (compiling Sage without openssl support) requires a lot
of work, i am OK to remove it (i am not sure if this is the point of the
vote).

Note that that there is no chicken-and-eggs issue since the way our
"package manager" works allows to install an optional package without
having to rely on openssl (no https), we only rely on the computation of
sha1 which python-hashlib offers even if it is build without openssl
support.

By the way, Sage is not GPL-3+ but GPL-2+.



Mac fans claim that paying a computer 1.5 the price of a random PC with
similar charateristics if justified by the fact that OSX is s
user-friendly, perhaps didn't they find the openssl one-click installer
right in the middle of the screen yet.

Proposal: require Apple a grant, corresponding to the huge amount of time
Sage developpers waste in porting Sage components (not only openssl, just
have a look at trac, sage-devel and ask timelines) on their broken and
constantly changing OS. This is not our job to help Apple pretend their
system is user-friendly, we are losing a lot of energy which could be
spent in much more interesting parts of Sage (e.g. mathematics).



Ciao,
Thierry




On Mon, Oct 16, 2017 at 03:08:51AM -0700, Emmanuel Charpentier wrote:
> [ The first post started too fast... Sorry for the interruption ! ]
>
> Following numerous discussions on this list and various Trac tickets*, the
> issue of maintaining Sage-specific patches to various components of Sage
> emerged again about the proposed upgrade
>  of R to 3.4.2 (discussed here
> ). William
> again raises
>  the
> issue of security.
>
> Since Trac#22189 , installation of
> a systemwide opennssl is recommended (may be too strongly
> , in the taste of some respectable
> Sage developers...). The ongoing relicensing of OpenSSL should lift the
> last barriers to its inclusion in sage. A discussed here
> ,, the
> probability of a legal problem related to the incusion of this library in
> Sage seems infinitesimal.
>
> It has beeen furthermore suggested
>  to
> add to our licensing (an adaptatin of) the following language, used in Gnu
> Wget License (GPL) :
>
> "Additional permission under GNU GPL version 3 section 7
>
> If you modify this program, or any covered work, by linking or combining it
> with the OpenSSL project's OpenSSL library (or a modified version of that
> library), containing parts covered by the terms of the OpenSSL or SSLeay
> licenses, the Free Software Foundation grants you additional permission to
> convey the resulting work. Corresponding Source for a non-source form of
> such a combination shall include the source code for the parts of OpenSSL
> used as well as that of the covered work."
>
>
> The proposed inclusion would entail :
>
>- Deprecation of our OpenSSL-avidance patches
>- Standardization of SSL communications on OpenSSL
>- At compilation, research of a systemwide OpenSSL
>   - If found : do nothing
>   - In not found : installation of OpenSSL in the Sage tree from a
>   Sage-specific repository (as for most of our standard and optional
>   packages...).
>- Licensing clarification
>
> In short, we have two options : include OpenSSL now (using language
> clarification), or wait for the complete OpenSSL relicensing. The exact
> terms of the vote are 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 18 octobre 2017 15:37:13 UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) a écrit :
>
> On 18 October 2017 at 14:13, Erik Bray  
> wrote:
>
>> On Wed, Oct 18, 2017 at 11:52 AM, Dr. David Kirkby (Kirkby Microwave
>> Note: We're not talking about adding *any* OpenSSL code to SageMath.
>> Sage would never be distributed with code from OpenSSL.  We're only
>> talking about providing a means to download and install it from
>> source, and about shipping binaries that includes it.
>>
>>  
> How exactly do you intend shipping binaries that include the OpenSSL 
> library, while not including *any*  OpenSSL code? 
>

Simple : the same way that e. g. the Cygwin port ships code interacting 
with, say, Windows without *including* *any* Windows code... : by using 
published APIs to published libraries. We do not have to include OpenSSL 
*code* to use OpenSSL as long as OpenSSL is installed somewhere reachable 
by Sage.

The contentious point is : how do we ensure that OpenSSL *is* installed ? 
With most packages, we include it, by posting it on the Sage servers and 
fetching if necessary. This, in some eyes, is "including" code, since we 
post a copy on our servers.

To these (respectable) people, this is "legally" dubious (in which 
legislation(s), BTW ???), until the OpenSSL license changes. We need at 
least an interm solution.


   - Depending on a systemwide SSL is a possibility.
   - If we retain the option "Include now", other possibilities could be 
   discussed.

--
Emmanuel Charpentier

>
> Dave 
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 18 October 2017 at 14:13, Erik Bray  wrote:

> On Wed, Oct 18, 2017 at 11:52 AM, Dr. David Kirkby (Kirkby Microwave
> Note: We're not talking about adding *any* OpenSSL code to SageMath.
> Sage would never be distributed with code from OpenSSL.  We're only
> talking about providing a means to download and install it from
> source, and about shipping binaries that includes it.
>
>
How exactly do you intend shipping binaries that include the OpenSSL
library, while not including *any*  OpenSSL code?

Dave

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Wed, Oct 18, 2017 at 11:52 AM, Dr. David Kirkby (Kirkby Microwave
Ltd)  wrote:
> On 18 Oct 2017 00:39, "William Stein"  wrote:
>>
>>
>> On Tue, Oct 17, 2017 at 4:35 PM Dr. David Kirkby (Kirkby Microwave Ltd)
>>  wrote:
>
>>> There are a lot of number theorists using Sagemath. Could one or more
>>> consider implementing the functionality of OpenSSL in a re-write? Maybe a
>>> Google Summer of Code project?
>>
>>
>> Absolutely not.   That's not how security software works (and would be
>> insulting to the OpenSSL developers).   You are **epically** understimating
>> what OpenSSL is and does.
>
> I don't see how it is insulting to someone to say we like what you have
> done,  but need a different licence model, so will need to implement the
> algoithms ourselves.
>
> How is that materially different to Octave implementing MATLAB functionality
> but under an open source licence?
>
> I feel an unacceptable licence and/or a broken implementation on one
> platform (OSX) are both reasons for a rewrite.  It seems that there are both
> problems now.
>
> What in my opinion is insulting is to
>
> 1) Add the OpenSSL code to Sagemath, knowing full well it is against the
> licence. How anybody can justify such action is beyond me.

Note: We're not talking about adding *any* OpenSSL code to SageMath.
Sage would never be distributed with code from OpenSSL.  We're only
talking about providing a means to download and install it from
source, and about shipping binaries that includes it.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-18 01:38, William Stein wrote:

Absolutely not.   That's not how security software works (and would be
insulting to the OpenSSL developers).   You are **epically**
understimating what OpenSSL is and does.


+1

Implementing crypto in practice is very different from implementing a 
toy RSA function in Python.


Also: if re-implementing OpenSSl really would have been so easy, it 
would already have been done a long time ago.


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 18 octobre 2017 11:52:47 UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) a écrit :
>
> On 18 Oct 2017 00:39, "William Stein"  
> wrote:
> >
> >
> > On Tue, Oct 17, 2017 at 4:35 PM Dr. David Kirkby (Kirkby Microwave Ltd) <
> drki...@kirkbymicrowave.co.uk > wrote:
>
> >> There are a lot of number theorists using Sagemath. Could one or more 
> consider implementing the functionality of OpenSSL in a re-write? Maybe a 
> Google Summer of Code project? 
> >
> >
> > Absolutely not.   That's not how security software works (and would be 
> insulting to the OpenSSL developers).   You are **epically** understimating 
> what OpenSSL is and does.
>
> I don't see how it is insulting to someone to say we like what you have 
> done,  but need a different licence model, so will need to implement the 
> algoithms ourselves.
>
 
Implementing crypto algorithms is (relatively) easy.

Implementing crypto algorithms *correctly* (i. e. with no failure points) 
is *incredibly** *hard*. *The implementation needs not only implement the 
algorithm, it has to do so leaving no exploitable traces or exploitable 
backdoors. As you should know, proving the *absence* of such attack points 
is really *not* easy.

The recent history offers a *lot* of security issues attributable to faulty 
implementations of sound algorithms. The last one has been published just 
the day before yesterday (Google for "WPA KRACK" if you're not convinced...)

I don't know how to do that correctly. However, I know that I don't know
 

> How is that materially different to Octave implementing MATLAB 
> functionality but under an open source licence?
>

Try it for yourself ;-).
 

> I feel an unacceptable licence and/or a broken implementation on one 
> platform (OSX) are both reasons for a rewrite.  It seems that there are 
> both problems now.  
>
> What in my opinion is insulting is to
>
> 1) Add the OpenSSL code to Sagemath, knowing full well it is against the 
> licence.
>

Whose license ? The problem is not with OpenSSL licenses (yes, there are 
two of them...) but with the GPL. Terms that we may amend at will. A 
suggestion (written and tested by the authors of another Gnu package) has 
been made, which some find faulty. They are welcome to propose better 
terms...
 

> How anybody can justify such action is beyond me.
>

See above.
 

>  
>
> 2) Email people and say that you assume that they agree unless they say 
> they object.
>

That's (alas...) common practice, in much more general ways that software 
licensing. You should try to explain to your tax collector that you didn't 
consent to pay taxes...

At least, that's not shrink-wrap license...

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 18 Oct 2017 00:39, "William Stein"  wrote:
>
>
> On Tue, Oct 17, 2017 at 4:35 PM Dr. David Kirkby (Kirkby Microwave Ltd) <
drkir...@kirkbymicrowave.co.uk> wrote:

>> There are a lot of number theorists using Sagemath. Could one or more
consider implementing the functionality of OpenSSL in a re-write? Maybe a
Google Summer of Code project?
>
>
> Absolutely not.   That's not how security software works (and would be
insulting to the OpenSSL developers).   You are **epically** understimating
what OpenSSL is and does.

I don't see how it is insulting to someone to say we like what you have
done,  but need a different licence model, so will need to implement the
algoithms ourselves.

How is that materially different to Octave implementing MATLAB
functionality but under an open source licence?

I feel an unacceptable licence and/or a broken implementation on one
platform (OSX) are both reasons for a rewrite.  It seems that there are
both problems now.

What in my opinion is insulting is to

1) Add the OpenSSL code to Sagemath, knowing full well it is against the
licence. How anybody can justify such action is beyond me.

2) Email people and say that you assume that they agree unless they say
they object.

Dave

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Maarten Derickx]

On Wednesday, 18 October 2017 03:35:15 UTC+2, Michael Orlitzky wrote:
>
> On 10/17/2017 08:42 PM, Maarten Derickx wrote: 
> > 
> > What makes you think their process is dubious? They are reaching out for 
> > consent from all people who have contributed, and they have removed the 
> > code from the several people who have objected on record. 
> > 
>
> The mail that they sent to contributors ended with, 
>
>   If we do not hear from you, we will assume that you have no objection. 
>
> That's not the way it works, but if they've changed their approach, I'll 
> be happy to be wrong in this case. 
>

Hmmm that line in the e-mail is very different from what is suggested by 
their public announcements, like for 
example 
https://www.coreinfrastructure.org/news/announcements/2017/03/openssl-re-licensing-apache-license-v-20-encourage-broader-use-other-foss
 
. To quote from that section:

“This re-licensing activity will make OpenSSL, already the world's most 
widely-used FOSS encryption software, more convenient to incorporate in the 
widest possible range of free and open source software," said Mishi 
Choudhary, Legal Director of Software Freedom Law Center (SFLC) and counsel 
to OpenSSL. “OpenSSL's team has carefully prepared for this re-licensing, 
and their process will be an outstanding example of 'how to do it right.’

This gives me the confidence that they will not take a dubious unlawful 
approach, even though I find the wording in the e-mail dubious as well. 

To all the people reading this and caring about the OpenSSL license change: 
please visit https://license.openssl.org/cgi-bin/authors.py . Here you can 
see a list of contributors who have not yet responded to the license change 
request, and helping with getting OpenSSL to reach them will surely help 
with the license change. 

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 18 octobre 2017 10:58:28 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-18 03:08, William Stein wrote: 
> >   (a) using a broken version of the Python/R/Sage stack that exposes 
> > them to installing malware 
>
> Is that really the case? I think pip is actually fail-safe in the sense 
> that it simply refuses to download if OpenSSL is not supported. So there 
> is no exposure to malware here. 
>
> Does anybody know how this works for R? 
>

1) There are *currently* http-accessible R repositories. The question is 
"for how long whal these repositories be mantained and curated ?". 

2) The same is true of Bioconductor, R-forge and Omegahat repositories.

3) I have no extensive knowledge of the 11626 (as of today) available R 
packages in the CRAN repository aind its mirrors. However, I would be 
deeply surprised if none of them offered or neeeded access to https-only 
resources, such as distributed databases.

4) There are also a $#i+load of non-CRAN repositories offering 
not-yet-published packages. Similarly, a number of published works (papers, 
books, etc...) offer access to non-CRAN repositories of data and 
complementary analyses. There is no guarantee that these resources are 
http-accessible.

To be unable to *programatically* access these resources from R is 
(another) pain in the @$$.

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 18 octobre 2017 10:58:28 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-18 03:08, William Stein wrote: 
> >   (a) using a broken version of the Python/R/Sage stack that exposes 
> > them to installing malware 
>
> Is that really the case? I think pip is actually fail-safe in the sense 
> that it simply refuses to download if OpenSSL is not supported.


And *that's* an excruciating pain in the @$$...
 

> So there 
> is no exposure to malware here. 
>

In other words, you're protecting the target system the same way Origen 
 (supposedly)  tried to protect 
himself from temptation.

--
Emmanuel Charpentier

>
> Does anybody know how this works for R? 
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

I think the elaboration part of the "Yes" option was not very carefully 
worded, this is what Michael pointed out.
We cannot HOST OpenSSL source (this is illegal with its present license),
but nothing prevents us from providing means to install it legally.

To be on a safe side with binary distribution of Sage, one might like to 
add the
exception clause to the license, as I suggested.


On Wednesday, October 18, 2017 at 10:10:38 AM UTC+1, Jeroen Demeyer wrote:
>
> First of all, I think that your email is unfair because it presents the 
> "Yes" option as something that we could just easily do. However, as 
> mentioned in another post in this thread, the "Yes" option might 
> actually be illegal. 
>
> So my vote is "No". 
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le mercredi 18 octobre 2017 10:51:21 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-18 03:08, William Stein wrote: 
> > The choice for users installing the Sage binary is between: 
>
> So you are worried about *binaries*? Are there any distros that we ship 
> binaries for that *don't* have a systemwide OpenSSL installed by default? 
>

Cygwin ?

And, as far as I know, there is no way for a Cygwin binary to *reliably* 
depend on another Cygwin package...

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

First of all, I think that your email is unfair because it presents the 
"Yes" option as something that we could just easily do. However, as 
mentioned in another post in this thread, the "Yes" option might 
actually be illegal.


So my vote is "No".

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

On Wednesday, October 18, 2017 at 9:51:21 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2017-10-18 03:08, William Stein wrote: 
> > The choice for users installing the Sage binary is between: 
>
> So you are worried about *binaries*? Are there any distros that we ship 
> binaries for that *don't* have a systemwide OpenSSL installed by default? 
>

there used to be the case with OSX that their systemwide OpenSSL was 
outdated. This is however no
longer then case, at least on OSX 10.12. There still could be some 
headaches with absence of proper certificates
installed on OSX (something fixable, I guess, but I'm not sure how), at 
least with my very limited understanding of the situation there.


 

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-18 03:08, William Stein wrote:

  (a) using a broken version of the Python/R/Sage stack that exposes
them to installing malware


Is that really the case? I think pip is actually fail-safe in the sense 
that it simply refuses to download if OpenSSL is not supported. So there 
is no exposure to malware here.


Does anybody know how this works for R?

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-18 03:08, William Stein wrote:

The choice for users installing the Sage binary is between:


So you are worried about *binaries*? Are there any distros that we ship 
binaries for that *don't* have a systemwide OpenSSL installed by default?


--
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Ralf Stephan]

First, to voice my opinion:
 [X] Require OpenSSL to be installed on the system. 
I really think that the Mac folks should resolve this and not require Sage 
to make awkward choices.

As to the vote:
|X| Yes, we should fully support OpenSSL now, and clarify the licensing 
issue.

Regards,

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[William Stein]

On Tue, Oct 17, 2017 at 6:41 PM Michael Orlitzky 
wrote:

> On 10/17/2017 09:37 PM, William Stein wrote:
> >
> > The mail that they sent to contributors ended with,
> >
> >   If we do not hear from you, we will assume that you have no
> objection.
> >
> > That's not the way it works,
> >
> >
> > Says who?   This is all about how things work legally, and the rules
> > there are not so simple.
> >
>
> If I email Disney with "I'm going to download Lilo and Stitch, and if
> you don't reply by the end of the week, I'm going to assume you're cool
> with it" -- that's totally legit and legally binding?


I am not a lawyer.  And that is not the same thing l, except maybe to a
mathematician.



>
> --
> 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.
>
-- 
-- William Stein

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Michael Orlitzky]

On 10/17/2017 09:37 PM, William Stein wrote:
> 
> The mail that they sent to contributors ended with,
> 
>   If we do not hear from you, we will assume that you have no objection.
> 
> That's not the way it works, 
> 
> 
> Says who?   This is all about how things work legally, and the rules
> there are not so simple.
> 

If I email Disney with "I'm going to download Lilo and Stitch, and if
you don't reply by the end of the week, I'm going to assume you're cool
with it" -- that's totally legit and legally binding?

-- 
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.