[tahoe-lafs-trac-stream] [tahoe-lafs] #1924: NetBSD < 6.0 /dev/random appears to break RSA keygen in test suites

[tahoe-lafs]

#1924: NetBSD < 6.0 /dev/random appears to break RSA keygen in test suites
-------------------------------+--------------------------------
     Reporter:  midnightmagic  |      Owner:
         Type:  defect         |     Status:  new
     Priority:  major          |  Milestone:  undecided
    Component:  code           |    Version:  1.9.2
   Resolution:                 |   Keywords:  netbsd,/dev/random
Launchpad Bug:                 |
-------------------------------+--------------------------------

Comment (by gdt):

 The behavior of random(4) on NetBSD 6 is actually a bit more complicated;
 a single open and read of lots of data uses up some bits, but repeated
 reads will still drain the pool and cause blocking.  By definition,
 random(4) is supposed to block rather than return bits without defensible
 entropy, while urandom(4) is supposed to return pretty good bits.

 In actual use, presumably blocking is better than bad security properties.

 So I'd say the test harness should do some combination of
  * refrain from over-using random bits
  * use urandom(4) instead (which is a scary/invasive change)
  * warn the user to address entropy generation (can be very hard in VMs)
  * accept that it may take a very long time to run

 (I am assuming that the random/urandom distinction is portable; my
 understanding is that while NetBSD and Linux have different
 implementations there has been a common view of the top-level
 specifications of how this should behave.)

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1924#comment:3>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage