On Wed, Sep 02, 2009 at 02:01:10PM +0200, [email protected] wrote: > >Dropbear 0.52 should be using /dev/urandom, which AFAIK > >won't block? Unless the behaviour of recent kernels has > >changed... > > > >If Dropbear is blocking on the random device it should log > >something - could you check the auth logs? > > the problem actually didn't occur to myself, my role is just a > nag-target/-relay here... ;) > i'm not sure why, but on several systems (and that includes fat multicore > amd64 systems as well as armel devices) where i'm using dropbear in > initramfs myself, this hasn't been an issue. > but i got reports that this happens. once i actually saw a system 'hanging' > at boot, but didn't have a chance to do some debugging, sadly. > i.e. i don't have logs and not even a system where i know i could reproduce > the problem... :( > > to check the behaviour of dropbear when there's no(t enough) data coming > from /dev/urandom i simply made it a symlink to some character device that > doesn't output anything. this resulted in dropbear blocking before forking > into background. i know that urandom shouldn't block. but it seems that it > can happen (maybe on those systems urandom is just a symlink to random or > something like that - dunno). > i guess in any case - even if a blocking /dev/urandom were itself an error > - that's probably worth to be addressed? then again - if a blocking random > device gets logged, that sounds to me like it already is handled??
Hi, indeed dropbear uses urandom unconditionally, see http://bugs.debian.org/386976 According to urandom(4), I'd say a blocking urandom device is a bug. HTH, Gerrit. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
