Re: [sage-devel] Re: Graphs: Hamiltonian path vs. cycle

[Jori Mäntysalo]

On Wed, 18 Oct 2017, David Coudert wrote:

But anyways, I found more. is_eulerian(path=True) will return either 
False OR an Eulerian path. This seems to be clearly wrong.


It is not a correct behavior. This method should have a parameter 
`certificate`, default to False. When certificate is True, it returns a 
pair boolean and certificate (see e.g., is_tree).


Sounds reasonable. But then what to do to eulerian_circuit()? There could 
be a function to count or list eulerian circuits too (a problem in #P, 
says Wikipedia).


What's more, is_eulerian(path=True) returns True when the graph has an 
Eulerian path BUT has not Eulerian cycle. Is this normal use in graph 
theory?


This is not consistent with the definition: “a graph has an Eulerian 
path if and only if exactly zero or two vertices have odd degree".


True. But it is useful function to have shorcut for 
"g.has_eulerian_path() and not g.has_eulerian_circuit()"?


 * * *

I think we have a clear consensus on two things: 1) is_* -function shall 
return either a Boolean or a pair where first element is a Boolean, and as 
I said before, 2) function related to Hamiltonian path/cycle shall be 
similar to those related to Eulerian path/cycle.


--
Jori Mäntysalo

[sage-devel] Re: Using C++ library from Sage

[Eric Gourgoulhon]

Thank you all for your answers. This is very helpful.

Eric.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Using C++ library from Sage

[Volker Braun]

There is src/sage/tests/stl_vector.pyx to demo/test c++ & cython (which is 
what I would recommend).



On Wednesday, October 18, 2017 at 4:31:16 PM UTC+2, Eric Gourgoulhon wrote:
>
> Hi Sage Devs,
>
> We plan to develop some experimental package for Sage, which requires to 
> make use of a C++ library (basically this is to implement numerical 
> calculus on manifolds). What would you recommend to make the link between 
> Sage (Python) code and that library? 
> - Cython ? 
> - Boost ?  
> - ???
> Any example of an existing C++ / Sage interaction would also be 
> appreciated. 
>
> Best regards,
>
> Eric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Live documentation with Thebe reloaded

[Jeroen Demeyer]

On 2017-10-18 18:21, Nicolas M. Thiery wrote:

 Dear Sage developers,

You can find a demo of live documentation on:

 https://more-sagemath-tutorials.readthedocs.io/

Pick e.g. "Demo basics", click "Activate", and wait a bit. To evaluate
a cell, use shift-Enter as in Jupyter.


Doesn't work for me (Firefox 45 on Linux). I see the Activate button and 
the code examples change but nothing becomes interactive.



In principle, any Sage package (by which I mean a Python package using
Sage)


Why should this be Sage-specific? Wouldn't it work with any notebook 
that can be run on mybinder?


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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

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


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

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


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Graphs: Hamiltonian path vs. cycle

[David Coudert]

> But anyways, I found more. is_eulerian(path=True) will return either False OR 
> an Eulerian path. This seems to be clearly wrong.

It is not a correct behavior. This method should have a parameter 
`certificate`, default to False. When certificate is True, it returns a pair 
boolean and certificate (see e.g., is_tree).

> What's more, is_eulerian(path=True) returns True when the graph has an 
> Eulerian path BUT has not Eulerian cycle. Is this normal use in graph theory?

This is not consistent with the definition: “a graph has an Eulerian path if 
and only if exactly zero or two vertices have odd degree".  So if the graph has 
a hamiltonian cycle it also has a hamiltonian path.

David.

> -- 
> Jori Mäntysalo







-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: What does MPolynomial_libsingular.reduce() do?

[Simon King]

Hi Luca,

On 2017-10-18, Luca De Feo  wrote:
> However, what's the use of such a function with
> implementation-dependent outputs?
>
> If I understand Martin's argument correctly, he is saying that
> .reduce() *could* be used for a schoolbook "implementation of Gröbner
> basis algorithms in Sage which call reduce, i.e. polynomial division
> with remainders, on S-polynomials wrt to the current basis."
>
> However for .reduce() to be useful for such applications, we would
> need to have at least *some* documented guarantee on its output.

Why? The result of the schoolbook implementation of Buchberger's
algorithm will result in *a* Gröbner basis, regardless of the concrete
choice of execution order in the implementation of polynomial reduction;
and if a reduced Gröbner basis is computed, it is *unique*.

>> But at least it is clear that the .reduce() method does polynomial
>> reductions and continues till no further reduction is possible;
>
> I agree with your analysis, but "no reduction is possible" is
> ambiguous: different textbooks mean different things by it (some mean
> Travis' algorithm, some others agree with Cox, Little and O'Shea).
>
> I would formulate it more precisely as "no monomial in the output is
> divisible by the leading monomial of any polynomial in I". This seems
> to be true given the examples I have, it would be good to have a
> confirmation (hidden somewhere in Singular's docs?)

Well, reducing the leading term is enough to get a Gröbner basis,
but you need tail reductions to compute the reduced Gröbner basis.
And Singular provides both options; I am sure Sage can use that, too.

Best regards,
Simon


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Erik Bray]

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

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

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


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

Re: [sage-devel] Re: Graphs: Hamiltonian path vs. cycle

[Jori Mäntysalo]

On Sat, 14 Oct 2017, Jori Mantysalo wrote:

Just read Wikipedia page and found the term "traversable". It seems to 
be less common than semi-eulerian... But a suggestion based on this: 
Let's make four functions


- is_eulerian
- is_traversable
- is_hamiltonian
- is_traceable

Crosslink is_eulerian <-> is_traversable and is_hamiltonian <-> is_traceable.


I did not get any answer to this.

But anyways, I found more. is_eulerian(path=True) will return either False 
OR an Eulerian path. This seems to be clearly wrong.


What's more, is_eulerian(path=True) returns True when the graph has an 
Eulerian path BUT has not Eulerian cycle. Is this normal use in graph 
theory?


--
Jori Mäntysalo

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

[Emmanuel Charpentier]

Dear Thierry,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I'd remove it in a cinch... 

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

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

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


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

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

--
Emmanuel Charpentier
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: What does MPolynomial_libsingular.reduce() do?

[john_perry_usm]

> I would formulate it more precisely as "no monomial in the output is 
> divisible by the leading monomial of any polynomial in I". This seems 
> to be true given the examples I have, it would be good to have a 
> confirmation (hidden somewhere in Singular's docs?) 
>

Curiously, the definition of "normal form" in the Singular docs differs 
from that in the Singular text; see 
http://www.singular.uni-kl.de/Manual/latest/sing_845.htm#IDX415 where 
normal form is defined with a standard basis G. In the text G can be any 
list of polynomials.

It is possible in Singular to reduce by something that is not a Gröbner 
basis but Singular usually complains when that happens. So, for instance, 
here is a computation I just carried out in Singular:

> ring R = 43,(x,y),dp;
> > ideal I = x2+y2-4,xy-1;
> > reduce(x3,I);
> // ** I is no standard basis
> 4x-y


The check that produces the warning is NOT a thorough check that G is a 
Gröbner basis; it merely inspects a flag to see if a Gröbner basis has been 
computed. You can circumvent the warning by setting the flag, so that even 
when it isn't a Gröbner basis there is no warning. I don't remember offhand 
how to set that flag.

Looking at the code, Sage first tries to see if it has cached a reduction 
already (at least, I think that's what I._groebner_strategy is about). If 
not, it invokes the Singular function kNF (line 4479 of 
sage/libs/singular/decl.pxd in Sage 8.0). Singular's source code is not 
well-known for documentation, and kNF is no exception: in my copy of the 
source there is more or less no documentation of what kNF is supposed to 
do. (My copy is old, but I know a developer pretty well & it's something 
we've talked about.) I worked with it some years back and as I recall kNF 
and the functions it calls together behave according to the description 
from the Singular text that I quoted earlier: "normal form" in that text is 
not the same as "normal form" in CLO. Figuring out exactly how they do this 
could be a challenge, because Singular can take one of many paths depending 
on the underlying data.

This is a long way of saying that I agree with the suggestion.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[William Stein]

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

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


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

William


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

[sage-devel] Live documentation with Thebe reloaded

[Nicolas M. Thiery]

Dear Sage developers,

You can find a demo of live documentation on:

https://more-sagemath-tutorials.readthedocs.io/

Pick e.g. "Demo basics", click "Activate", and wait a bit. To evaluate
a cell, use shift-Enter as in Jupyter.


This was made possible by:

- Sage on mybinder, which gives a service providing temporary Jupyter
  kernels for Sage (and friends)

- ThebeLab [2], an experimental rewrite of Thebe as a thin layer on
  JupyterLab (by Min, again!). ThebeLab should be much more
  maintainable than Thebe.

- Configuration done by Min and myself in sage-package

In principle, any Sage package (by which I mean a Python package using
Sage) that enables the "sage_package.sphinx" extension (provided by
the pip package "sage-package") will benefit from this feature for
free. See the setup.py and conf.py in:

https://github.com/sagemath/more-sagemath-tutorials/

This is still all rather experimental. In particular there should be a
standard mybinder image for use as default Sage computation backend
(this is currently using my experimental repo I advertised yesterday),
this should be configurable. And ThebeLab is still in its infancy.

But eventually we should update the Sage documentation to use this.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Thierry]

Hi,

the dichotomy of the vote is not clear to me.

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

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

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

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

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

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



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

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



Ciao,
Thierry




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

Re: [sage-devel] Re: Sage running on mybinder!

[Nicolas M. Thiery]

On Wed, Oct 18, 2017 at 02:26:02AM -0700, Eric Gourgoulhon wrote:
>Fantastic!
>Thanks for your work on this.

:-)

Now I am looking forward a sage-manifolds live demo!

Amitiés,
Nicolas
--
Nicolas M. Thiéry "Isil" 
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage running on mybinder!

[Nicolas M. Thiery]

On Wed, Oct 18, 2017 at 11:36:57AM +0200, Jeroen Demeyer wrote:
> Quick question: does the use the Jupyter software from Sage or from binder
> itself?

It runs the Jupyter server within the container, which is that shipped
by Sage.

That made it easy to activate the Pari/* kernels by just installing
the corresponding spkg.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: What does MPolynomial_libsingular.reduce() do?

[Luca De Feo]

> I agree that Sage devs don't (need to) know what *exact* algorithm is
> used. But at least it is clear that the .reduce() method does polynomial
> reductions and continues till no further reduction is possible; all this
> for a fixed monomial ordering (determined by the polynomial ring), in
> *some* order of execution that is considered an implementation detail
> and is thus not necessarily backwards compatible or compatible with an
> order of execution proposed in the literature.

Something along the lines of this paragraph would be a valuable
addition to the docstring of .reduce().

However, what's the use of such a function with
implementation-dependent outputs?

If I understand Martin's argument correctly, he is saying that
.reduce() *could* be used for a schoolbook "implementation of Gröbner
basis algorithms in Sage which call reduce, i.e. polynomial division
with remainders, on S-polynomials wrt to the current basis."

However for .reduce() to be useful for such applications, we would
need to have at least *some* documented guarantee on its output. You
say:

> But at least it is clear that the .reduce() method does polynomial
> reductions and continues till no further reduction is possible;

I agree with your analysis, but "no reduction is possible" is
ambiguous: different textbooks mean different things by it (some mean
Travis' algorithm, some others agree with Cox, Little and O'Shea).

I would formulate it more precisely as "no monomial in the output is
divisible by the leading monomial of any polynomial in I". This seems
to be true given the examples I have, it would be good to have a
confirmation (hidden somewhere in Singular's docs?)

Luca

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Using C++ library from Sage

[Ralf Stephan]

On Wednesday, October 18, 2017 at 4:31:16 PM UTC+2, Eric Gourgoulhon wrote:
>
> Any example of an existing C++ / Sage interaction would also be 
> appreciated. 
>

src/sage/libs for example pynac, polybori, or singular

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Using C++ library from Sage

[Francesco Biscani]

Consider pybind11 as a (probably better) alternative to Boost Python:

https://pybind11.readthedocs.io/en/stable/

You will need a C++11 capable compiler, but the gains in terms of ease of
use, compilation speed and memory usage are IMO well worth it.

On 18 October 2017 at 16:31, Eric Gourgoulhon 
wrote:

> Hi Sage Devs,
>
> We plan to develop some experimental package for Sage, which requires to
> make use of a C++ library (basically this is to implement numerical
> calculus on manifolds). What would you recommend to make the link between
> Sage (Python) code and that library?
> - Cython ?
> - Boost ?
> - ???
> Any example of an existing C++ / Sage interaction would also be
> appreciated.
>
> Best regards,
>
> Eric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Emmanuel Charpentier]

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

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

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

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


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

--
Emmanuel Charpentier

>
> Dave 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: What does MPolynomial_libsingular.reduce() do?

[Simon King]

Hi Luca,

On 2017-10-18, Luca De Feo  wrote:
> I hate to sound snarky, but...

No offence taken...

> Yet, none of us seems to be able to second guess what kind of normal
> form is actually implemented by .reduce() (Singular's kNF, actually).
> And from the answers to this thread, it seems to me that neither Sage
> devs can.

I agree that Sage devs don't (need to) know what *exact* algorithm is
used. But at least it is clear that the .reduce() method does polynomial
reductions and continues till no further reduction is possible; all this
for a fixed monomial ordering (determined by the polynomial ring), in
*some* order of execution that is considered an implementation detail
and is thus not necessarily backwards compatible or compatible with an
order of execution proposed in the literature.

Best regards,
Simon


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Using C++ library from Sage

[Jeroen Demeyer]

On 2017-10-18 16:31, Eric Gourgoulhon wrote:

Hi Sage Devs,

We plan to develop some experimental package for Sage, which requires to
make use of a C++ library (basically this is to implement numerical
calculus on manifolds). What would you recommend to make the link
between Sage (Python) code and that library?
- Cython ?
- Boost ?
- ???


If your focus is mainly on Sage, then Cython looks like a natural 
choice. There are many Cython modules in Sage, but no Boost/Python modules.



Any example of an existing C++ / Sage interaction would also be
appreciated.


src/sage/graphs/base/boost_graph.pxd

src/sage/libs/coxeter3/decl.pxd

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Using C++ library from Sage

[Eric Gourgoulhon]

Hi Sage Devs,

We plan to develop some experimental package for Sage, which requires to 
make use of a C++ library (basically this is to implement numerical 
calculus on manifolds). What would you recommend to make the link between 
Sage (Python) code and that library? 
- Cython ? 
- Boost ?  
- ???
Any example of an existing C++ / Sage interaction would also be 
appreciated. 

Best regards,

Eric.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Dr. David Kirkby (Kirkby Microwave Ltd)]

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

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

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: What does MPolynomial_libsingular.reduce() do?

[Luca De Feo]

Hi Simon,

I hate to sound snarky, but...

> When reading `normal form` and `Groebner basis` in the same sentence,
> the meaning should be clear to anybody who took a course in commutative
> algebra. So, the question is: Whom should documentation be addressed to?
>
> I do *not* think that documentation should always be addressed to
> non-experts.

I am teaching a commutative algebra class to grad students. They and I
perfectly know what a Gröbner basis is. I have read many times Cox,
Little and O'Shea, and I hope my students have too.

Yet, none of us seems to be able to second guess what kind of normal
form is actually implemented by .reduce() (Singular's kNF, actually).
And from the answers to this thread, it seems to me that neither Sage
devs can.

So, maybe, we should at least modify the documentation so that
*experts* can understand it.

FTR, my question was raised by an exercise in my course book that is
several (about 6?) years old, whose goal was exactly to teach the
students that f.reduce([g, h]) can give different results from
f.reduce([h, g]) when [g, h] is not a Gröbner basis. At some point in
the past, Sage behaviour changed, and the two calls stopped giving
different results for the specific f,g,h in the exercise (at least I
think it used to give different results, my memory may be faulty).

Luca

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] What does MPolynomial_libsingular.reduce() do?

[Luca De Feo]

> The algorithm in question is described in “Ideals, Varieties, and
> Algorithms” by David Cox, John Little and Donal O’Shea in Section "§3 A
> Division Algorithm in k[x_1 , … , x_n]".

It is not:

sage: A. = PolynomialRing(QQ, order="lex")
sage: (x*y^2 + 1).reduce([x*y + 1, y+1])
x + 1
sage: (x*y^2 + 1).reduce([y+1, x*y + 1])
x + 1

whereas Example 1 in §3 gives remainder 2;

sage: A. = PolynomialRing(QQ, order="lex")
sage: (x^2*y + x*y^2 + y^2).reduce([x*y - 1, y^2 - 1])
2*x + 1
sage: (x^2*y + x*y^2 + y^2).reduce([y^2 - 1, x*y - 1])
2*x + 1

whereas Example 2 gives remainder x + y + 1.


> My understanding is it does the (naïve?) reduction algorithm:
>
> reducing = True
> while reducing:
> reducing = False
> for expr in I:
> if expr.leading_monomial().divides(cur.leading_monomial()):
> cur -= cur.leading_term() / expr.leading_term() * expr
> reducing = True

It does not:

sage: def travis_red(f, I):
: cur = f
: reducing = True
: while reducing:
: reducing = False
: for expr in I:
: if expr.lm().divides(cur.lm()):
: cur -= cur.lt() // expr.lt() * expr
: reducing = True
: return cur
:
sage: travis_red(x^2*y + x*y^2 + y^2, [y^2 - 1, x*y - 1])
2*x + y^2


> Singular itself does this (see pp. 51-52 of "A Singular Introduction
> to Commutative Algebra") and the text even speaks of a non-unique "NF
> [normal form] w.r.t. a non-standard basis", illustrating how the
> results are different when the basis is not standard (aka Gröbner)
> and how there is a unique canonical result when the basis is
> standard.

Singular seems to have changed algorithm since. The example 1.6.13
you're referring to computes slightly different:

sage: A. = PolynomialRing(QQ, order="degrevlex")
sage: f = x^2*y*z + x*y^2*z + y^2*z + z^3 + x*y
sage: f1 = x*y + y^2 - 1
sage: f2 = x*y
sage: f.reduce([f1, f2]) # same as in the example
y^2*z + z^3
sage: f.reduce([f2, f1]) # missing a xz monomial
y^2*z + z^3 - y^2 + 1


Luca

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Erik Bray]

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage running on mybinder!

[kcrisman]

 Nice!

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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

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


+1

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


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


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Emmanuel Charpentier]

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

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

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

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

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

Try it for yourself ;-).
 

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

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

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

See above.
 

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

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

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

--
Emmanuel Charpentier

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Dr. David Kirkby (Kirkby Microwave Ltd)]

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

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

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

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

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

What in my opinion is insulting is to

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

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

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Maarten Derickx]

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

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Emmanuel Charpentier]

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

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

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

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

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

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

--
Emmanuel Charpentier

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage running on mybinder!

[Jeroen Demeyer]

Quick question: does the use the Jupyter software from Sage or from 
binder itself?


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage running on mybinder!

[Eric Gourgoulhon]

Fantastic!

Thanks for your work on this.
Best regards,

Eric.


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Emmanuel Charpentier]

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


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

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

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

--
Emmanuel Charpentier

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Dima Pasechnik]

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

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Emmanuel Charpentier]

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

Cygwin ?

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

--
Emmanuel Charpentier 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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


So my vote is "No".

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Dima Pasechnik]

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

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


 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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

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


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


Does anybody know how this works for R?

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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

The choice for users installing the Sage binary is between:


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


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Cannot push to trac - some git issue

[Simon Brandhorst]

Thank you guys for your help. It worked :)

What confused me was that there were two merge conflicts. One between the 
two branches  and one between them and the latest beta version. 


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.