Re: [Bug-gnubg] Serious bug: Random.org - Important Request for Comments

[Dan Fandrich]

On Tue, Jan 13, 2015 at 01:21:56PM -0700, Michael Petch wrote:
> On 2015-01-13 1:11 PM, Dan Fandrich wrote:
> > An end
> > user compiling his own gnubg doesn't even need to concern himself with the
> > license of the SSL library (as long as he doesn't redistribute the code) 
> > while
> > packagers can choose one of a number of SSL back-ends compatible with
> > distribution.
> 
> Please read what I said " It primarily has
> to do with RELEASING BINARIES that use OpenSSL for TLS on the back end
> when linked with GPL code"

I'm aware—binaries are what packagers release, after all.

> The problem is that GNUbg does official binary builds for Windows and
> OS/X. So this issue directly impacts our production of binaries. I am
> well aware that the issue isn't one that concerns those who build from
> source themselves.

That makes your job even easier, since you you're not even dependent on which
SSL libraries are available on the platforms you're targeting.

> The MingW environment I use doesn't even have GnuTLS as a package. So I
> happened to build Nettle (and had libgmp installed) and wouldn't you
> know it the GNUtls build fails (and apparently I'm not alone with that
> issue)
> 
> So I'll have to find a back end that actually will work under MingW. It
> just so happens that OpenSSL just works on Msys/Mingw which is why it
> would have been convenient.

CyaSSL and PolarSSL are two that seem to support MinGW, and are fairly
lightweight and self-contained (read: easier to compile than OpenSSL), too.

> So it is worthy to at least note that supporting Random.org will require
> new dependencies and that should be communicated to the downstream
> maintainers. So your view that it really is a non issue is not one I
> agree with.

It's definitely worth documenting.  My view is only that the OpenSSL license
is a non-issue when developing an app using libcurl.

>>> Dan