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

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 09:16:34AM -0500, Ganesh Ajjanagadde wrote:
> On Wed, Dec 9, 2015 at 8:54 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Tue, Dec 08, 2015 at 09:12:42AM -0500, Ganesh Ajjanagadde wrote:
> >> On Tue, Dec 8, 2015 at 9:01 AM, 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.
> >>
> >> To clarify above: the seed is not meant for security anyway, since if
> >> that was the case FFmpeg's seeding is fundamentally broken, falling
> >> down to time is not safe. But this is clarified in the docs.
> >
> > its not intended for security no, but its also not intended to be
> > intentionally insecure.
> 
> arc4random is not intentionally insecure; else the API has defeated
> its own purpose.

I was just talking about the random_seed code as is, that wasnt a
comment about arc4random :)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/3605c93c/attachment.sig>