"Additional permission under GNU GPL version 3 section 7If 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."
|_| Yes, we should fully support OpenSSL now, and clarify the licensing issue.|_| No, we should wait until OpenSSL finishes fixing their license situation formally.
[ 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 7If 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 therefore :
|X| Yes, we should fully support OpenSSL now, and clarify the licensing issue.
|_| No, we should wait until OpenSSL finishes fixing their license situation formally.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Has anyone emailed them and just tell them the plan is for SageMath
in November 2017 to include OpenSSL and include a license clarification
of some type, and ask the OpenSSL people for their reaction?
I have no strong opinion on whether to make OpenSSL a hard requirement
or providing it if it's not there. But *not* having OpenSSL is a
recurrent pain (e.g. for pip installing package) and it would be
really helpful to be able to rely on it.
If we make it a hard requirement, how to install OpenSSL on the
classical systems should be well documented. I spent too many hours
helping people on mac/... that were missing it.
On 17 Oct 2017 23:56, "Dima Pasechnik" <dim...@gmail.com> wrote:
>
> On Tuesday, October 17, 2017 at 10:52:47 PM UTC+1, Nicolas M. Thiéry wrote:
>>
>>
> The problem is that we cannot, as rightfully pointed here by Michael, provide a tarball with OpenSSL source, as this
> would be an outright copyright violation. Thus we ought to rely on the system libraries.
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?
If a subset of the SSL developers are happy to have the code they wrote GPL, then there would be no need to rewrite those bits, if those individuals would relicense the bits they personally wrote. That would mean a rewrite of the bit written by by developers who will not relicense what they wrote.
Dave.
On 17 Oct 2017 23:56, "Dima Pasechnik" <dim...@gmail.com> wrote:
>
> On Tuesday, October 17, 2017 at 10:52:47 PM UTC+1, Nicolas M. Thiéry wrote:
>>
>>> The problem is that we cannot, as rightfully pointed here by Michael, provide a tarball with OpenSSL source, as this
> would be an outright copyright violation. Thus we ought to rely on the system libraries.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?
If a subset of the SSL developers are happy to have the code they wrote GPL, then there would be no need to rewrite those bits, if those individuals would relicense the bits they personally wrote. That would mean a rewrite of the bit written by by developers who will not relicense what they wrote.
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
On 10/17/2017 03:56 PM, Emmanuel Charpentier wrote:
>
> Throwing my vote away:
>
> [X] Require OpenSSL to be installed on the system.
>
>
> That's not one of the proposed options.
That's what I meant by "throwing my vote away" =)
> But it seems to imply that we should wait for OpenSSL relicensing.
We don't have to wait if we require it to be installed on the system.
"Wait for OpenSSL to relicense" is a bad option because they will
probably never relicense -- even if they ultimately change their LICENSE
file, the process by which they've done it is extremely dubious, and
several copyright holders are on record withholding permission to do so.
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.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
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.
On 18 Oct 2017 00:39, "William Stein" <wst...@gmail.com> 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.
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
On 18 Oct 2017 00:39, "William Stein" <wst...@gmail.com> 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.
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.
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.
Dave
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+.
<troll>
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 soooo
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).
</troll>
Ciao,
Thierry
> For what it is worth, I strongly agree with everything you write above. +1
Also +1 with some quibbles about <troll> section (agree with in
principle, but in tone or nuance).
On Wed, Oct 18, 2017 at 8:36 PM, Jeroen Demeyer <jdem...@cage.ugent.be> 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.
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.
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 <jdem...@cage.ugent.be> 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"...
Apple should pick up the bill for these lunches, and much more, I fully agree.
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.
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.
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+.
<troll>
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 soooo
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).
</troll>
Ciao,
Thierry
> |_| Yes, we should fully support OpenSSL now, and clarify the licensing
> issue.
>
> |_| No, we should wait until OpenSSL finishes fixing their license
> situation formally.
>
> The vote will take place as answers to this post, and will be open until
> Monday October 23, 14h UTC.
>
> Sincerely yours,
>
>
> Emmanuel Charpentier
>
> * Perusing the results of searching Trac and sage-devel Google group is
> enlightening...
> --
> Emmanuel Charpentier
>
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.
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?
> And, BTW : which is your vote ?
My vote now is for a re-vote :)
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 not in
any way require SSL to work. There was a time when it did, but only
due to a bug where some module assumed the `ssl` module would always
be importable which is not necessarily the case. There are completely
legitimate reasons to either *explicitly* run pip without SSL support,
and there are completely legitimate reasons to simply not need it at
all or not care.
Therefore pip should be able to work (and does)
without SSL support, without patching. The same should be true for R,
and if this is not the case (and I'm not convinced it isn't),
then it
should be for the same or similar reasons as pip. Again, this is
purely from an abstract standpoint in how that software should,
ideally, be designed.
Second: The question is, should it be possible to build/install Sage
(specifically the distribution) without an SSL library? There are two
sub-problems that arise from this question:
a) If we agree that that should at least be *possible* (I think it
should be, even if not the default) to build Sage without SSL, then
all of Sage's dependencies should be able to build without SSL.
This
includes pip and R. If these packages satisfy the first issue then
there is no problem; nothing to discuss. But your assertion is that R
can't even be built without SSL support unless it is patched.
I would
consider that an upstream deficiency that should be addressed
aggressively just in principle if nothing else.
b) If we agree that it should not be possible to build Sage
without SSL support (which I think is a poor decision, due to the
first point) then there is no issue about needing to maintain a patch
to remove SSL requirement from any package.
But there is the separate
issue of having this added dependency that may be inconvenient for
some people.
Third: There's a question of who the audience is. For the "casual"
user who does not care about building things or compiling things or
licenses or patches and just wants to run Sage, and be able to install
packages from pip and CRAN (should the need even arise) this should
all Just Work. From that point of view, they should be installing
Sage from pre-built binaries, and those binaries should include the
necessary SSL support, period, end of story.
This requirement is
independent of how SSL support is achieved, what that means for
developers or maintainers of binary packages, etc.
Does that help at all?
On Mon, Oct 23, 2017 at 2:31 PM, Erik Bray <erik....@gmail.com> 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.