Build break for gcc 4.4.5.
Created attachment 81924 [details] Proposed patch use return value of read in both debug and release modes.
Comment on attachment 81924 [details] Proposed patch Why not just use the CRASH() version in both debug and release? A quick web search suggests that reads from /dev/urandom never fails in practice, just possibly degrading quality (not sure if there's a proper spec for this). I'm wondering if one Web page will be able to predict random numbers generated in other pages by exhausting OS randomness first.
(In reply to comment #2) > (From update of attachment 81924 [details]) > Why not just use the CRASH() version in both debug and release? > Yeah I suppose I could. I don't ever predict /dev/urandom to fail to provide the exact number of requested bytes. I'll revise. > A quick web search suggests that reads from /dev/urandom never fails in practice, just possibly degrading quality (not sure if there's a proper spec for this). I'm wondering if one Web page will be able to predict random numbers generated in other pages by exhausting OS randomness first. Good thought. May want to hit up the Chromium team who added this :)
Created attachment 81934 [details] Proposed patch
Comment on attachment 81934 [details] Proposed patch Clearing flags on attachment: 81934 Committed r78203: <http://trac.webkit.org/changeset/78203>
All reviewed patches have been landed. Closing bug.
*** Bug 54190 has been marked as a duplicate of this bug. ***
Adam, I'm still curious about your thoughts on the issue of Web content abusing randomness source, and thus affecting other pages (and even other processes?!). Is there a rate limit or some other protection against that?
(In reply to comment #8) > Adam, I'm still curious about your thoughts on the issue of Web content abusing randomness source, and thus affecting other pages (and even other processes?!). Is there a rate limit or some other protection against that? Access to OS randomness is mediated by a cryptographic PRNG in WTF. There shouldn't be a problem with sharing the crypto PRNG with other web pages. If there was, that would be an attack on RC4, and we'd have bigger problems! Now, there's the question of whether it's dangerous to let web pages pull from OS randomness, even mediated by a PRNG. I don't think that's overly dangerous. In many common scenarios, web pages can already pull from OS randomness. For example, the <keygen> element lets you generate certificates, which requires a bunch of OS randomness. As another example, WTF::randomNumber backends to arc4random on Mac, which backends to /dev/urandom. To the extent that web pages can cause WebKit to call WTF::randomNumber, they can already convince us to extract randomness from the OS.
> Now, there's the question of whether it's dangerous to let web pages pull from OS randomness, even mediated by a PRNG. Yes, that's my concern. Perhaps this hasn't been exploited yet, but it seems likely to be exploitable.