[gnutls-devel] [PATCH] Fix library build on Chrome Native Client (NaCl)

[Nikos Mavrogiannopoulos]

On Tue, Apr 19, 2016 at 2:05 AM, Kevin Cernekee <cernekee at gmail.com> wrote:
> On Mon, Apr 18, 2016 at 6:27 AM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> Hi Kevin,
>>  (1) is very tricky. If we go that path the implicit initialization of
>> the library goes away. Is there some way to avoid it? E.g., can we
>> rely on getrandom() does nacl support it?
>
> It isn't currently supported, but I can propose adding it to
> libnacl_io if we know that GnuTLS won't actually call it until the app
> calls a GnuTLS function.  In that sense it would have the same
> restrictions as file operations, but since _rnd_system_entropy_init()
> doesn't perform any I/O, it avoids the initial problem.
> Would that work?

It would, no randomness is needed at the constructor. Only
initialization happens and getrandom() doesn't require that. A simple
getrandom() on kernels that don't support it could be implemented by
opening reading and closing /dev/unrandom. That could also be part of
gnutls with a special compilation option, but I don't quite like
having many options as they will pretty much be untested.

> Checking to see if there are other things happening in the library
> constructor that require libnacl_io: there are a few calls to open
> /dev/crypto, FIPS related files, etc.  The open() calls will return
> ENOSYS prior to initialization, which should be fine for those.  Can
> you think of any other dependencies?

I don't believe there are any other.