[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Petch
Subject: [Bug-gnubg] Serious bug: Random.org - Important Request for Comments
Date: Tue, 13 Jan 2015 11:17:20 -0700
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Today this bug appeared on our tracking system

"Of late the programme picks up the same old dice numbers and not random
eg: w 3.1, b4.1, w2.2, b6.2.... This does not give confidence on
'cheating' its hard enough to win anyway!
The same applies on my laptop win 8.1 64 bit.
Any thoughts on how to regenerate true random numbers apart from manual

I have confirmed that this is the case. I quickly discovered that we
don't retrieve values from Random.org anymore because of a permanent URL
redirect that requires https rather than http. We don't support 'https',
just 'http' . It appears we quietly fall back to a PRNG with a fixed
seed (so the values generated always seem to be the same). We should
probably be a bit smarter about falling back to a PRNG and probably let
the user know.

The primary issue is that we now have to support https. This is non
trivial if we roll our own. My request for comments is regarding how we
should go about resolving this. The first thing that I am considering is
using libcurl: http://curl.haxx.se/libcurl/

It is file transfer protocol that supports a variety of internet
protocols including http and https. The the TLS support can come from a
number of backend libraries such as OpenSSL and GNUtls.One other things
is that libcurl handles things like HTTP redirects etc.

The downside is that we add some more dependencies to GNUbg. We'll
require libcurl(and anything it depends on) if a user wants Random.org
support . We'd have to check for libcurl (and that it support SSL)
during the ./configure process.

There are some potential licensing issues with libcurl. It primarily has
to do with releasing binaries that use OpenSSL for TLS on the back end
when linked with GPL code. There is one possible solution. Use GNUtls as
a back end. Unfortunately it may be (and I have to look into it) the
Windows (MingW builds) and/or OS/X may be using OpenSSL. Whether they
can be easily changed I can't say. Projects like 'wget' have been using
a special exemption to deal with this in their license:

"In addition, as a special exception, the Free Software Foundation gives
permission to link the code of its release of Wget with the OpenSSL
project's "OpenSSL" library (or with modified versions of it that use
the same license as the "OpenSSL" library), and distribute the linked
executables. You must obey the GNU General Public License in all
respects for all of the code used other than "OpenSSL". If you modify
this file, you may extend this exception to your version of the file,
but you are not obligated to do so. If you do not wish to do so, delete
this exception statement from your version."

Does anyone have any other suggestions (beyond libcurl) or have any
comments on this issue in general? I'd like to hear them before I look
at producing a fix.

Michael Petch
GNU Backgammon Maintainer / Developer
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304

reply via email to

[Prev in Thread] Current Thread [Next in Thread]