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? > 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. 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 ---- Join us in #sagemath on irc.freenode.net ! -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
