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

Michael Niedermayer michaelni at gmx.at
Wed Dec 9 14:54:26 CET 2015


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.
That said, i would be quite interrested in any statistical or
security flaws in its output (if all platform specific high quality
functions are disabled)

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/cca2a3de/attachment.sig>


More information about the ffmpeg-devel mailing list