Discussion:
VOTE: inclusion of OpenSSL in Sage
(too old to reply)
Emmanuel Charpentier
2017-10-16 09:47:09 UTC
Permalink
Following numerous discussions on this list an various tickets, the issue
of maintaining Sage-specific patches to various components of Sage emerged
again about the proposed upgrade <https://trac.sagemath.org/ticket/24026>
of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>).

Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation of
a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, in the taste of some respectable
Sage developers...).

The proposed inclusion would entail :
Deprecation of our OpenSSL-avidance patches
Sta
At compilation, research of a systemwide OpenSSL
If found : do nothing
--
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.
Emmanuel Charpentier
2017-10-16 10:08:51 UTC
Permalink
[ 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
<https://trac.sagemath.org/ticket/24026> of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>). William
again raises
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/WQ5FPmsiAQAJ> the
issue of security.

Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation of
a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, 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
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>,, the
probability of a legal problem related to the incusion of this library in
Sage seems infinitesimal.

It has beeen furthermore suggested
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ> 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 therefore :

|_| 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
--
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.
Erik Bray
2017-10-16 14:58:03 UTC
Permalink
On Mon, Oct 16, 2017 at 12:08 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
In short, we have two options : include OpenSSL now (using language
clarification), or wait for the complete OpenSSL relicensing. The exact
|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.
Yes, but it's terrible in the first place that we have to include
OpenSSL "in Sage" at all. As long as the system library is used by
default though then I don't mind.
--
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.
Dima Pasechnik
2017-10-16 15:22:16 UTC
Permalink
On Monday, October 16, 2017 at 11:08:52 AM UTC+1, Emmanuel Charpentier
Post by Emmanuel Charpentier
[ 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
<https://trac.sagemath.org/ticket/24026> of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>).
William again raises
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/WQ5FPmsiAQAJ> the
issue of security.
Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation
of a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, 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
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>,, the
probability of a legal problem related to the incusion of this library in
Sage seems infinitesimal.
It has beeen furthermore suggested
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ> to
add to our licensing (an adaptatin of) the following language, used in Gnu
"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."
- 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
|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.
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
--
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.
William Stein
2017-10-16 15:24:31 UTC
Permalink
|X| Yes, we should fully support OpenSSL now, and clarify the licensing
issue.
Post by Dima Pasechnik
On Monday, October 16, 2017 at 11:08:52 AM UTC+1, Emmanuel Charpentier
Post by Emmanuel Charpentier
[ 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
<https://trac.sagemath.org/ticket/24026> of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>).
William again raises
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/WQ5FPmsiAQAJ>
the issue of security.
Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation
of a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, 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
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>,, the
probability of a legal problem related to the incusion of this library in
Sage seems infinitesimal.
It has beeen furthermore suggested
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ> to
add to our licensing (an adaptatin of) the following language, used in Gnu
"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."
- 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
|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.
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
--
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
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+***@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.
John Cremona
2017-10-16 16:06:06 UTC
Permalink
|X| Yes, we should fully support OpenSSL now, and clarify the licensing
issue.
--
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.
David Roe
2017-10-16 17:08:01 UTC
Permalink
|X| Yes, we should fully support OpenSSL now, and clarify the licensing
issue.
--
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.
Jeroen Demeyer
2017-10-16 18:07:56 UTC
Permalink
Post by Emmanuel Charpentier
|_| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
What does "clarifying" the licensing issue even mean? The fact that
OpenSSL is *in the process of* relicensing does not help us at the
moment. And you don't need a mailing list vote to change the Sage
license: you need approval from every author of every GPL package in 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+***@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.
William Stein
2017-10-16 19:44:43 UTC
Permalink
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
|_| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
What does "clarifying" the licensing issue even mean? The fact that
OpenSSL is *in the process of* relicensing does not help us at the
moment. And you don't need a mailing list vote to change the Sage
license: you need approval from every author of every GPL package in Sage.
To me, "clarify the license situations means":

1. At a mimum: make it crytstal clear in our LICENSE/README file and
binaries download page that we are distribution OpenSSL (or at least
something that depends on OpenSSL), and that -- depending on
interpretations of the system license exception -- this may violate the
GPL. I think making this situation *clear* is absolutely essential, rather
than say just "sneaking" openssl into Sage.

2. Also: explain that the risk is minimal, since it is the intention of the
OpenSSL authors to relicense, and several of us significant copyright
holders (e.g., me) can at least make a clear statement that **WE** are not
going to complain or sue anybody for combining Sage with OpenSSL.

Until OpenSSL is properly relicensed there is a small but real risk of some
problem arising from this copyright situation. That has to be balanced
with the very real risk that shipping a crippled security stack directly
results in users of Sage having their computers and personal information
compromised.

A legally safer approach would be to never include openssl in sage, but
instead make a system-wide install of openssl a hard requirement for
building or installing sage. We then still link to openssl. The build
fails if it libopenssl-dev (or whatever) is not available. A binary
install doesn't work (in some cases?) if it isn't available. Maybe this
should be a third option for the vote? It seems like what Eric wanted...

William
Post by Jeroen Demeyer
--
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
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+***@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.
Jeroen Demeyer
2017-10-17 06:55:22 UTC
Permalink
So basically you want to add OpenSSL to Sage and then say

"We know that distributing SageMath might be illegal, but it is unlikely
that somebody will sue. Use at your own risk!"

I doubt that this is such a good deal.
--
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.
Michael Orlitzky
2017-10-17 19:49:41 UTC
Permalink
Post by Jeroen Demeyer
So basically you want to add OpenSSL to Sage and then say
"We know that distributing SageMath might be illegal, but it is unlikely
that somebody will sue. Use at your own risk!"
I doubt that this is such a good deal.
Not to mention that the addition of terms under Section 7 of GPLv3
amounts to a license change ("shall be treated as though they were
included in this License"), and possibly requires the consent of all
SageMath contributors.

Which, by the way, is why OpenSSL has not actually relicensed. Some of
the contributors said "no," and that's the last I heard about it.

Throwing my vote away:

[X] Require OpenSSL to be installed on the system.
--
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.
Emmanuel Charpentier
2017-10-17 19:56:20 UTC
Permalink
Dear Michael,
Post by Michael Orlitzky
Post by Jeroen Demeyer
So basically you want to add OpenSSL to Sage and then say
"We know that distributing SageMath might be illegal, but it is unlikely
that somebody will sue. Use at your own risk!"
I doubt that this is such a good deal.
Not to mention that the addition of terms under Section 7 of GPLv3
amounts to a license change ("shall be treated as though they were
included in this License"), and possibly requires the consent of all
SageMath contributors.
Which, by the way, is why OpenSSL has not actually relicensed. Some of
the contributors said "no," and that's the last I heard about it.
[X] Require OpenSSL to be installed on the system.
That's not one of the proposed options. But it seems to imply that we
should wait for OpenSSL relicensing. If that's what you think should
happen, could you explicitly vote in that direction ?
--
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.
Michael Orlitzky
2017-10-17 20:46:46 UTC
Permalink
Post by Michael Orlitzky
[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" =)
Post by Michael Orlitzky
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.

"Include it anyway" is a bad option because we've just announced to the
world that we're going to commit (willful) copyright infringement.
--
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.
Maarten Derickx
2017-10-18 00:42:25 UTC
Permalink
Post by Michael Orlitzky
Post by Michael Orlitzky
[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" =)
Post by Michael Orlitzky
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.
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.

"Include it anyway" is a bad option because we've just announced to the
Post by Michael Orlitzky
world that we're going to commit (willful) copyright infringement.
--
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.
Michael Orlitzky
2017-10-18 01:35:10 UTC
Permalink
Post by Maarten Derickx
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.
William Stein
2017-10-18 01:37:46 UTC
Permalink
Post by Michael Orlitzky
Post by Maarten Derickx
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,
Says who? This is all about how things work legally, and the rules there
are not so simple.

but if they've changed their approach, I'll
Post by Michael Orlitzky
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
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+***@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.
Michael Orlitzky
2017-10-18 01:41:07 UTC
Permalink
Post by Michael Orlitzky
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+***@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.
William Stein
2017-10-18 01:42:40 UTC
Permalink
Post by Michael Orlitzky
Post by Michael Orlitzky
The mail that they sent to contributors ended with,
If we do not hear from you, we will assume that you have no
objection.
Post by Michael Orlitzky
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.
Post by Michael Orlitzky
--
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
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+***@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.
Maarten Derickx
2017-10-18 09:47:09 UTC
Permalink
Post by Michael Orlitzky
Post by Maarten Derickx
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+***@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.
William Stein
2017-10-18 01:08:56 UTC
Permalink
Post by Jeroen Demeyer
So basically you want to add OpenSSL to Sage and then say
"We know that distributing SageMath might be illegal, but it is unlikely
that somebody will sue. Use at your own risk!"
I doubt that this is such a good deal.
The choice for users installing the Sage binary is between:

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

(b) using a more robust version of the Python/R/Sage stack, but with the
risk that somebodywho owns the copyright of some GPL'd part of the Sage
distribution sues the distributor of Sage for violating their GPL license.

A copyright holder that might have a valid complaint would not be OpenSSL,
since it's not the OpenSSL license that is violated; it's the GPL that is
violated.

Honestly, it's never even been clear to me that the GPL is definitely
violated here, since OpenSSL only binary links with Python, and Python is
not GPL'd. The meaning of derived work for software that is combined only
at runtime via an interpreter environment is still unclear to me (e.g., see
recent inclusion of ZFS in Ubuntu).

The organizations doing the distribution of the Sage binaries would
probably be taking the biggest risk here.

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+***@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.
Jeroen Demeyer
2017-10-18 08:51:16 UTC
Permalink
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+***@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.
Dima Pasechnik
2017-10-18 09:05:16 UTC
Permalink
Post by Jeroen Demeyer
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+***@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.
Emmanuel Charpentier
2017-10-18 09:17:17 UTC
Permalink
Post by Jeroen Demeyer
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+***@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.
Jeroen Demeyer
2017-10-18 08:58:24 UTC
Permalink
Post by William Stein
(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+***@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.
Emmanuel Charpentier
2017-10-18 09:22:53 UTC
Permalink
Post by Jeroen Demeyer
Post by William Stein
(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.
In other words, you're protecting the target system the same way Origen
<https://en.wikipedia.org/wiki/Origen> (supposedly) tried to protect
himself from temptation.

--
Emmanuel Charpentier
Post by Jeroen Demeyer
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+***@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.
Emmanuel Charpentier
2017-10-18 09:40:12 UTC
Permalink
Post by Jeroen Demeyer
Post by William Stein
(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+***@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.
Emmanuel Charpentier
2017-10-17 13:34:20 UTC
Permalink
We may combine these approaches by, sequentially,

1. Depend on a systemwide OpenSSL :
1. update README, the Installation Guide and possibly the Developer's
Guide ;
2. test for OpenSSL in the configure script, failing if not installed
;
3. (possibly) fail early at Sage startup if the runtime isn't found
(necessary for binary installations, such as Erik's Cygwin 64 port, that
can't reliably depend on other packages. Binary packages such as Debian's
or Ubuntu's may depend on the relevant runtime library packages) ;
4. find and remove OpenSSL-specific patches.
2. (After OpenSSL relicensing) include OpenSSL :
1. update README, Installation guide and Developer's guide again ;
2. test for OpenSSL in the configure script, installing it in the
Sage tree if necessary.

That could be discussed after the vote if its result is in favor of
immediate inclusion. In the other case, 1.4+2. is a possible approach.

Further discussion should probably wait for the vote's result...

HTH,

--
Emmanuel Charpentier
Post by William Stein
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
|_| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
What does "clarifying" the licensing issue even mean? The fact that
OpenSSL is *in the process of* relicensing does not help us at the
moment. And you don't need a mailing list vote to change the Sage
license: you need approval from every author of every GPL package in Sage.
1. At a mimum: make it crytstal clear in our LICENSE/README file and
binaries download page that we are distribution OpenSSL (or at least
something that depends on OpenSSL), and that -- depending on
interpretations of the system license exception -- this may violate the
GPL. I think making this situation *clear* is absolutely essential, rather
than say just "sneaking" openssl into Sage.
2. Also: explain that the risk is minimal, since it is the intention of
the OpenSSL authors to relicense, and several of us significant copyright
holders (e.g., me) can at least make a clear statement that **WE** are not
going to complain or sue anybody for combining Sage with OpenSSL.
Until OpenSSL is properly relicensed there is a small but real risk of
some problem arising from this copyright situation. That has to be
balanced with the very real risk that shipping a crippled security stack
directly results in users of Sage having their computers and personal
information compromised.
A legally safer approach would be to never include openssl in sage, but
instead make a system-wide install of openssl a hard requirement for
building or installing sage. We then still link to openssl. The build
fails if it libopenssl-dev (or whatever) is not available. A binary
install doesn't work (in some cases?) if it isn't available. Maybe this
should be a third option for the vote? It seems like what Eric wanted...
William
Post by Jeroen Demeyer
--
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
<javascript:>.
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+***@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.
Dima Pasechnik
2017-10-16 22:40:31 UTC
Permalink
by clarification I meant this: https://groups.google.com/forum/m/#!msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ
--
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.
Nathan Dunfield
2017-10-17 04:31:02 UTC
Permalink
|X| Yes, we should fully support OpenSSL now, and clarify the licensing
issue.
--
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.
David Joyner
2017-10-17 11:21:28 UTC
Permalink
On Mon, Oct 16, 2017 at 6:08 AM, Emmanuel Charpentier
Post by Emmanuel Charpentier
[ 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)
"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."
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
|_| Yes, we should fully support OpenSSL now, and clarify the licensing
issue.
|_| No, we should wait until OpenSSL finishes fixing their license situation
formally.
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?

According to https://www.openssl.org/community/contacts.html the email
for licensing issues is ***@opensslfoundation.org, but they have a
developers' email list at
https://www.openssl.org/community/mailinglists.html.
Post by Emmanuel Charpentier
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
--
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
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.
Emmanuel Charpentier
2017-10-17 13:09:47 UTC
Permalink
Le mardi 17 octobre 2017 13:21:52 UTC+2, David Joyner a écrit :

[ Snip... ]
Post by David Joyner
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?
Not yet, as far as I know. That would be an interesting first step in
implementation of the inclusion if the current vote ends up in favor of
immediate inclusion. In the other case, the point would be moot, since MPL
*is* compatible with GPL...

According to https://www.openssl.org/community/contacts.html the email
Post by David Joyner
they have a
developers' email list at
https://www.openssl.org/community/mailinglists.html.
Post by Emmanuel Charpentier
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
--
You received this message because you are subscribed to the Google
Groups
Post by Emmanuel Charpentier
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an
<javascript:>.
Post by Emmanuel Charpentier
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.
Ralf Stephan
2017-10-18 05:31:38 UTC
Permalink
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+***@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.
Ralf Stephan
2017-10-19 07:26:46 UTC
Permalink
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+***@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.
Emmanuel Charpentier
2017-10-19 14:58:35 UTC
Permalink
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
Post by 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+***@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.
Jeroen Demeyer
2017-10-18 09:10:35 UTC
Permalink
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+***@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.
Dima Pasechnik
2017-10-18 09:20:45 UTC
Permalink
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.
Post by 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+***@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.
Emmanuel Charpentier
2017-10-19 14:58:27 UTC
Permalink
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
Post by 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+***@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.
Thierry
2017-10-18 16:23:46 UTC
Permalink
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
Post by Emmanuel Charpentier
[ 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
<https://trac.sagemath.org/ticket/24026> of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>). William
again raises
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/WQ5FPmsiAQAJ> the
issue of security.
Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation of
a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, 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
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>,, the
probability of a legal problem related to the incusion of this library in
Sage seems infinitesimal.
It has beeen furthermore suggested
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ> to
add to our licensing (an adaptatin of) the following language, used in Gnu
"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."
- 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
|_| 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
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
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.
William Stein
2017-10-18 16:37:37 UTC
Permalink
Post by 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,...),
- check if libssl-dev (or similar) is installed on the OS
- use it
- strongly complain about it, provide documentation on how to do it
(possibly provide a doc that depends on the system),
- "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

William
Post by Thierry
Post by Emmanuel Charpentier
[ The first post started too fast... Sorry for the interruption ! ]
Following numerous discussions on this list and various Trac tickets*,
the
Post by Emmanuel Charpentier
issue of maintaining Sage-specific patches to various components of Sage
emerged again about the proposed upgrade
<https://trac.sagemath.org/ticket/24026> of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>).
William
Post by Emmanuel Charpentier
again raises
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/WQ5FPmsiAQAJ>
the
Post by Emmanuel Charpentier
issue of security.
Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation
of
Post by Emmanuel Charpentier
a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, in the taste of some
respectable
Post by Emmanuel Charpentier
Sage developers...). The ongoing relicensing of OpenSSL should lift the
last barriers to its inclusion in sage. A discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>,, the
probability of a legal problem related to the incusion of this library in
Sage seems infinitesimal.
It has beeen furthermore suggested
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ> to
add to our licensing (an adaptatin of) the following language, used in
Gnu
Post by Emmanuel Charpentier
"Additional permission under GNU GPL version 3 section 7
If you modify this program, or any covered work, by linking or combining
it
Post by Emmanuel Charpentier
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
Post by Emmanuel Charpentier
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."
- 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
|_| 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
--
You received this message because you are subscribed to the Google
Groups "sage-devel" group.
Post by Emmanuel Charpentier
To unsubscribe from this group and stop receiving emails from it, send
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
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+***@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.
Erik Bray
2017-10-18 17:26:07 UTC
Permalink
Post by William Stein
Post by 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,...),
- check if libssl-dev (or similar) is installed on the OS
- use it
- strongly complain about it, provide documentation on how to do it
(possibly provide a doc that depends on the system),
- "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).

But big +1 for the proposed implementation, including the strong and
informative warning messages :)
Post by William Stein
Post by Thierry
Post by Emmanuel Charpentier
[ 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
<https://trac.sagemath.org/ticket/24026> of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>). William
again raises
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/WQ5FPmsiAQAJ> the
issue of security.
Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation of
a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, 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
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>,, the
probability of a legal problem related to the incusion of this library in
Sage seems infinitesimal.
It has beeen furthermore suggested
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ> to
add to our licensing (an adaptatin of) the following language, used in Gnu
"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."
- 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
|_| 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
--
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
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
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
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.
kcrisman
2017-10-19 13:49:17 UTC
Permalink
Post by Erik Bray
Post by William Stein
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).
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+***@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.
Erik Bray
2017-10-19 14:30:29 UTC
Permalink
Post by Thierry
Post by Erik Bray
Post by William Stein
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).
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+***@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.
Dima Pasechnik
2017-10-19 21:17:09 UTC
Permalink
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+***@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.
John H Palmieri
2017-10-19 22:29:45 UTC
Permalink
Post by 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.
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+***@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.
kcrisman
2017-10-20 18:20:17 UTC
Permalink
Post by Dima Pasechnik
Post by 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...
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).
Post by Dima Pasechnik
Apple should pick up the bill for these lunches, and much more, I fully
Post by Dima Pasechnik
agree.
True.
Post by Dima Pasechnik
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+***@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.
Dima Pasechnik
2017-10-20 18:25:18 UTC
Permalink
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)
Post by kcrisman
Post by Dima Pasechnik
Post by 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...
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).
Post by Dima Pasechnik
Apple should pick up the bill for these lunches, and much more, I fully
Post by Dima Pasechnik
agree.
True.
Post by Dima Pasechnik
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+***@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.
Emmanuel Charpentier
2017-10-18 17:02:43 UTC
Permalink
Dear Thierry,
Post by 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).
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 ?
Post by Thierry
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,...),
- check if libssl-dev (or similar) is installed on the OS
- use it
- strongly complain about it, provide documentation on how to do it
(possibly provide a doc that depends on the system),
- "i will install openssl from the distro, and come back later
(recommended)"
This one is acceptable, and does not raise any pseudo-legalistic question.
Post by Thierry
- "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...
Post by Thierry
- "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
Post by Thierry
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
Post by Thierry
"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+.
Post by Thierry
<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.
Seconded ! Now, *that's* a get-rich-fast scheme...
Post by Thierry
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
--
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+***@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.
Jeroen Demeyer
2017-10-18 18:36:43 UTC
Permalink
Post by Emmanuel Charpentier
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+***@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.
Erik Bray
2017-10-19 07:18:56 UTC
Permalink
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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+***@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.
Emmanuel Charpentier
2017-10-19 15:19:45 UTC
Permalink
Dear Erik
Post by Erik Bray
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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?
Post by Jeroen Demeyer
It seems to me that R is the only package causing us so much trouble
with
Post by Jeroen Demeyer
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"...
Post by Erik Bray
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+***@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.
William Stein
2017-10-19 15:24:06 UTC
Permalink
On Thu, Oct 19, 2017 at 8:19 AM Emmanuel Charpentier <
Post by Emmanuel Charpentier
Dear Erik
Post by Erik Bray
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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?
Post by Jeroen Demeyer
It seems to me that R is the only package causing us so much trouble
with
Post by Jeroen Demeyer
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+***@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.
Jeroen Demeyer
2017-10-20 08:49:37 UTC
Permalink
Post by William Stein
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+***@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.
Emmanuel Charpentier
2017-10-21 18:37:57 UTC
Permalink
Post by Jeroen Demeyer
Post by William Stein
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+***@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.
Jeroen Demeyer
2017-10-20 08:51:15 UTC
Permalink
Post by Emmanuel Charpentier
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+***@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.
Dima Pasechnik
2017-10-20 08:54:39 UTC
Permalink
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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+***@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.
Jeroen Demeyer
2017-10-20 09:13:32 UTC
Permalink
Post by Dima Pasechnik
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+***@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.
Dima Pasechnik
2017-10-20 10:04:13 UTC
Permalink
Post by Jeroen Demeyer
Post by Dima Pasechnik
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
Post by Jeroen Demeyer
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+***@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.
Emmanuel Charpentier
2017-10-21 18:45:19 UTC
Permalink
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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...
Post by Jeroen Demeyer
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+***@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.
Erik Bray
2017-10-23 09:15:59 UTC
Permalink
On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
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.
Post by Emmanuel Charpentier
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+***@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.
Emmanuel Charpentier
2017-10-23 09:57:18 UTC
Permalink
Dear Erik,
Post by Erik Bray
On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Again : R is not only a software package but also an ecosystem. The
11638
Post by Emmanuel Charpentier
(as of today) packages available to R users are a large part of R
usefulness
Post by Emmanuel Charpentier
to its users. So, "disabling downloads from CRAN" is *NOT* fine (to
them, at
Post by Emmanuel Charpentier
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 ;-)...
Post by Erik Bray
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+***@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.
Erik Bray
2017-10-23 10:17:01 UTC
Permalink
On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Dear Erik,
Post by Erik Bray
On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
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
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+***@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.
Emmanuel Charpentier
2017-10-23 10:27:53 UTC
Permalink
Post by Erik Bray
On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Dear Erik,
Post by Erik Bray
On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
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
Post by Emmanuel Charpentier
straightforward as the automatic download-and-install default method).
But
Post by Emmanuel Charpentier
There are a large number of CRAN packages (11660 as of this morning).
More
Post by Emmanuel Charpentier
and more of these packages have mutual dependencies, which are easily
accounted for bu install.packages() but are a pain to deal with
"manually".
Post by Emmanuel Charpentier
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
Post by Emmanuel Charpentier
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.
Post by Emmanuel Charpentier
My prediction (or prognostication, or oracle, if you wish...;-) is that
they
Post by Emmanuel Charpentier
will reach the level of complexity of operating system distributions in
an
Post by Emmanuel Charpentier
amount of time short enough for this problem to be of interest to all
but
Post by Emmanuel Charpentier
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+***@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.
Erik Bray
2017-10-23 12:31:59 UTC
Permalink
On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
Post by Erik Bray
On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Dear Erik,
Post by Erik Bray
On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
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
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 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?

I think we're nearly in agreement, except maybe about the extent to
which SSL support should be mandated in all cases.

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+***@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.
Erik Bray
2017-10-23 12:43:13 UTC
Permalink
Post by Erik Bray
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+***@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.
Emmanuel Charpentier
2017-10-23 13:28:11 UTC
Permalink
Post by Erik Bray
Post by Erik Bray
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.
Post by Erik Bray
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+***@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.
Erik Bray
2017-10-23 13:44:03 UTC
Permalink
On Mon, Oct 23, 2017 at 3:28 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Post by Erik Bray
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+***@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.
Emmanuel Charpentier
2017-10-23 13:19:51 UTC
Permalink
Post by Erik Bray
On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
Post by Erik Bray
On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Dear Erik,
Post by Erik Bray
On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Again : R is not only a software package but also an ecosystem.
The
Post by Erik Bray
Post by Emmanuel Charpentier
Post by Erik Bray
Post by Emmanuel Charpentier
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
Post by Erik Bray
Post by Emmanuel Charpentier
Post by Erik Bray
Post by Emmanuel Charpentier
them, at
least...).
I'm not saying it shouldn't be possible to install R packages at
all,
Post by Erik Bray
Post by Emmanuel Charpentier
Post by Erik Bray
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
Post by Erik Bray
Post by Emmanuel Charpentier
Post by Erik Bray
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
Post by Erik Bray
Post by Emmanuel Charpentier
Post by Erik Bray
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
Post by Erik Bray
Post by Emmanuel Charpentier
as
straightforward as the automatic download-and-install default
method).
Post by Erik Bray
Post by Emmanuel Charpentier
But
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
Post by Erik Bray
Post by Emmanuel Charpentier
your operating system : it *is* indeed possible to maintain a
Unix/Linux
Post by Erik Bray
Post by Emmanuel Charpentier
installation using only tarballs conveyed to the system via
sneakersnet,
Post by Erik Bray
Post by Emmanuel Charpentier
but
it' certainly a) not fun and b) chronophage to the extreme...
As it happened with Linux distributions, these intermutual
dependencies,
Post by Erik Bray
Post by Emmanuel Charpentier
which started scarce and lightweight, are getting more and more important.
My prediction (or prognostication, or oracle, if you wish...;-) is
that
Post by Erik Bray
Post by Emmanuel Charpentier
they
will reach the level of complexity of operating system distributions
in
Post by Erik Bray
Post by Emmanuel Charpentier
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 I see the problem here. We're talking about multiple
Post by Erik Bray
issues simultaneously and some things are getting confused--some
streams crossed.
Indeed : SSL is a *general* tool, and its absence affects *many* things.
Post by Erik Bray
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.
Okay : we have another confusion here : you want to *run* pip (or R)
without SSL support. The problem (at least with R) is that we shouldn't be
able to *build* R without SSL support.

Therefore pip should be able to work (and does)
Post by Erik Bray
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),
It isn't : I've spent CPU *days* (two or three upgrades ago, can't exactly
rember when) to prove that neither GnuTLS nor Netscape's library allow to
compile an unmodified upstream R. You are, of course, welcome to check.
Post by Erik Bray
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
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.
I think that this is where we disagree : I tend to follow upstream's
authors : see below.
Post by Erik Bray
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.
See above for the source of this assertion. The R Core Team (roughly the
author of upstream R) has decided that R *must* support https-enabled
downloads. It has taken steps to ensure that such support *is* available at
compile time. Therefore, we have to patch "our" R to lift this enforcement.
Post by Erik Bray
I would
consider that an upstream deficiency that should be addressed
aggressively just in principle if nothing else.
Again, you are welcome to try to change R Core Team's mind. I doubt you can
manage it : they seem to think that http mirrors are too insecure to be
trusted, and decided to enforce https *ability* in recent versions of R.
They probably won't be impressed by a couple of mathematicians with
pseudo-legal licensing issues.

And, BTW, R is GPL-licensed <https://www.r-project.org/Licenses/>... Stop
brandishing that strawman. Thank you.

b) If we agree that it should not be possible to build Sage
Post by Erik Bray
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.
Indeed...
Post by Erik Bray
But there is the separate
issue of having this added dependency that may be inconvenient for
some people.
The same problem applies the the same people wanting to use upstream's R.
Post by Erik Bray
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.
Agreed. Fully.

I'd like to add that the "average user" of R seems to be be much more prone
to install external packages than the "average user" of Sage : CRAN is a
very large part of the "R ecosystem".

From a larger point of view : for an applied statistician, as judged by
their respective presences in scholarly publications, R is the dominant
platform for code supporting the papers, with Matlab being a (distant)
second ; Python has yet to make a marked dent ; SAS, which was dominant
about 20 years ago, seems to slide in oblivion.

So, maintaining compatibility with the R-and--CRAN ecosystem is important.

Being a (very) casual user of Python, I am not aware of the nature and
importance of the Python ecosystem. But I'd be surprised if it pip-oriented
repositories didn't become as important to "the Python users community" as
CRAN is to the "R users community...
Post by Erik Bray
This requirement is
independent of how SSL support is achieved, what that means for
developers or maintainers of binary packages, etc.
Indeed. You're welcome to try and find an unencubered SSL library that is
swallowed by upstream's R as acceptable for https support, and to propose
the patches necessary to its use to the R Core Team. I didn't succeed, but,
hey, I'm just a dentist that tries to *use* R...

Does that help at all?
Yes.
Post by Erik Bray
I think we're nearly in agreement, except maybe about the extent to
which SSL support should be mandated in all cases.
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+***@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.
Erik Bray
2017-10-23 13:39:21 UTC
Permalink
On Mon, Oct 23, 2017 at 3:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Post by Erik Bray
On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
Post by Erik Bray
On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
Post by Emmanuel Charpentier
Dear Erik,
Post by Erik Bray
On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
Post by Emmanuel Charpentier
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
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 ?
*sigh* I feel like I've been over this but pip works without PyPI and
this is *by design*.
Post by Emmanuel Charpentier
Post by Erik Bray
Okay. I think I see the problem here. We're talking about multiple
issues simultaneously and some things are getting confused--some
streams crossed.
Indeed : SSL is a *general* tool, and its absence affects *many* things.
Post by Erik Bray
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.
Okay : we have another confusion here : you want to *run* pip (or R)
without SSL support. The problem (at least with R) is that we shouldn't be
able to *build* R without SSL support.
Yes, we should be able to. We can't currently (without patch), but we
should be able to.
Post by Emmanuel Charpentier
Post by Erik Bray
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),
It isn't : I've spent CPU *days* (two or three upgrades ago, can't exactly
rember when) to prove that neither GnuTLS nor Netscape's library allow to
compile an unmodified upstream R. You are, of course, welcome to check.
I don't mean a different SSL library. I mean without *any*.
Post by Emmanuel Charpentier
Post by Erik Bray
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
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.
I think that this is where we disagree : I tend to follow upstream's authors
: see below.
I don't know. Do we really disagree? Or are you just agreeing with
the upstream authors?
Post by Emmanuel Charpentier
Post by Erik Bray
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.
See above for the source of this assertion. The R Core Team (roughly the
author of upstream R) has decided that R *must* support https-enabled
downloads. It has taken steps to ensure that such support *is* available at
compile time. Therefore, we have to patch "our" R to lift this enforcement.
This is wrong. R works without *any* kind of download capability
whatsoever. This includes installing R packages (which I agree is
important functionality). But that doesn't mean R has to be able to
download them. It's not like starting up R is going to fail if it
can't download anything (if that were the case you could never use it
offline). And indeed it isn't the case. They're simply refusing to
modularize their functionality for some reason.
Post by Emmanuel Charpentier
Post by Erik Bray
I would
consider that an upstream deficiency that should be addressed
aggressively just in principle if nothing else.
Again, you are welcome to try to change R Core Team's mind. I doubt you can
manage it : they seem to think that http mirrors are too insecure to be
trusted, and decided to enforce https *ability* in recent versions of R.
They probably won't be impressed by a couple of mathematicians with
pseudo-legal licensing issues.
They are welcome to require HTTPS for CRAN and any other public
mirrors. I would insist on it too. But that doesn't mean there's no
good reason for plain HTTP networks (e.g. on a closed network). Or,
as I feel like I've said repeatedly and am perhaps still unclear about
somehow: It's not necessary for it to have *any* kind of download
capability much less with/without SSL.
Post by Emmanuel Charpentier
And, BTW, R is GPL-licensed... Stop brandishing that strawman. Thank you.
I'm not sure what strawman you're referring to here but it's probably
not one I've used. I don't personally care about licensing issues at
all even if I probably should :)
Post by Emmanuel Charpentier
Post by Erik Bray
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.
Indeed...
Post by Erik Bray
But there is the separate
issue of having this added dependency that may be inconvenient for
some people.
The same problem applies the the same people wanting to use upstream's R.
It's not a problem if they're installing from binaries, which most
are? Same for Sage.
Post by Emmanuel Charpentier
Post by Erik Bray
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.
Agreed. Fully.
I'd like to add that the "average user" of R seems to be be much more prone
to install external packages than the "average user" of Sage : CRAN is a
very large part of the "R ecosystem".
Agreed, but this still goes back to my first point which is the
"average user" is also not everyone, and there are legitimate reasons
to not care about the R library itself handling package downloads
(regardless of how that affects Sage).
Post by Emmanuel Charpentier
From a larger point of view : for an applied statistician, as judged by
their respective presences in scholarly publications, R is the dominant
platform for code supporting the papers, with Matlab being a (distant)
second ; Python has yet to make a marked dent ; SAS, which was dominant
about 20 years ago, seems to slide in oblivion.
So, maintaining compatibility with the R-and--CRAN ecosystem is important.
This is all well understood as to the need for this functionality in a
normal install of R, but it's still irrelevant to the general point
that it's not essential functionality merely for building and
installing R in all cases.
Post by Emmanuel Charpentier
Being a (very) casual user of Python, I am not aware of the nature and
importance of the Python ecosystem. But I'd be surprised if it pip-oriented
repositories didn't become as important to "the Python users community" as
CRAN is to the "R users community...
They are and were before "pip" even came along. I used to manage an
internal PyPI instance, for example, for proprietary Python packages.
This is irrelevant though.
Post by Emmanuel Charpentier
Post by Erik Bray
This requirement is
independent of how SSL support is achieved, what that means for
developers or maintainers of binary packages, etc.
Indeed. You're welcome to try and find an unencubered SSL library that is
swallowed by upstream's R as acceptable for https support, and to propose
the patches necessary to its use to the R Core Team. I didn't succeed, but,
hey, I'm just a dentist that tries to *use* R...
I don't care about that, and am not sure how I indicated that I am.
I'm also not sure who accused you of being a "dentist" (also I know
some very smart dentists...); I'm sorry if you feel on the defensive
here because again I think we're almost entirely in agreement. I want
what you want, for the same reasons, just from a
different...perspective? I'm not sure what the disconnect is here
except that you and the R developers seem to believe that it should
be literally impossible to even build their software unless it has
even the *capability* of connecting to CRAN, even though that's not
necessary for any of its core functionality. This is very strange to
me, even if we can all agree that CRAN is important to its ecosystem
and typical user-base.

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+***@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.
Emmanuel Charpentier
2017-10-19 15:21:11 UTC
Permalink
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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 <https://docs.python.org/2.7/license.html#openssl> page
:

The modules hashlib
<https://docs.python.org/2.7/library/hashlib.html#module-hashlib>, posix
<https://docs.python.org/2.7/library/posix.html#module-posix>, ssl
<https://docs.python.org/2.7/library/ssl.html#module-ssl>, crypt
<https://docs.python.org/2.7/library/crypt.html#module-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.
Post by Jeroen Demeyer
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+***@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.
Erik Bray
2017-10-23 09:19:09 UTC
Permalink
On Thu, Oct 19, 2017 at 5:21 PM, Emmanuel Charpentier
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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? *
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
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.
Post by Jeroen Demeyer
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+***@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.
Jeroen Demeyer
2017-10-23 09:24:14 UTC
Permalink
Post by Emmanuel Charpentier
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+***@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.
Erik Bray
2017-10-23 09:28:53 UTC
Permalink
Post by Emmanuel Charpentier
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+***@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.
Erik Bray
2017-10-23 09:39:25 UTC
Permalink
Post by Erik Bray
Post by Emmanuel Charpentier
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&version=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+***@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.
Emmanuel Charpentier
2017-10-23 10:19:47 UTC
Permalink
Dear Jeroen
Post by Jeroen Demeyer
Post by Emmanuel Charpentier
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
<https://groups.google.com/forum/#!topic/sage-devel/B5gV0_MBiAc>. 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+***@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.
Luca De Feo
2017-10-19 18:07:19 UTC
Permalink
|X| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
Post by Thierry
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+***@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.
Thierry
2017-10-19 20:56:17 UTC
Permalink
Hi,
Post by Emmanuel Charpentier
|X| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
Post by Thierry
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
Post by Emmanuel Charpentier
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.
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.
Erik Bray
2017-10-23 09:21:30 UTC
Permalink
On Thu, Oct 19, 2017 at 10:56 PM, Thierry
Post by Thierry
Hi,
Post by Emmanuel Charpentier
|X| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
Post by Thierry
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+***@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.
Jeroen Demeyer
2017-10-20 08:58:29 UTC
Permalink
Post by 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.
--
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.
Luca De Feo
2017-10-20 09:32:12 UTC
Permalink
Post by 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+***@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.
Jeroen Demeyer
2017-10-20 09:44:37 UTC
Permalink
Post by Luca De Feo
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+***@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.
Luca De Feo
2017-10-20 11:25:49 UTC
Permalink
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+***@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.
Emmanuel Charpentier
2017-10-21 18:53:58 UTC
Permalink
Post by Jeroen Demeyer
Post by 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.
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+***@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.
Erik Bray
2017-10-23 09:23:41 UTC
Permalink
Post by 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.
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+***@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.
Maarten Derickx
2017-10-20 14:54:09 UTC
Permalink
On Wednesday, 18 October 2017 18:23:53 UTC+2, Thierry
Post by 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,...),
- check if libssl-dev (or similar) is installed on the OS
- use it
- strongly complain about it, provide documentation on how to do it
(possibly provide a doc that depends on the system),
- "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.
Post by Thierry
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
Post by Emmanuel Charpentier
[ The first post started too fast... Sorry for the interruption ! ]
Following numerous discussions on this list and various Trac tickets*,
the
Post by Emmanuel Charpentier
issue of maintaining Sage-specific patches to various components of Sage
emerged again about the proposed upgrade
<https://trac.sagemath.org/ticket/24026> of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>).
William
Post by Emmanuel Charpentier
again raises
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/WQ5FPmsiAQAJ>
the
Post by Emmanuel Charpentier
issue of security.
Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation
of
Post by Emmanuel Charpentier
a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, in the taste of some
respectable
Post by Emmanuel Charpentier
Sage developers...). The ongoing relicensing of OpenSSL should lift the
last barriers to its inclusion in sage. A discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>,, the
probability of a legal problem related to the incusion of this library
in
Post by Emmanuel Charpentier
Sage seems infinitesimal.
It has beeen furthermore suggested
<https://groups.google.com/d/msg/sage-devel/rhMrNK_2c24/GYHzsSd6BAAJ>
to
Post by Emmanuel Charpentier
add to our licensing (an adaptatin of) the following language, used in
Gnu
Post by Emmanuel Charpentier
"Additional permission under GNU GPL version 3 section 7
If you modify this program, or any covered work, by linking or combining
it
Post by Emmanuel Charpentier
with the OpenSSL project's OpenSSL library (or a modified version of
that
Post by Emmanuel Charpentier
library), containing parts covered by the terms of the OpenSSL or SSLeay
licenses, the Free Software Foundation grants you additional permission
to
Post by Emmanuel Charpentier
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
Post by Emmanuel Charpentier
used as well as that of the covered work."
- 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
|_| 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
--
You received this message because you are subscribed to the Google
Groups "sage-devel" group.
Post by Emmanuel Charpentier
To unsubscribe from this group and stop receiving emails from it, send
<javascript:>.
Post by Emmanuel Charpentier
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.
Eric Gourgoulhon
2017-10-21 16:02:32 UTC
Permalink
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+***@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.
David Joyner
2017-10-21 18:53:14 UTC
Permalink
On Sat, Oct 21, 2017 at 12:02 PM, Eric Gourgoulhon
Post by 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.
- check if libssl-dev (or similar) is installed on the OS
- use it
- strongly complain about it, provide documentation on how to do it
(possibly provide a doc that depends on the system),
- "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.
Post by Eric Gourgoulhon
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
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.
Richard_L
2017-10-17 19:59:05 UTC
Permalink
[X] Require OpenSSL to be installed on the system.
This sidesteps the whole license issue and, since more bugs are sure to be
found, we do not have to keep yet another package up to date.
--
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.
Nicolas M. Thiery
2017-10-17 21:52:41 UTC
Permalink
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.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <***@users.sf.net>
http://Nicolas.Thiery.name/
--
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.
Dima Pasechnik
2017-10-17 22:56:02 UTC
Permalink
Post by Nicolas M. Thiery
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.
Yeah, this brings up the story about OpenSSL on OSX again, as what's
provided by the system still a looks bit broken, it seems.

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.

A couple of years ago that was, however, impossible on OSX, more or less,
as their openssl implementation
was old and lacking features.
Now it appears that they updated openssl to a pretty new version 1.1.0c.
See https://github.com/hashdist/hashdist/issues/352#issuecomment-337392725

There are some weird messages about certificates missing, but this could be
my broken setup, or perhaps
it's something trivial to fix by installing a free certificate bundle.
Could someone knowledgeable about these things comment?

Dima
Post by Nicolas M. Thiery
Cheers,
Nicolas
--
http://Nicolas.Thiery.name/
--
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.
Dr. David Kirkby (Kirkby Microwave Ltd)
2017-10-17 23:35:47 UTC
Permalink
Post by Dima Pasechnik
The problem is that we cannot, as rightfully pointed here by Michael,
provide a tarball with OpenSSL source, as this
Post by Dima Pasechnik
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.
William Stein
2017-10-17 23:38:51 UTC
Permalink
On Tue, Oct 17, 2017 at 4:35 PM Dr. David Kirkby (Kirkby Microwave Ltd) <
Post by Dima Pasechnik
On Tuesday, October 17, 2017 at 10:52:47 PM UTC+1, Nicolas M. Thiéry
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?
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.
Post by Dima Pasechnik
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
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+***@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.
Dr. David Kirkby (Kirkby Microwave Ltd)
2017-10-18 09:52:41 UTC
Permalink
Post by William Stein
On Tue, Oct 17, 2017 at 4:35 PM Dr. David Kirkby (Kirkby Microwave Ltd) <
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
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?
Post by William Stein
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+***@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.
Emmanuel Charpentier
2017-10-18 10:12:58 UTC
Permalink
Le mercredi 18 octobre 2017 11:52:47 UTC+2, Dr. David Kirkby (Kirkby
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
Post by William Stein
On Tue, Oct 17, 2017 at 4:35 PM Dr. David Kirkby (Kirkby Microwave Ltd) <
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
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?
Post by William Stein
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....
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
How is that materially different to Octave implementing MATLAB
functionality but under an open source licence?
Try it for yourself ;-).
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
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...
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
How anybody can justify such action is beyond me.
See above.
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
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+***@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.
Erik Bray
2017-10-18 13:13:37 UTC
Permalink
On Wed, Oct 18, 2017 at 11:52 AM, Dr. David Kirkby (Kirkby Microwave
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
Post by William Stein
On Tue, Oct 17, 2017 at 4:35 PM Dr. David Kirkby (Kirkby Microwave Ltd)
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
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+***@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.
Dr. David Kirkby (Kirkby Microwave Ltd)
2017-10-18 13:37:08 UTC
Permalink
Post by Erik Bray
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+***@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.
Emmanuel Charpentier
2017-10-18 14:57:08 UTC
Permalink
Le mercredi 18 octobre 2017 15:37:13 UTC+2, Dr. David Kirkby (Kirkby
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
Post by Erik Bray
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
Post by Dr. David Kirkby (Kirkby Microwave Ltd)
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.
Jeroen Demeyer
2017-10-18 10:51:47 UTC
Permalink
Post by William Stein
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+***@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.
Maarten Derickx
2017-10-18 01:02:18 UTC
Permalink
|x| Yes, we should fully support OpenSSL now, and clarify the licensing
issue.

Where I want to add that my support is conditional on that this can be done
in a legal way.
Post by Emmanuel Charpentier
Following numerous discussions on this list an various tickets, the issue
of maintaining Sage-specific patches to various components of Sage emerged
again about the proposed upgrade <https://trac.sagemath.org/ticket/24026>
of R to 3.4.2 (discussed here
<https://groups.google.com/forum/#!topic/sage-devel/rhMrNK_2c24>).
Since Trac#22189 <https://trac.sagemath.org/ticket/22189>, installation
of a systemwide opennssl is recommended (may be too strongly
<https://trac.sagemath.org/ticket/22620>, in the taste of some
respectable Sage developers...).
Deprecation of our OpenSSL-avidance patches
Sta
At compilation, research of a systemwide OpenSSL
If found : do nothing
--
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.
Emmanuel Charpentier
2017-10-23 13:40:46 UTC
Permalink
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+***@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.
'Julien Puydt' via sage-devel
2017-10-23 13:49:55 UTC
Permalink
Post by Emmanuel Charpentier
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+***@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.
Loading...