Our SSL serial drama-cum-cliffhanger

[Emmanuel Charpentier]

Dear list,

We have three separate, but interacting, difficulties with SSL/TLS support in Sage. I'll summarize the results of the efforts of several people who tracked them, and propose a couple of solutions.

I) Python now (discreetly) depends on Open SSL.

Their license page states :

The modules hashlib, posix, ssl, crypt use the OpenSSL library for added performance if made available by the operating system. Additionally, the Windows and Mac OS X installers for Python may include a copy of the OpenSSL libraries, so we include a copy of the OpenSSL license here:

followed by the bizarre OpenSSL license. For our purpose, the important statement is "use the OpenSSL library for added performance if made available by the operating system.".

"Added performance, my a^htired foot : Thierry has checked the possibilities of an OpenSSL-less Sage, and I have further checked other possibilities. Our trials conclusively demonstrate that Gnu TLS can't be substituted to OpenSSL for at least the following reasons :

• Sage's pip is non-functionnal when compiled against Gnu TLS
• Ditto for Sage's git
• I understand (but have not checked) that  Python's hashlib module, which depends on openssl, is used in Sage.

However, contrary to my expectations, R 3.3.2 can be compiled in Sage against a curl library using Gnu TLS and keep a functional HTTPS access to R repositories.

Consequences :

• Sage *can*be built and run without OpenSSL support, (as long as R is < 3.3 or  some SSL support is available for R >= 3.3), but this system will have severe limitations (among others, no access to pip resources, questionable  support for Sage's git).
• OpenSSL can be retrofitted in such a system by installing the openssl package, but this retrofit becomes effective after recompilation of python2 (at least).

This latter "solution" is, at best, a contraption (even if something in this direction has been proposed back in 2012 to solve the very same problem). Therefore :

• we must at minimum advertise this problem in the REAME.md file and recommend checking the presence of OpenSSL, and recommend the installation of openssl development files for Sage compilation. In this case, we would have to :
• provide a standard package providing some HTTPS-capable SSL support. Ideally, this package should be able to check for the presence of suitable systemwide libraries, and in this case, do nothing ;
  
• use this SSL support to provide an HTP-enabled curl for R>=3.3 (with again, the possibility of usinf a systemwide curl library).
  
• We should acknowledge our de facto dependence on a systemwide OpenSSL (in terms close to those used by the Python license). In this case, we would have to provide a standard curl package, with the same provisions as before.

The first solution, used on a system without OpenSSL, will create a crippled Sage. Furthermore, it needs writing two standard packages, installing widely-diffused utilities (it seems awfully difficult to install a Debian system sans OpenSSL : even a freshly installed "base system + common utilities" has openssl, on which Debian's reportbug and various utilities depend).

I would rather acknowledge our dependence on OpenSSL, recommend its installation and advertise the limitations of an OpenSSL-less Sage, leaving this possibility open to prudes...

II) OpenSSL has broken a lot of software.

OpenSSL 1.1.0 has broken a lot of OpenSSL-using software at the source level (older binaries still can use the libraries, but the macro mechanisms used in source are not compatible with those used in OpenSSL 1.0.x, and compilations fail).

This has happened in "our" Python ; our now-current 2.7.12 version does not compile against OpenSSL 1.1. A patch against this version, allowing compilation against OpenSSL 1.1 has been released after the version we used in Trac#19735. I tried to port it in our current version, and failed miserably (someone with more experience than me should have wielded this chainsaw...).

BTW, this has also happened to "our" git, which was easier to upgrade (see Trac#22058, which needs review, BTW).

This is a problem for us because OpenSSL 1.1 has now reached the stage of diffusion in commonly-used distributions (Debian testing, which means the next Ubuntu, etc...). It has been said that this move was (unduly) hastened by a nearing "freeze" in Debian testing ; true or not, the move has happened, and I don't fight the weather... (Interestingly, cygwin still is at openSSL-devel-1.0.2j).

I think that our best bet is the upgrade proposed in Trac#22037, whose development seems to have stopped dead in its tracks after sagemath has hit Debian unstable... This is especially important if we adopt the idea of openly depending on OpenSSL as a solution to I).

III) OpenSSL is problematic on Macintoshes.

 (This is by hearsay : I do not have access to a Mac, and don't really understand the problem ; I'm tryin to summarize what I've read).

Apple seems to have its own SSL implementation, and specific procedures for updating its collection of root certificates. This makes installing a Sage-specific SSL library problematic, and makes necessary a specific procedure fot root certificates maintenance.

1) I do not know if Apple's ssl implementation is sufficient for

a) Sage and related utilities (Sage's pip, Saage's git, etc...)
b) Curl (needed bty R>=3.3, see above).

2) It seems also difficult  to develop an utility making Apple's root certificates usable by Sage.

Qiscussion and questions

In view of these difficulties, what should be done ?

I think that our first priority should be to get a Python that will compile against OpenSSL>=1.1, which will become ubiquitous sooner or later (ant I think it will be sooner...). That means completing Trac#22037 as soon as possible.

In parallel, we should document the SSL problem right at the startof teh README.md and in the developer's documentation (README.md and the Developer's Guide). I will propose a patch to these effect of these docs.

The SSL-using parts of Sage should be reviewed, for answers to three questions :

• do they compile against OpenSSL>1.1 on Linux (and other Unices) ?
• do they compile efficiently (i. e. with full functionality) against Apple's SSL library ?
• will they compile against a future OpenSSL>=1.1 on cygwin ?

Platform-specific adaptations should be considered for both Macs and Windows.

Questions :

• Should we openly depend on OpenSSL ? If so, how to express it ?

I'd vote for that, and for warning of the penalties involved by the non-use of OpenSSL, probably in terms close to those of the Python license.

• Do we need a standard SSL package ?

This is necessary to allow for R>3.3 if we do NOT openly depend on OpenSSL. That's the only way to allow to upgrade to R>3.3, which has become urgent...

• How can we help completing Trac#22037 ?

and, last but not least :

• how can we help with the platform-specific aspects of this thorny problem ?

Your advice, please ?

HTH,

--
Emmanuel Charpentier

[William Stein]

On Sat, Dec 31, 2016 at 5:55 PM, Emmanuel Charpentier
<emanuel.c...@gmail.com> wrote:
> Should we openly depend on OpenSSL ? If so, how to express it ?
>
> I'd vote for that, and for warning of the penalties involved by the non-use
> of OpenSSL, probably in terms close to those of the Python license.

Just to add to what you say, I support openly depending on OpenSSL,
just as Python depends on OpenSSL. It really does seem to be the
only solution to the whole problem that is compatible with the GPL,
the OpenSSL license (https://www.openssl.org/docs/faq.html#LEGAL2),
and Python's current dependence on OpenSSL.

It's also worth thinking about who exactly would complain about our
use of OpenSSL. It's not the OpenSSL devs, and almost nothing in the
Python ecosystem (which is mostly GPL-free). It's the Sage library
itself, and some of our dependencies.

In case you're curious, OpenSSL was a standard package in Sage for a
month or two, around 2007, I think (I added it). Then a student in my
class told me that the OpenSSL license is GPL incompatible (due to a
statement in the openSSL license about advertising materials), and I
was pretty pissed. I then spent a lot of time removing OpenSSL from
Sage, then fully integrating GNUTLS, and all (the many) dependencies
into Sage. For several years, I think, we distributed and built
GNUTLS as a standard package in Sage, and I have many not-fond
memories of dealing with build issues, etc. I also remember some
users considered GNUTLs very second rate regarding security quality
and audit, and *refused* to use it (for fear of being compromised), so
I still had to maintain the ability to build Sage against OpenSSL.
There were also a lot of issues getting sagenb over https to work with
GNUTLS -- I remember patching some Python library, which only
supported OpenSSL. Eventually, and I can't really remember why, I
(or somebody else?) removed GNUTLS from Sage, and we ended up with
what we have now.

Throughout all this, I always wondered whether OpenSSL + Sage is
really GPL incompatible. I believe there is no binary linking between
OpenSSL and any GPL'd component of Sage... except maybe R (?). There
is some question whether it is a GPL violation to distribute Python +
OpenSSL + a GPL'd Python library. I am sooooo not a lawyer.

Now I think the best thing to do regarding this problem is what the
most other people do, which is depend on an existing installed
OpenSSL.

William

> Your advice, please ?
>
> HTH,
>
> --
> Emmanuel Charpentier
>

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



--
William (http://wstein.org)

[Travis Scrimshaw]

My 2 cents, not that I know too much about this, would be to openly make it a listed dependency. I don't know how difficult it would be to maintain this as an optional dependency, but it is something we could either abort or warn the user (with a prompt) should they try installing Sage without OpenSSL.

Best,
Travis

[Kosta]

I know that in linux, one approach that is sometimes taken is having the software download the components "dirty" components separately (e.g. some proprietary drivers and firmware, as well as fonts and codecs). Might it be possible to take a similar approach?

Best,

Kosta

[Emmanuel Charpentier]

A first step towards a solution awaits your comments and review.

Plan :

1. Document OpenSSL dependency, mention the possibility of compiling againts GnuTLS (with drawbacks)
2. Get OpenSSL development libs on the machines producing Unix binary tarballs/packages.
3. (To be discussed) : create a standard "SSL" package serving as a backup, allowing compilation on OpenSSL-less machines. As done for git, this package should do nothing if OpenSSL is installed systemwide.
4. Complete curl as a standard package, which would allow :
5. Upgrade R. Pffeeeewww...

Unsolved problem : What about Macs (I don't have a Mac and can't contribute).

To be discussed : Cygwin (advoce from Erik Bray keenly awaited...).

HTH,

--
Emmanuel Charpentier

[Konstantin Kliakhandler]

Regarding OSX, take a look at ticket 21944 [basically a way to either specify where to find the openssl headers or to use the homebrew headers if available].

The homebrew package can be made to depend on the openssl package. Finally, regarding packaged .app - I don't know. I think it would be reasonable to prompt the user about this issue if the dynamic library is not found. I may be wrong, but I think that in recent years homebrew has become the de-facto package manager and in older OS versions openssl was present, so it would be fairly reasonable to just prompt the user to install homebrew and then install via homebrew.

Cheers,

Kosta

-- 
Konstantin Kliakhandler
    http://slumpy.org
          )°) )°( (°(

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscribe@googlegroups.com.

[Emmanuel Charpentier]

I'm not sure to understand the ticket. Does that means that OS X Sage will depend on Apple's SSL library ? Or depend on a systemwide OpenSSL ? Or am I mistaken entirely ?

--
Emmanuel Charpentier

To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

[Dima Pasechnik]

On Wednesday, January 18, 2017 at 1:20:20 PM UTC, Emmanuel Charpentier wrote:

I'm not sure to understand the ticket. Does that means that OS X Sage will depend on Apple's SSL library ? Or depend on a systemwide OpenSSL ? Or am I mistaken entirely ?

Apple still sneakily ships OpenSSL headers in XCode, for some sort of upgrading tools, I guess.

The location is unstable, though, it chnages from one version of XCode to another :-)

Using homebrew to build Sage on OSX isn't well-explored, IMHO. It might work, given some effort is made.

[Konstantin Kliakhandler]

Right now (pre-ticket) if you try to build sage on OSX Sierra and above, it will be built without

OpenSSL support. I'm not sure what happens if you download a prebuilt package but somehow I assumed

that if you don't have OpenSSL installed, then you can't use OpenSSL (otherwise I don't understand

the whole discussion re GPL/OpenSSL). My comment regarding installing sage via homebrew is with this

in mind, since right now it simply automatically installs the prebuilt package.

The ticket addresses the building issue - it looks for the headers in a user specified location (in an environment variable) if it is defined, and otherwise in the location that homebrew installs to.

-- 
Konstantin Kliakhandler
    http://slumpy.org
          )°) )°( (°(

To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscribe@googlegroups.com.

[Dima Pasechnik]

Are you able to build Sage under/in homebrew?

[Konstantin Kliakhandler]

I'm not sure exactly what you mean; I am able to *install* sage via homebrew - what it does is effectively download the .dmg archive and unpack it in an appropriate location. There is no homebrew package for building sage from source, however. I can (probably) make one if necessary, however.

Konstantin Kliakhandler
Sent on the go

[John H Palmieri]

The question is, if you have homebrew installed, can you build Sage from source? That is, extract the source tarball, type 'make' in the sage directory, and have it complete successfully. I think the motivation behind the question is, in the past, the presence of fink or macports prevented Sage from building correctly, so it is natural to wonder what happens with homebrew.

  John

[Konstantin Kliakhandler]

Ah, I misunderstood the question. AFAICT homebrew does not adversely affect the sage built. In particular, I was able to successfully build it several times with 7.5.betaX 7.5.rcX and 7.5, on two separate machines (on which I also have HB installed).

-- 
Konstantin Kliakhandler
    http://slumpy.org
          )°) )°( (°(

To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscribe@googlegroups.com.

[François Bissey]

It depend what compilers are exposed. Last time someone filled
a bug, gfortran from brew was interfering with the gfortran sage
installs. https://trac.sagemath.org/ticket/22112

Francois

On 25/01/17 11:46, Konstantin Kliakhandler wrote:
> Ah, I misunderstood the question. AFAICT homebrew does not adversely
> affect the sage built. In particular, I was able to successfully build
> it several times with 7.5.betaX 7.5.rcX and 7.5, on two separate
> machines (on which I also have HB installed).
>
> --
> Konstantin Kliakhandler
> http://slumpy.org
> )°) )°( (°(
>
> On 25 January 2017 at 00:42, John H Palmieri <jhpalm...@gmail.com

> <https://trac.sagemath.org/ticket/21944> [basically

> a way to either specify where to find the
> openssl headers or to use the homebrew
> headers if available].
>
> The homebrew package can be made to depend
> on the openssl package. Finally, regarding
> packaged .app - I don't know. I think it
> would be reasonable to prompt the user about
> this issue if the dynamic library is not
> found. I may be wrong, but I think that in
> recent years homebrew has become the
> de-facto package manager and in older OS
> versions openssl was present, so it would be
> fairly reasonable to just prompt the user to
> install homebrew and then install via homebrew.
>
> Cheers,
> Kosta
>
> --
> Konstantin Kliakhandler
> http://slumpy.org
> )°) )°( (°(
>
> On 15 January 2017 at 15:51, Emmanuel
> Charpentier <emanuel.c...@gmail.com> wrote:
>
> A first step

> <https://trac.sagemath.org/ticket/22058>

> towards a solution awaits your comments
> and review.
>
> Plan :
>

> 1. Document OpenSSL dependency, mention

> the possibility of compiling againts
> GnuTLS (with drawbacks)

> 2. Get OpenSSL development libs on the

> machines producing Unix binary
> tarballs/packages.

> 3. (To be discussed) : create a

> standard "SSL" package serving as a
> backup, allowing compilation on
> OpenSSL-less machines. As done for
> git, this package should do nothing
> if OpenSSL is installed systemwide.

> 4. Complete curl as a standard package,
> which would allow :
> 5. Upgrade R. Pffeeeewww...

>
> Unsolved problem : What about Macs (I
> don't have a Mac and can't contribute).
>
> To be discussed : Cygwin (advoce from
> Erik Bray keenly awaited...).
>
> HTH,
>
> --
> Emmanuel Charpentier
>
> Le dimanche 1 janvier 2017 02:55:42
> UTC+1, Emmanuel Charpentier a écrit :
>
> Dear list,
>
> We have three separate, but
> interacting, difficulties with
> SSL/TLS support in Sage. I'll
> summarize the results of the efforts
> of several people who tracked them,
> and propose a couple of solutions.
>

> _I) Python now (discreetly) depends
> on Open SSL._
>
> Their license page
> <https://docs.python.org/3/license.html>
> states :
>
> The modules |hashlib|
> <https://docs.python.org/3/library/hashlib-blake2.html#module-hashlib>,
> |posix|
> <https://docs.python.org/3/library/posix.html#module-posix>,
> |ssl|
> <https://docs.python.org/3/library/ssl.html#module-ssl>,
> |crypt|
> <https://docs.python.org/3/library/crypt.html#module-crypt>

> use the OpenSSL library for
> added performance if made
> available by the operating
> system. Additionally, the
> Windows and Mac OS X installers
> for Python may include a copy of
> the OpenSSL libraries, so we
> include a copy of the OpenSSL
> license here:
>
> followed by the bizarre OpenSSL
> license. For our purpose, the

> important statement is *"use the

> OpenSSL library for added
> performance if made available by the

> operating system."*.

>
> "Added performance, my a^htired foot
> : Thierry has checked the
> possibilities of an OpenSSL-less
> Sage, and I have further checked
> other possibilities. Our trials
> conclusively demonstrate that Gnu
> TLS can't be substituted to OpenSSL
> for at least the following reasons :
>

> * Sage's pip is non-functionnal

> when compiled against Gnu TLS

> * Ditto for Sage's git
> * I understand (but have not

> checked) that Python's hashlib
> module, which depends on
> openssl, is used in Sage.
>
>
> However, contrary to my

> expectations, R 3.3.2 *can* be

> compiled in Sage against a curl
> library using Gnu TLS and keep a
> functional HTTPS access to R
> repositories.
>
> Consequences :
>

> * Sage *can*be built and run

> without OpenSSL support, (as
> long as R is < 3.3 or some SSL
> support is available for R >=
> 3.3), but this system will have
> severe limitations (among
> others, no access to pip
> resources, questionable support
> for Sage's git).

> * OpenSSL can be retrofitted in

> such a system by installing the
> openssl package, but this
> retrofit becomes effective after
> recompilation of python2 (at least).
>
> This latter "solution" is, at best,
> a contraption (even if something in
> this direction has been proposed

> <https://groups.google.com/d/msg/sage-devel/iwrF8_kGLzM/aze9lJi8nm8J>

> back in 2012 to solve the very same
> problem). Therefore :
>

> * we *must at minimum* advertise

> this problem in the REAME.md
> file and recommend checking the
> presence of OpenSSL, and
> recommend the installation of
> openssl development files for
> Sage compilation. In this case,
> we would have to :

> o provide a standard package

> providing some HTTPS-capable
> SSL support. Ideally, this
> package should be able to
> check for the presence of
> suitable systemwide
> libraries, and in this case,
> do nothing ;

> o use this SSL support to

> provide an HTP-enabled curl
> for R>=3.3 (with again, the
> possibility of usinf a
> systemwide curl library).

> * We *should* acknowledge our /de
> facto/ dependence on a

> systemwide OpenSSL (in terms
> close to those used by the
> Python license). In this case,
> we would have to provide a
> standard curl package, with the
> same provisions as before.
>
> The first solution, used on a system
> without OpenSSL, will create a
> crippled Sage. Furthermore, it needs
> writing two standard packages,
> installing widely-diffused utilities
> (it seems awfully difficult to

> install a Debian system /sans/

> OpenSSL : even a freshly installed
> "base system + common utilities" has
> openssl, on which Debian's reportbug
> and various utilities depend).
>
> I would rather acknowledge our
> dependence on OpenSSL, recommend its
> installation and advertise the
> limitations of an OpenSSL-less Sage,
> leaving this possibility open to
> prudes...
>

> _II) OpenSSL has broken a lot of
> software._

>
> OpenSSL 1.1.0 has broken a lot of

> OpenSSL-using software *at the
> source level* (older binaries still

> can use the libraries, but the macro
> mechanisms used in source are not
> compatible with those used in
> OpenSSL 1.0.x, and compilations fail).
>
> This has happened in "our" Python ;
> our now-current 2.7.12 version does
> not compile against OpenSSL 1.1. A
> patch against this version, allowing
> compilation against OpenSSL 1.1 has
> been released after the version we
> used in Trac#19735

> <https://trac.sagemath.org/ticket/19735>.
> I tried
> <https://trac.sagemath.org/ticket/22089>

> to port it in our current version,
> and failed miserably (someone with
> more experience than me should have
> wielded this chainsaw...).
>
> BTW, this has also happened to "our"
> git, which was easier to upgrade
> (see Trac#22058

> <https://trac.sagemath.org/ticket/22058>,
> which needs review, BTW).
>
> This *is* a problem for us because

> OpenSSL 1.1 has now reached the
> stage of diffusion in commonly-used
> distributions (Debian testing, which
> means the next Ubuntu, etc...). It
> has been said that this move was
> (unduly) hastened by a nearing
> "freeze" in Debian testing ; true or
> not, the move has happened, and I
> don't fight the weather...
> (Interestingly, cygwin still is at
> openSSL-devel-1.0.2j).
>
> I think that our best bet is the
> upgrade proposed in Trac#22037

> <https://trac.sagemath.org/ticket/22037>,

> whose development seems to have
> stopped dead in its tracks after
> sagemath has hit Debian unstable...
> This is especially important if we
> adopt the idea of openly depending
> on OpenSSL as a solution to I).
>

> _III) OpenSSL is problematic on
> Macintoshes._

>
> (This is by hearsay : I do not have
> access to a Mac, and don't really
> understand the problem ; I'm tryin
> to summarize what I've read).
>
> Apple seems to have its own SSL
> implementation, and specific
> procedures for updating its
> collection of root certificates.
> This makes installing a
> Sage-specific SSL library
> problematic, and makes necessary a
> specific procedure fot root
> certificates maintenance.
>
> 1) I do not know if Apple's ssl
> implementation is sufficient for
> a) Sage and related utilities
> (Sage's pip, Saage's git, etc...)
> b) Curl (needed bty R>=3.3, see above).
>
> 2) It seems also difficult to
> develop an utility making Apple's
> root certificates usable by Sage.
>

> _Qiscussion and questions_

>
> In view of these difficulties, what
> should be done ?
>
> I think that our first priority
> should be to get a Python that will
> compile against OpenSSL>=1.1, which
> will become ubiquitous sooner or
> later (ant I think it will be
> sooner...). That means completing
> Trac#22037

> <https://trac.sagemath.org/ticket/22037>

> as soon as possible.
>
> In parallel, we should document the
> SSL problem right at the startof teh
> README.md and in the developer's
> documentation (README.md and the
> Developer's Guide). I will propose a
> patch to these effect of these docs.
>
> The SSL-using parts of Sage should
> be reviewed, for answers to three
> questions :
>

> * do they compile against

> OpenSSL>1.1 on Linux (and other
> Unices) ?

> * do they compile efficiently (i.

> e. with full functionality)
> against Apple's SSL library ?

> * will they compile against a

> future OpenSSL>=1.1 on cygwin ?
>
>
> Platform-specific adaptations should
> be considered for both Macs and Windows.
>
> Questions :
>

> * Should we openly depend on

> OpenSSL ? If so, how to express it ?
>
> I'd vote for that, and for warning
> of the penalties involved by the
> non-use of OpenSSL, probably in
> terms close to those of the Python
> license.
>

> * Do we need a standard SSL package ?

>
> This is necessary to allow for R>3.3
> if we do NOT openly depend on
> OpenSSL. That's the only way to
> allow to upgrade to R>3.3, which has
> become urgent...
>

> * How can we help completing
> Trac#22037 ?
> <https://trac.sagemath.org/ticket/22037>

>
> and, last but not least :
>

> * how can we help with the

> platform-specific aspects of
> this thorny problem ?
>
> Your advice, please ?
>
> HTH,
>
> --
> Emmanuel Charpentier
>
> --
> You received this message because you
> are subscribed to a topic in the Google
> Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe

> <https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe>.

> To unsubscribe from this group and all
> its topics, send an email to
> sage-devel+...@googlegroups.com.
> To post to this group, send email to
> sage-...@googlegroups.com.
> Visit this group at
> https://groups.google.com/group/sage-devel

> <https://groups.google.com/group/sage-devel>.

> For more options, visit
> https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed
> to a topic in the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe

> <https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe>.

> To unsubscribe from this group and all its topics,
> send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to
> sage-...@googlegroups.com.
> Visit this group at
> https://groups.google.com/group/sage-devel

> <https://groups.google.com/group/sage-devel>.

> For more options, visit
> https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to a
> topic in the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe

> <https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe>.

> To unsubscribe from this group and all its topics, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at
> https://groups.google.com/group/sage-devel

> <https://groups.google.com/group/sage-devel>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
>
>
> Konstantin Kliakhandler
> Sent on the go
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe

> <https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to
> sage-devel+...@googlegroups.com

> <mailto:sage-devel+...@googlegroups.com>.

> To post to this group, send email to sage-...@googlegroups.com

> <mailto:sage-...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/sage-devel

> <https://groups.google.com/group/sage-devel>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+...@googlegroups.com

> <mailto:sage-devel+...@googlegroups.com>.

> To post to this group, send email to sage-...@googlegroups.com

> <mailto:sage-...@googlegroups.com>.

[Konstantin Kliakhandler]

That may be true, but IMHO this is already a specific issue of incompatibility with a specific package, rather than a systemic incompatibility with HB itself (e.g. as would be the case if HB relied on said version of gfortran). I see it as no different than a situation where the user installed gfortran manually somehow and it interfered with Sage's.

Also, if there will be a build-from-source variant in HB (which I am happy to write if there is the demand), it can easily mark what packages it is incompatible with.

-- 
Konstantin Kliakhandler
    http://slumpy.org
          )°) )°( (°(

    sage-devel+unsubscribe@googlegroups.com
    <mailto:sage-devel+unsubscribe@googlegroups.com>.

    To post to this group, send email to sage-...@googlegroups.com

    <mailto:sage-devel@googlegroups.com>.

    Visit this group at https://groups.google.com/group/sage-devel
    <https://groups.google.com/group/sage-devel>.
    For more options, visit https://groups.google.com/d/optout
    <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+unsubscribe@googlegroups.com
<mailto:sage-devel+unsubscribe@googlegroups.com>.

To post to this group, send email to sage-...@googlegroups.com

<mailto: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 a topic in the Google Groups "sage-devel" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscribe@googlegroups.com.

To post to this group, send email to sage-...@googlegroups.com.

[Konstantin Kliakhandler]

P.S.

I looked at the ticket now. I don't know exactly what was wrong on their end, but I have homebrew gcc (6.3.0) installed, including gfortran, and it did not break my build, as far as I can tell (at the very least, it was successfully built and runs fine the simple stuff I usually use it for).

-- 
Konstantin Kliakhandler
    http://slumpy.org
          )°) )°( (°(

    sage-devel+unsubscribe@googlegroups.com
    <mailto:sage-devel+unsubscribe@googlegroups.com>.

    To post to this group, send email to sage-...@googlegroups.com

    <mailto:sage-devel@googlegroups.com>.

    Visit this group at https://groups.google.com/group/sage-devel
    <https://groups.google.com/group/sage-devel>.
    For more options, visit https://groups.google.com/d/optout
    <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+unsubscribe@googlegroups.com
<mailto:sage-devel+unsubscribe@googlegroups.com>.

To post to this group, send email to sage-...@googlegroups.com

<mailto: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 a topic in the Google Groups "sage-devel" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/jdLfIKQ1M18/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscribe@googlegroups.com.

To post to this group, send email to sage-...@googlegroups.com.

[Dima Pasechnik]

surely people would not mind a HB based way to build Sage. Long ago HB was a pain,due to linking to wrong libs all the time. Since then Sage switch to using rpath, and it is much more robust in this sense.