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

[Ganesh Ajjanagadde]

On Wed, Dec 9, 2015 at 8:28 AM, wm4 <nfxjfg at googlemail.com> wrote:
> 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?)

First off, it is not clear at all what one means by 100% correctness,
since it depends on what environment this will operate in (security vs
speed). I operated under the assumption that it is not security
critical, an assumption that is reasonable given the current API. For
instance, if it was security critical, we should have error'ed in some
way (at the very least a message) when the insecure get_generic_seed
fallback is used.

Anyway, Michael has clarified it.

I was mainly interested in a fast way to get a good random seed, and
there is no native, high-level interface on Linux ATM. The main
benefit (and my main motivation) is that this can't fail. I don't know
the internals of /dev/urandom, but it may be subject to some error
paths that open calls are subject to.

TL;DR: I still feel (at a 70 for, 30 against) that 2/2 is reasonable.
This may be argued endlesslessly (even /dev/urandom vs /dev/random
generates debate in 2015 with a lot of FUD out there
(https://news.ycombinator.com/item?id=10149019), and so I may shelve
it (and hence also the original "controversial" label).
The main (unambiguous) change is patch 1/2, which still lacks a
review. Let us focus efforts on that patch.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel