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

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

details:   https://anonhg.NetBSD.org/src/rev/c6585438ac53
branches:  netbsd-6-0
changeset: 774783:c6585438ac53
user:      msaitoh <msaitoh%NetBSD.org@localhost>
date:      Fri Mar 29 00:52:23 2013 +0000

description:
ticket #859

diffstat:

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

diffs (31 lines):

diff -r 79782ae22f79 -r c6585438ac53 doc/CHANGES-6.0.2
--- a/doc/CHANGES-6.0.2 Fri Mar 29 00:46:58 2013 +0000
+++ b/doc/CHANGES-6.0.2 Fri Mar 29 00:52:23 2013 +0000
@@ -1,4 +1,4 @@
-# $NetBSD: CHANGES-6.0.2,v 1.1.2.24 2013/03/15 18:52:53 riz Exp $
+# $NetBSD: CHANGES-6.0.2,v 1.1.2.25 2013/03/29 00:52:23 msaitoh Exp $
 
 A complete list of changes from the NetBSD 6.0.1 release to the NetBSD 6.0.2
 release:
@@ -169,3 +169,21 @@
        such as those in /rescue.
        [martin, ticket #846]
 
+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]