[src/netbsd-6]: src/doc ticket #859

[msaitoh <msaitoh%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/8b91a1ddc8c7
branches:  netbsd-6
changeset: 775740:8b91a1ddc8c7
user:      msaitoh <msaitoh%NetBSD.org@localhost>
date:      Fri Mar 29 00:50:32 2013 +0000

description:
ticket #859

diffstat:

 doc/CHANGES-6.1 |  20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diffs (31 lines):

diff -r add10e72e4b1 -r 8b91a1ddc8c7 doc/CHANGES-6.1
--- a/doc/CHANGES-6.1   Fri Mar 29 00:44:28 2013 +0000
+++ b/doc/CHANGES-6.1   Fri Mar 29 00:50:32 2013 +0000
@@ -1,4 +1,4 @@
-# $NetBSD: CHANGES-6.1,v 1.1.2.113 2013/03/15 23:26:27 riz Exp $
+# $NetBSD: CHANGES-6.1,v 1.1.2.114 2013/03/29 00:50:32 msaitoh Exp $
 
 A complete list of changes from the 6.0 release until the 6.1 release:
 
@@ -8730,3 +8730,21 @@
        Welcome to 6.1_RC2!
        [riz]
 
+sys/kern/subr_cprng.c                          1.16
+
+       Re-fix 'fix' for SA-2013-003.  Because the original fix evaluated a
+       flag backwards, in low-entropy conditions there was a time interval
+       in which /dev/urandom could still output bits on an unacceptably
+       short key.  Output from /dev/random was *NOT* impacted.
+
+       Eliminate the flag in question -- it's safest to always fill the
+       requested key buffer with output from the entropy-pool, even if we
+       let the caller know we couldn't provide bytes with the full entropy
+       it requested.
+
+       Advisory will be updated soon with a full worst-case analysis of the
+       /dev/urandom output path in the presence of either variant of the
+       SA-2013-003 bug.  Fortunately, because a large amount of other input
+       is mixed in before users can obtain any output, it doesn't look as
+       dangerous in practice as I'd feared it might be.
+       [tls, ticket #859]