Proposal: Remove GNUTLS from Sage.
William Stein
PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
libgcrypt, and
libgpg_error from Sage-5.0. See below for details.
VOTE:
[ ] Yes, remove them!
[ ] No, we need them.
[ ] Woops -- you are confused and didn't realize that ________________.
DETAILS:
The Sage notebook supports a "secure=True" option, which encrypts
communication between the notebook server and clients. This currently
depends on hacked-in support in Twisted for GNUTLS instead of OpenSSL,
because GNUTLS is GPL and OpenSSL is GPL-incompatible. GNUTLS has a
long list of dependencies, all of which we build from source with some
pain.
Twisted does not (and will likely never) officially support using
GNUTLS instead of OpenSSL; we had support with the version of Twisted
in Sage by hacking it in. For the new flask-based notebook for
Sage-5.0 we would have to do this hacking again (for the newer Twisted
spkg). This is holding up the release.
Very few people actually use the notebook in secure=True mode. For
those that do, I think it is reasonable to require them to build
Python with openssl support. Probably Sage doesn't even work without
building it that way, at least on some systems (I'm currently confused
on this point). In the worst case, they will have to ensure that some
openssl headers are installed, and rebuild Python. As long as we
aren't distributing openssl, there are no license issues.
Removing the above 5 packages will save space, make Sage build more
quickly and easily, and make the release manager and developer's job
easier. The only loss in functionality is that some people might not
have support for "secure=True" *out of the box*. For individual users,
I think using ssh tunnels is much better than https anyways. For
localhost users, secure=True is irrelevant. For people setting up a
server who will user secure=True, they *should* get a properly signed
certificate, so they are likely very sophisticated users willing to do
some extra work (incidentally, I have never once in the history of
Sage heard of anybody successfully run a Sage notebook server using
secure=True with a valid non-self-signed certificate!).
When I originally pushed to have secure=True easily available by
default in Sage for all users, I (1) didn't understand that
secure=False is safe on localhost, (2) didn't understand how easy ssh
port forwarding is, and (3) didn't realize how important (and
socially difficult) it is to have a non-self-signed certificate.
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Julien Puydt
> Hi Sage-Devel,
>
> PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
> libgcrypt, and
> libgpg_error from Sage-5.0. See below for details.
> Removing the above 5 packages will save space, make Sage build more
> quickly and easily, and make the release manager and developer's job
> easier. The only loss in functionality is that some people might not
> have support for "secure=True" *out of the box*. For individual users,
> I think using ssh tunnels is much better than https anyways. For
> localhost users, secure=True is irrelevant. For people setting up a
> server who will user secure=True, they *should* get a properly signed
> certificate, so they are likely very sophisticated users willing to do
> some extra work (incidentally, I have never once in the history of
> Sage heard of anybody successfully run a Sage notebook server using
> secure=True with a valid non-self-signed certificate!).
>
> When I originally pushed to have secure=True easily available by
> default in Sage for all users, I (1) didn't understand that
> secure=False is safe on localhost, (2) didn't understand how easy ssh
> port forwarding is, and (3) didn't realize how important (and
> socially difficult) it is to have a non-self-signed certificate.
Answer:
[X] Yes, remove them!
... and make as many other things "use what's available on the system if
possible" as possible.
Snark on #sagemath
John Cremona
and the rebuild python, since otherwise mercurial does not work when
pull/pushing to a remote place. (I tihnk that this is stil the case
when on a machine with its own mercurial, not using Sage's mercurial,
though I cannot see how installing something in Sage could affect
that). It would be hugely convenient to me not to have to do this
ever again. How is this affected by your proposed change (if at all)?
I do currently run a Sage server on a machine with secure=True, but it
would not be impossibly inconvenient to have it only available to
users with an ordinary account on the same machine (via ssh
tunnelling) if that would be necessary after your proposed change.
In any case, because of firewall issues only those with a normal
account can access it from off campus.
John
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
Michael Orlitzky
On 01/09/12 11:39, William Stein wrote:
> ... For people setting up a
> server who will user secure=True, they *should* get a properly signed
> certificate, so they are likely very sophisticated users willing to do
> some extra work (incidentally, I have never once in the history of
> Sage heard of anybody successfully run a Sage notebook server using
> secure=True with a valid non-self-signed certificate!).
>
> When I originally pushed to have secure=True easily available by
> default in Sage for all users, I (1) didn't understand that
> secure=False is safe on localhost, (2) didn't understand how easy ssh
> port forwarding is, and (3) didn't realize how important (and
> socially difficult) it is to have a non-self-signed certificate.
I would argue that self-signed certificates are safer than "valid"
CA-signed ones, since, in both cases there's exactly one opportunity for
a MITM attack and in the latter, you additionally have to secure the
entire CA infrastructure.
That has absolutely no bearing on this issue, though.
The effort needed to keep all this stuff in sage is better spent elsewhere.
Dima Pasechnik
On Tuesday, 10 January 2012 00:39:30 UTC+8, William wrote:
Hi Sage-Devel,PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
libgcrypt, and
libgpg_error from Sage-5.0. See below for details.VOTE:
[X ] Yes, remove them!
Jeroen Demeyer
If this is possible, that would be a very good idea. Where's the
ticket, such that I can give it positive_review :-)
Nils Bruin
> When I originally pushed to have secure=True easily available by
> default in Sage for all users, I
> (1) didn't understand that secure=False is safe on localhost,
the notebook, I agree. However, on a machine with multi-account login
(nearly any unix/linux/mac workstation in a department network), even
listening on localhost provides a larger attack surface. If I'm
running notebook() and someone logs in to the machine and connects to
the notebook, there is now another way someone could try to run code
under a different (my!) identity. Normally people will probably not
realize that by starting notebook() they are increasing their attack
surface. I don't think including GnuTLS solves this problem, so I'm
not against dropping it.
Are there things we can do to improve (perceived) security around this?
Michael Orlitzky
>
> Via the absolutely zero-configuration one-time certificate opening of
> the notebook, I agree. However, on a machine with multi-account login
> (nearly any unix/linux/mac workstation in a department network), even
> listening on localhost provides a larger attack surface. If I'm
> running notebook() and someone logs in to the machine and connects to
> the notebook, there is now another way someone could try to run code
> under a different (my!) identity. Normally people will probably not
> realize that by starting notebook() they are increasing their attack
> surface. I don't think including GnuTLS solves this problem, so I'm
> not against dropping it.
>
> Are there things we can do to improve (perceived) security around this?
>
I just spent thirty seconds starting a notebook (bringing my total
notebook usage up to about thirty-seconds-worth): don't you need a
username/password to run sage code?
If there's a bug in the web server software, it could allow "remote"
execution over localhost. Otherwise, it looks to me like you have to log
in to do any damage.
Sending your admin password over the loopback interface unencrypted is
safe, since only root can sniff it.
mmarco
but are not that sophisticated is as unusual as William assumes. I
know several examples (and i am one of them). I would agree with the
elimination of this option IF the way to recompile it with openssl
support is adequately documented (and this documentation is easy to
find).
IanSR
[X] Yes, remove them!
Somewhat coincidentally, Jason and I were looking at this today. The express summary is that Jason and I have put together a patch today that solves the FlaskNB+HTTPS problem (caused by an attempt to use TLS with the latest Twisted 2), and to do so it rips out GnuTLS dependencies in exchange for adding in PyOpenSSL dependencies.
Some more details for those who are interested:
There is no good way to support GnuTLS without continuing to maintain a patched version of Twisted. See the 3rd (and last) post in this thread from a Twisted developer who said GnuTLS support would be a long way off (post from 14 months ago):
http://twistedmatrix.com/pipermail/twisted-python/2010-October/022988.html
For the record, the second post in that thread suggested we could get TLS support by adding:
ssl:443:sslmethod=TLSv1_METHODgrep for strport in run_notebook.py for details, or google for "twisted ssl:443:sslmethod" if you want more details on this.
to the Twisted "strports" configuration in run_notebook.py, as follows:
strport = 'ssl:443:sslmethod=TLSv1_METHOD:%s:%s:interface=%s:privateKey=%s:certKey=%s' ...
Unfortunately this doesn't solve the problem -- looks like it throws off the mini-parser for strports, and whether I put it at the start or end of the string I get weird errors that don't seem worth looking into. What we're doing is a variation on the patches provided on github in June 2011:
https://github.com/cschwan/sage-on-gentoo/issues/63
Cheers,
Ian
Florent Hivert
I agrees with that... Wouldn't be sufficient to provide a modified python spkg
which presuppose to have ssl installed on the computer ?
Cheers,
Florent
kcrisman
up their Sage notebook servers? If anything changes there in terms
of security, it would need to be really well documented on the setup
pages.
- kcrisman
Jason Grout
Changes would be:
1. install openssl development libraries (e.g., libssl-dev)
2. install sage
I think that's pretty much it, and everything else should be the same.
Thanks,
Jason
kcrisman
On Jan 9, 8:45 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> On 1/9/12 8:36 PM, kcrisman wrote:
>
> > As a very naive question, how would this change the way campuses set
> > up their Sage notebook servers? If anything changes there in terms
> > of security, it would need to be really well documented on the setup
> > pages.
>
> Changes would be:
>
> 1. install openssl development libraries (e.g., libssl-dev)
>
event this happens? Which seems extremely likely :)
Robert Bradshaw
situation; it's needed only by the few (and the technically capable)
and is a lot of weight for something that looks to always be an
incomplete hack around not having OpenSSL on the system. Just make
sure that it's clearly documented to that to run with secure=True
(perhaps this could be renamed to ssl=True, so secure=False doesn't
sound so bad) one needs to instal ssl before building Sage (or at
least its Python). Setting up a public/multi-user server has larger
security implications anyways (e.g. setting up workers in a VM or
other trusted environment depending on the set of users).
On Mon, Jan 9, 2012 at 8:39 AM, William Stein <wst...@gmail.com> wrote:
> Hi Sage-Devel,
>
> PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
> libgcrypt, and
> libgpg_error from Sage-5.0. See below for details.
>
> VOTE:
>
> [X] Yes, remove them!
Jason Grout
> It pains me a bit to say yes, but I agree with your assessment of the
> situation; it's needed only by the few (and the technically capable)
> and is a lot of weight for something that looks to always be an
> incomplete hack around not having OpenSSL on the system. Just make
> sure that it's clearly documented to that to run with secure=True
> (perhaps this could be renamed to ssl=True, so secure=False doesn't
> sound so bad) one needs to instal ssl before building Sage (or at
> least its Python). Setting up a public/multi-user server has larger
> security implications anyways (e.g. setting up workers in a VM or
> other trusted environment depending on the set of users).
How about changing it to protocol='https' instead of ssl=True or
secure=True? Of course, the default would be protocol='http'
Thanks,
Jason
Robert Bradshaw
+1
>
> Thanks,
>
> Jason
Dr David Kirkby
On Jan 9, 4:39 pm, William Stein <wst...@gmail.com> wrote:
> Hi Sage-Devel,
>
> PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
> libgcrypt, and
> libgpg_error from Sage-5.0. See below for details.
>
> VOTE:
>
> [ ] Yes, remove them!
> [ ] No, we need them.
> [ ] Woops -- you are confused and didn't realize that ________________.
[ ] I understand the issues. I don't want to make a quick decision.
> DETAILS:
>
> The Sage notebook supports a "secure=True" option, which encrypts
> communication between the notebook server and clients. This currently
> depends on hacked-in support in Twisted for GNUTLS instead of OpenSSL,
> because GNUTLS is GPL and OpenSSL is GPL-incompatible. GNUTLS has a
> long list of dependencies, all of which we build from source with some
> pain.
able to remove them anyway.
But the GPL issue is one you should not forget.
> Very few people actually use the notebook in secure=True mode. For
> those that do, I think it is reasonable to require them to build
> Python with openssl support.
> When I originally pushed to have secure=True easily available by
> default in Sage for all users, I (1) didn't understand that
> secure=False is safe on localhost, (2) didn't understand how easy ssh
> port forwarding is
users if their admin permits it. By default, on a number of systems,
that wont be true. Both Solaris and CentOS (redhat clone), will not
allow X forwarding over SSH unless the admin changes the sshd_config
file.
# X11 tunneling options
X11Forwarding yes
if that is commented out, or set to "no", then X forwarding wont
work.
I don't know how many Linux distributions ship with that by default,
but I know CentOS does, so I assume Redhat and Oracle Linux. Solaris
too.
Dave
William Stein
On Jan 14, 2012 9:00 AM, "Dr David Kirkby" <drki...@gmail.com> wrote:
>
>
>
> On Jan 9, 4:39 pm, William Stein <wst...@gmail.com> wrote:
> > Hi Sage-Devel,
> >
> > PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
> > libgcrypt, and
> > libgpg_error from Sage-5.0. See below for details.
> >
> > VOTE:
> >
> > [ ] Yes, remove them!
> > [ ] No, we need them.
> > [ ] Woops -- you are confused and didn't realize that ________________.
>
> How about adding:
>
> [ ] I understand the issues. I don't want to make a quick decision.
>
>
> > DETAILS:
> >
> > The Sage notebook supports a "secure=True" option, which encrypts
> > communication between the notebook server and clients. This currently
> > depends on hacked-in support in Twisted for GNUTLS instead of OpenSSL,
> > because GNUTLS is GPL and OpenSSL is GPL-incompatible. GNUTLS has a
> > long list of dependencies, all of which we build from source with some
> > pain.
>
> Are those dependencies used elsewhere though?
No, I don't think so.
> If so, you might not be
> able to remove them anyway.
>
> But the GPL issue is one you should not forget.
>
> > Very few people actually use the notebook in secure=True mode. For
> > those that do, I think it is reasonable to require them to build
> > Python with openssl support.
>
> Makes Sage non GPL
No it doesn't. There is a linking-with-system-libraries ckause in the GPL.
>
> > When I originally pushed to have secure=True easily available by
> > default in Sage for all users, I (1) didn't understand that
> > secure=False is safe on localhost, (2) didn't understand how easy ssh
> > port forwarding is
>
> You are missing an important point here. SSH forwarding is easy for
> users if their admin permits it. By default, on a number of systems,
> that wont be true. Both Solaris and CentOS (redhat clone), will not
> allow X forwarding over SSH unless the admin changes the sshd_config
> file.
>
> # X11 tunneling options
> X11Forwarding yes
>
> if that is commented out, or set to "no", then X forwarding wont
> work.
I am *not* talking about X forwarding but port forwarding. They are completely different.
> I don't know how many Linux distributions ship with that by default,
> but I know CentOS does, so I assume Redhat and Oracle Linux. Solaris
> too.
>
> Dave
>
Dr David Kirkby
On Jan 14, 5:07 pm, William Stein <wst...@gmail.com> wrote:
I know there is this clause
"However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable. "
But OpenSSL can't be considered to fall into that.
> > if that is commented out, or set to "no", then X forwarding wont
> > work.
>
> I am *not* talking about X forwarding but port forwarding. They are
> completely different.
"entreprise" level operating systems. I am not on a Unix box just now,
but I suspect that might fall into the same category as X forwarding.
It probably depends on how sshd_config is set up, and that will depend
on the level of paranoia of the system admin.
But to be honest, if I was bothered about security, I would not rely
on the "Secure=True" mode of Sage, as I would not trust its been
implemented as well as security has been on tools designed to be
secure.
Dave
John H Palmieri
On Saturday, January 14, 2012 9:07:08 AM UTC-8, William wrote:
On Jan 14, 2012 9:00 AM, "Dr David Kirkby" <drki...@gmail.com> wrote:
>
>
>
> On Jan 9, 4:39 pm, William Stein <wst...@gmail.com> wrote:
> > Very few people actually use the notebook in secure=True mode. For
> > those that do, I think it is reasonable to require them to build
> > Python with openssl support.
>
> Makes Sage non GPLNo it doesn't. There is a linking-with-system-libraries ckause in the GPL.
--
John
Jeroen Demeyer
> Yes, and are you sure port fowarding is permitted by the more
> "entreprise" level operating systems. I am not on a Unix box just now,
> but I suspect that might fall into the same category as X forwarding.
> It probably depends on how sshd_config is set up, and that will depend
> on the level of paranoia of the system admin.
1024) can be done by any program, it doesn't need any special
privileges. If ssh disallows it, it is really some kind of DRM.
William Stein
> What part of the GPL? Can you be more specific.
>
> I know there is this clause
>
> "However, as a special exception, the source code distributed need not
> include anything that is normally distributed (in either source or
> binary form) with the major components (compiler, kernel, and so on)
> of the operating system on which the executable runs, unless that
> component itself accompanies the executable. "
>
> But OpenSSL can't be considered to fall into that.
1. "can't?" OpenSSL is actually considered to fall into that
category by a lot of people, as explained here [1], which claims that
"most distributions" consider OpenSSL to fall under the operating
system exemption, with two notable exceptions (Debian and FSF). I
don't think we need to depend on this though.
2. We could instead solve this problem by adding an OpenSSL exemption
to the GPL-license on the Sage Notebook, as is discussed in detail at
[3], and there are examples of this listed at [4]. We can do this
because me (and a relatively small number of people) own the copyright
on all GPL'd code in the notebook, and I *think* none of the
dependencies of the notebook are GPL'd. Moreover, the notebook
server doesn't link in the Sage library. The following from the
GPL faq [2] is important: "If the program uses fork and exec to
invoke plug-ins, then the plug-ins are separate programs, so the
license for the main program makes no requirements for them." The
Sage Notebook server uses fork and exec to invoke ssh, which then
invokes Sage itself possibly on another computer.
3. We could also BSD license the Sage notebook. A huge advantage to
this would be that it would make full two-way collaboration with the
new Ipython notebook [5] possible. I'm personally willing to switch
to BSD for the Sage notebook (I have also received emails from many
notebook contributors such as Tom Boothby explicitly giving me
permission to change the license to BSD, so this wouldn't be too
hard).
SUMMARY: The Sage Notebook (in secure mode) is the only part of Sage
that potentially uses openssl. We can modify the notebook license.
By changing the license we can resolve potential license issues.
The only potential weak link would be if there are GPL'd dependencies
for any component of the notebook, but I'm 99% sure there aren't any,
since the world of web development (and javascript) is mostly free of
the GPL "virus". (I like GPL in some cases, but it is viral.)
[1] http://lwn.net/Articles/428111/
[2] http://www.gnu.org/licenses/gpl-faq.html
[3] http://people.gnome.org/~markmc/openssl-and-the-gpl.html
[4] http://en.wikipedia.org/wiki/OpenSSL
[5] http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html
-- William
William Stein
Unclear, since we have so many options at present. For example, at a
minimum we *could* just delete the *ssl.so module from the Python
build. Then the user who wants to use secure=True would have to
rebuild Python to fix this (via "sage -f python"), or get that ssl
module for Python in some other way.
Users (and internal distributors) can do whatever they want with a
GPL'd program, so long as they don't publicly redistribute it.
-- William
David Kirkby
On Sat, Jan 14, 2012 at 9:22 AM, Dr David Kirkby <drki...@gmail.com> wrote:1. "can't?" OpenSSL is actually considered to fall into that
> What part of the GPL? Can you be more specific.
>
> I know there is this clause
>
> "However, as a special exception, the source code distributed need not
> include anything that is normally distributed (in either source or
> binary form) with the major components (compiler, kernel, and so on)
> of the operating system on which the executable runs, unless that
> component itself accompanies the executable. "
>
> But OpenSSL can't be considered to fall into that.
category by a lot of people, as explained here [1], which claims that
"most distributions" consider OpenSSL to fall under the operating
system exemption, with two notable exceptions (Debian and FSF). I
don't think we need to depend on this though.
-- William
Personally I don't see how OpenSSL can be considered a major part of the operating system. Given there are loads of Unix and Linux systems running without OpenSSL being installed, and they run fine, I don't believe it can be considered a major component of the operating system.
I suspect "most distributions" consider OpenSSL to fall under the exemption as it suites them to do so. I believe the FSF and Debian are right to not consider it a major part of the OS.
But then personally I don't consider the compiler a component of the operating system. To me a compiler is an application and not part of the OS at all, yet the GPL refers to it as a major component.
Dave
Volker Braun
Personally I don't see how OpenSSL can be considered a major part of the operating system.
Dr. David Kirkby
I don't see any reference to "system library" and I certainly would have thought
"totally insignificant" and "major" to have different meanings.
Clearly OpenSSL is not shipped as part of the OS for many.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Volker Braun
I don't see any reference to "system library"
and I certainly would have thought
"totally insignificant" and "major" to have different meanings.
Clearly OpenSSL is not shipped as part of the OS for many.
Keshav Kini
> Hi Sage-Devel,
>
> PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
> libgcrypt, and
> libgpg_error from Sage-5.0. See below for details.
all the SPKGs you mentioned being shipped with Sage 5.2. Furthermore we
now depend on OpenSSL being on the system, and on its dev headers being
installed. It looks to me like the situation has worsened.
> VOTE:
>
> [ ] Yes, remove them!
> [ ] No, we need them.
> [ ] Woops -- you are confused and didn't realize that ________________.
still the prevailing opinion?
> DETAILS:
>
> The Sage notebook supports a "secure=True" option, which encrypts
> communication between the notebook server and clients. This currently
> depends on hacked-in support in Twisted for GNUTLS instead of OpenSSL,
> because GNUTLS is GPL and OpenSSL is GPL-incompatible. GNUTLS has a
> long list of dependencies, all of which we build from source with some
> pain.
>
> GNUTLS instead of OpenSSL; we had support with the version of Twisted
> in Sage by hacking it in. For the new flask-based notebook for
> Sage-5.0 we would have to do this hacking again (for the newer Twisted
> spkg). This is holding up the release.
>
> those that do, I think it is reasonable to require them to build
> building it that way, at least on some systems (I'm currently confused
> on this point). In the worst case, they will have to ensure that some
> openssl headers are installed, and rebuild Python. As long as we
> aren't distributing openssl, there are no license issues.
>
> Removing the above 5 packages will save space, make Sage build more
> quickly and easily, and make the release manager and developer's job
> easier. The only loss in functionality is that some people might not
> have support for "secure=True" *out of the box*. For individual users,
> I think using ssh tunnels is much better than https anyways. For
> localhost users, secure=True is irrelevant. For people setting up a
> server who will user secure=True, they *should* get a properly signed
> certificate, so they are likely very sophisticated users willing to do
> some extra work (incidentally, I have never once in the history of
> Sage heard of anybody successfully run a Sage notebook server using
> secure=True with a valid non-self-signed certificate!).
>
> default in Sage for all users, I (1) didn't understand that
> secure=False is safe on localhost, (2) didn't understand how easy ssh
> socially difficult) it is to have a non-self-signed certificate.
rid of the OpenSSL headers dependency which has been causing users so
much trouble since 5.2 was released. We can just stop packaging
pyOpenSSL with the sagenb SPKG, and instead require users who want to
use `notebook(secure=True)` to install it manually with `sage --sh -c
easy_install pyOpenSSL`. Or am I missing something?
-Keshav
----
Join us in #sagemath on irc.freenode.net !
François Bissey
notebook came in.
+1 for removal.
Francois
John H Palmieri
On Monday, August 20, 2012 8:35:45 PM UTC-7, Keshav Kini wrote:
William Stein <wst...@gmail.com> writes:
> Hi Sage-Devel,
>
> PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
> libgcrypt, and
> libgpg_error from Sage-5.0. See below for details.
Half a year later, it seems nothing came of this, since we still have
all the SPKGs you mentioned being shipped with Sage 5.2. Furthermore we
now depend on OpenSSL being on the system, and on its dev headers being
installed. It looks to me like the situation has worsened.
> VOTE:
>
> [ ] Yes, remove them!
> [ ] No, we need them.
> [ ] Woops -- you are confused and didn't realize that ________________.
Almost everyone in the thread voted to remove these packages. Is that
still the prevailing opinion?
Yes, remove them, and even better if we can remove the dependency on OpenSSL.
--
John
Keshav Kini
> If this is still your view, it seems to me that we can probably even get
> rid of the OpenSSL headers dependency which has been causing users so
> much trouble since 5.2 was released. We can just stop packaging
> pyOpenSSL with the sagenb SPKG, and instead require users who want to
> use `notebook(secure=True)` to install it manually with `sage --sh -c
> easy_install pyOpenSSL`. Or am I missing something?
Keshav Kini
> I made this #13385 - http://trac.sagemath.org/sage_trac/ticket/13385
dependency from sagenb: https://github.com/sagemath/sagenb/pull/95
Anyone want to review it real quick? +22/-6 diff.
fero
Dear all,
please forgive me if I say something "stupid", but I am still a SAGE newbie.
I have read this thread also because I experimented weird problems with the libgnutls installed in sage
as you can read in http://ask.sagemath.org/question/1674/psycopg2-importerror-libgnutls-on-debian-wheezy
IMHO gnutls should be removed from SAGE if it is just used for notebook secure=True to provide https connection,
because this argument could be relegated to the deployment enivronment which should be in care of sysadmins that deploy
SAGE notebook somewhere.
My opinion is that Twisted, Flask, or any other kind of application server like Django, should be deployed behind a
__real__ webserver like Apache, or Cherokee or something else that could handle easily, reliably, and scalability
secure connections.
So I think it would be better to provide a documentation page like
Deploy (secure) SAGE notebook
=================
With the Apache Web Server
------------------------------------
1. Install Apache 2
2. Install mod_proxy mod_proxy_http mod_rewrite
3. Setup your site like...
<VirtualHost *:443>
SSLEngine on
SSLCACertificatePath /etc/apache2
SSLCertificateFile /etc/apache2/apache.pem
RewriteEngine on
ProxyRequests off
RewriteRule ^/(.*) https://localhost:9000/$1 [P]
</VirtualHost>
My 2 cents
Luca
Keshav Kini
> IMHO gnutls should be removed from SAGE if it is just used for
> notebook secure=True to provide https connection,
> because this argument could be relegated to the deployment
> enivronment which should be in care of sysadmins that deploy
> SAGE notebook somewhere.
fero
Il giorno lunedì 27 agosto 2012 08:34:45 UTC+2, Keshav Kini ha scritto:
fero <lu...@befair.it> writes:
> IMHO gnutls should be removed from SAGE if it is just used for
> notebook secure=True to provide https connection,
> because this argument could be relegated to the deployment
> enivronment which should be in care of sysadmins that deploy
> SAGE notebook somewhere.
See trac #13392 - http://trac.sagemath.org/sage_trac/ticket/13392
Thx I read the ticket, I was just only saying that it could be documented and took away from SAGE problems.
Do not care about ssl/tls in sage either.