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

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 09:39:47AM -0500, Ganesh Ajjanagadde wrote:
> 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?)
> 
> I looked at the libbsd code right now. Strictly speaking, you are
> right, but it falls back to time of day only on very rare platforms.
> In particular, it uses /dev/urandom when available. Thus, it turns out
> that using it over /dev/urandom should actually be a Pareto
> improvement (ref: getentropy in _rs_stir). Or more generally, using it

> when available via --enable-libbsd will never lower FFmpeg's random
> seeding quality.

how does it use time of day to create a seed and on what platform ?


> 
> I am now 90-10 for 2/2.
> 
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151209/77d71b17/attachment.sig>