Bug#754513: Questions from upstream
On Jul 21, 2014, at 7:31 AM, Steven Chamberlain <steven@pyro.eu.org> wrote:
> Hi Brent,
>
> Thank you very much for your input here.
>
> On 21/07/14 13:10, Brent Cook wrote:
>> Also, please do not replace arc4random in libressl. We'll have to figure
>> out what to do about the circular dependency with openssh
>
> OK, let's see what the OpenSSH Portable team comes up with...
>
> Having embedded copies of arc4random.c in different packages though
> (libressl, openssh, libevent, libbsd) is not great. It would be nice to
> someday package it into a re-usable library for all of Debian to use,
> and for ensuring it always stays up-to-date with upstream.
>
> (The one in LibreSSL Portable is currently the most up-to-date; I
> realise other/older versions of it are unsafe for some use cases).
>
>> replacing
>> with the version from libbsd is really not the way to go at the moment
>
> Agreed, there are serious problems with the arc4random in libbsd at the
> moment (I'm looking at our options to fix this). But if we could
> someday split out arc4random, then libbsd would seem like a good place
> to put it.
OK. Someone, whom I think is a libbsd maintainer, expressed interest in updating libbsd as well:
https://github.com/busterb/libressl/issues/5
In the short term, we are doing some refactoring to make arc4random even more portable in LibreSSL, and will be adding support for the new Linux getrandom syscall if/when it lands as well.
I wonder if libc integration would be the best integration path, since not everything that integrates arc4random/arc4random_buf uses an external library to provide that functionality. Take libevent2, which also embeds its own implementation if the system does not have it.
If there was a secure arc4random implementation that all apps could use on Linux without any special libraries, that would kill a few birds with one stone.
> Regards,
> --
> Steven Chamberlain
> steven@pyro.eu.org
Reply to: