On Wed, Dec 09, 2015 at 09:16:34AM -0500, Ganesh Ajjanagadde wrote: > On Wed, Dec 9, 2015 at 8:54 AM, Michael Niedermayer <michae...@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 <gajja...@mit.edu> > >> wrote: > >> > On Tue, Dec 8, 2015 at 8:16 AM, Clément Bœsch <u...@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 <nfx...@googlemail.com> wrote: > >> >>> > On Sun, 6 Dec 2015 22:56:33 -0500 > >> >>> > Ganesh Ajjanagadde <gajjanaga...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
