[FFmpeg-devel] [PATCH 2/2] configure: libbsd support for arc4random()

[wm4]

On Tue, 8 Dec 2015 09:01:47 -0500
Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:

> On Tue, Dec 8, 2015 at 8:16 AM, Clément Bœsch <u at pkh.me> wrote:
> > On Tue, Dec 08, 2015 at 07:34:51AM -0500, Ganesh Ajjanagadde wrote:  
> >> On Tue, Dec 8, 2015 at 7:27 AM, wm4 <nfxjfg at googlemail.com> wrote:  
> >> > On Sun,  6 Dec 2015 22:56:33 -0500
> >> > Ganesh Ajjanagadde <gajjanagadde at gmail.com> wrote:
> >> >  
> >> >> On non-BSD machines, there exists a package libbsd for providing BSD
> >> >> functionality. This can be used to get support for arc4random.
> >> >>
> >> >> Thus, an opt-in --enable-libbsd is added to configure for this
> >> >> functionality.
> >> >>
> >> >> Tested on GNU/Linux.
> >> >>  
> >> >
> >> > This doesn't seem worth the trouble at all. Who is even going to use
> >> > it, and why, and what additional hidden bugs will it cause?  
> >>
> >> arc4random is a far superior interface, in that it can never fail. See
> >> http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt for
> >> details.
> >> As for hidden bugs, apart from configuration/detection issues, I see none.
> >> If anything, it is easier to use /dev/urandom incorrectly.
> >> Ultimately any code change is a tradeoff, with different people
> >> feeling differently about various things.
> >> I still feel that it is worth inclusion due to its technical merits.
> >>  
> >
> > Note that the behaviour of arc4random differs between implementations.
> >
> > http://insanecoding.blogspot.gr/2014/05/libressl-porting-update.html  
> 
> That is for libressl, not libbsd, though the remark may still apply.
> And there is no real fundamental issue: FFmpeg's seeding code anyway
> varies between platforms, in the worst case using time.
> 
> Second, a getrandom system call has been added to the kernel, so
> libbsd/libressl should upgrade to the new interface over time.
> 
> Whatever, if people don't want this, I will drop 2/2 but keep within
> my own tree for a future date potentially.
> 
> 1/2 is still very much worthwhile: platforms supporting natively
> arc4random should use it (e.g the BSD's).

You should wait until glibc supports the getrandom syscall, instead of
using a wrapper lib that is merely meant to make porting BSD programs
simpler. (Looking at libbsd, it does try to use the getrandom syscall,
but also tries potentially dangerous fallbacks like using the system
time as random seed? Isn't that exactly the wrong thing if you want
100% correctness?)