On Wed, Dec 9, 2015 at 11:00 AM, wm4 <nfx...@googlemail.com> wrote: > On Wed, 9 Dec 2015 09:39:47 -0500 > Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > >> On Wed, Dec 9, 2015 at 8:28 AM, wm4 <nfx...@googlemail.com> wrote: >> > On Tue, 8 Dec 2015 09:01:47 -0500 >> > 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. >> >> >> >> 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 > > So what, we do that too? Just because libbsd accumulated a shitload of > hacks it doesn't mean we have to use it, neither does it have to mean > it's "better".
libbsd uses a "shitload of hacks" because there is no portable way of generating good random number seeds efficiently and of good quality. The documentation states that FFmpeg makes a best effort for providing a good random number seed. By best effort, I define it along the dimensions of seed quality and speed. libbsd provides improvements along one axis for FFmpeg, keeps the other axis fixed afaik, and so I still consider the change worthy. I can't speak for your definition of "better", which you have not clarified. > > Anyway, I'm strictly against making FFmpeg depend on a BSD > compatibility library, even optionally. It makes no sense. I'm out of > here. I request a review for 1/2. You have a tendency to have strong reactions regarding hacks and/or external dependencies for things, as long as it is not mpv. I thus also request a second opinion on this. > >> 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. >> >> I am now 90-10 for 2/2. >> >> > _______________________________________________ >> > ffmpeg-devel mailing list >> > ffmpeg-devel@ffmpeg.org >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
