On Sat, Oct 14, 2017 at 10:00 AM, Ingo Schwarze <schwa...@usta.de> wrote: ...
> RTFS is all well and good, but trying to understand your postings, > i also tried to RTFM. > > schwarze@isnote $ man urandom > man: No entry for urandom in the manual. > > This is ungood. > > So i looked at random(4) and found multiple issues. > > * srandom and urandom are missing from NAME. That's particularly > unfortunate for urandom(4) because that's the best of the four > for portable software, IIUC. > I'm okay with adding urandom for the portability reason. I'm less inclined to add srandom: how many years have to pass before we stop documenting it? Does the timer only start when we remove the /dev entry? > * I think we want a strong deprecation notice here, like for > crypt(3). We usually put that at the top of the DESCRIPTION, > such that people won't study all the text before realizing > that they have to start over with a different page. > * Given that these devices are only useful for (some situations) > of portable code, it seems quite counter-productive to only talk > about what OpenBSD does, and the failure to make clear which > of the statements apply to OpenBSD only is even worse. > * It should certainly be said that if at all, urandom(4) > is the one to use. > * There is no need to say twice that these devices produce > high-quality random data. > * Add the missing FILES entries. > * Kill the reference to the deprecated random(3) APIs. > * We don't need to get into the argument whether Linux is an > operating system or just a kernel. Instead, we usually mention > the release something first appeared in. But i'm too lazy to > research Linux kernel version numbers, and maybe they are not > even all that interesting, so i'm just putting the year. > * Author names belong in AUTHORS, not HISTORY. Instead, > HISTORY should say when ARC4 was introduced here. > I agree with all the above. > * It's weird to mention who implemented a former algorithm, > but to not say the same for the current one. > I'm pondering whether and why the switch to arc4random stands out. Was that the "it doesn't have to be slow, duh!" moment? If so, it deserves to be called out for that aspect with the use of arc4 as a "and here's how" side note. This patch in likely not perfect yet, there is more weirdness, > but i don't know the best way to fix that. If this is a bad > patch, i hope it triggers a good one. > > * Are the .Xr's to md5(3) and md5(9) still relevant? How does > reading md5(3) and md5(9) potentially help somebody who is > considering to use /dev/urandom? I'd like to delete these, > but if we want to keep them, shouldn't we explain why they > are relevant? > Kill'em. I think they're only there because md5 was used before arc4. > * I strongly suspect the sentence "This is a cloned interface" > is completely misplaced in HISTORY. But i'm not quite sure > what it means and whether it is true, so i have no idea > where to move it. > IMO, delete it. random(4) isn't a cloning device in the D_CLONE sense in the kernel: multiple opens are indistinguishable. Even reviewing the commit where the text was added doesn't really clarify for me what that was intended to indicate. > Feedback? Or even an OK? > Other than my hesitance about add ".Nm srandom", this diff appears to be an improvement to me. IMO, ok guenther@ and we'll refine it further. Philip Guenther
