New software release 3.5 - release notes

[Paul Campbell]

Just a quick note - I put up a new OneRNG software release last  week v3.5  - 
this is not a major release, it doesn't fix any bugs, more it tracks changes 
in the way that Linux systems have been working - here are some release notes:

- if rngd has been started by systemd it is now shut down when a OneRNG is 
inserted before starting a rngd instance connected to the OneRNG (rngd does 
not handle multiple instances well), if you remove your OneRNG we'll restart 
the old rngd

- there is now an option for the more paranoid among you to derate the value 
of the entropy that OneRNG produces - by default we set this to 0.93750 bits 
of entropy per bit - if you make this number smaller rngd will feed more 
OneRNG data into the kernel, stirring the kernel pool more - for example a 
value of 0.5 will feed 2 OneRNG bits for every bit the kernel asks for - you 
can change this in the /etc/onerng.conf file

- finally and this may be a reason why you want to upgrade - contrary to the 
popular received wisdom about how /dev/urandom works in modern kernels it 
doesn't simply consume entropy the same way as /dev/random but not stall when 
the kernel runs out of entropy, instead it sips at the kernel entropy pool 
occasionally - the kernel parameter:

     /proc/sys/kernel/random/urandom_min_reseed_secs

controls how often this happens - the default value seems to 60 - once a 
minute. In this release we set this value  to 0 (which disables this 
behaviour) in a rich entropy environment with a OneRNG this means that /dev/
urandom is continually fed more entropy. If the value of '0' is not what you 
want you can change it in the /etc/onerng.conf file

======================================================

Finally - this is not part of this new release - I found a bug in the 
firmware's failure reporting code - essentially if the on-board firmware sees 
a string of 8 00s of FFs it shuts down and reports a failure by flashing the 
LED in a fixed pattern .... of course strings like this do occasionally occur 
naturally from an RNG as part of its normal operation - it turns out there is 
a case where this can cause the LED can be turned off and stay off even though 
it is behaving OK.

You will only likely ever see this happen when the OneRNG is completely idle - 
when the kernel is not connected and regularly sipping data (since this will 
clear this state). 

So in summary, if the LED goes out (rather than is flashing which is the error 
indication) it's not a big deal, unless drawing some data from the device 
doesn't turn it back on again.

	Paul Campbell