On Thu, 01 Jul 2010, Petter Reinholdtsen wrote: > Perhaps ls round up to the nearest block? Any other ideas on how to > fix this with the tools available on /?
I'm looking at the kernel code for random.c right now. To me it looks like we can just drop the test for file size. When (and why) did we add it? Was it in response to some particular security concern? In 2.6.32, it looks like whatever you toss into /dev/u?random gets *MIXED* in the two pools, and does NOT contribute to the measurement of the entropy contained in the pool. So, it stirs up the pool but doens't cause the entropy estimation to increase, nor triggers the catastrophic reseed process, etc. At first glance, it looks to me like a short write will not leave you in a state any *worse* than you were before the short write. OTOH, it is a very nasty situation to have a broken random seeding, and we really should warn the user if that happens. But we could easily have two scripts, one that runs VERY early to do the reseeding (using something like cat or dd to feed the data to /dev/random or to /dev/urandom), and the other that runs much later to check if the seeding was done properly, and log a message at the LOG_CRIT level if it wasn't. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
