Arch Linux

I'm not the maintainer, but out of curiosity:

Why do you request the change? As far as I understand this would fix possible latency/timeout problems at the cost of weaker encryption, is this correct? If so, do we know that the weaker encryption is "good enough"? What are other distros doing, what does upstream think about the issue?

/dev/random is always secure as it stops returning data if it has too low entropy.
/dev/urandom guarantees not to block but can deliver less secure random data. Now
in SASL a random device is used for digest computation (as in CRAM MD5) and other
things. If you program a server doing authentication over SASL, the worst thing
which can possibly happen is that it stops during authentication (imagine sshd
would do that): you are open to DoSAs for login.

If you worry about security: /dev/urandom feeds actually on /dev/random for
it's entropy, so in normal situations they are equally safe. If you have a
hardware random number generator and are using for instance rngd, then the
hardware entropy is used to feed /dev/random's entropy pool.

This is a more general discussion I realize and maybe we should look at other
distributions and other packages (not only SASL) and what's the poilicy on
the usage of random number devices there.

Addendum: /dev/random feeds on hardware events, mainly mouse moves and keyboard clicks
to produce entropy (also a little bit interrupts and disk activity). Now servers
rarely have somebody sitting in the rack moving around mouses and doing a lot
of tipping.. ;-)

See at discussions like the following one:

"http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg98604.html"

It's about outweighing two evils, which one is in which case the lesser evil.

Thanks for the summary!

It sounds to me after reading the discussions that

1) /dev/random must be used when generating long-lastin keys/certificates (ssh-keygen, ++),
2) /dev/urandom must be used for things susceptible to a DoS attack,
3) things that are neither in 1, nor 2, should use /dev/urandom, and
4) things that are both in 1 and 2 are broken and need to be looked into...

Maybe we have a policy on this already that I have not seen?

/dev/urandom should be used for SASL. I faced this problem once on debian when we had setup a Cyrus Murder setup. Authentication between backend and frontend would always hang for several minutes after the box had rebooted because of an empty random entropy pool.