“Feeding /dev/urandom into the entropy pool for /dev/random” is cheating — you're pretending to provide new entropy when in fact the data is derived deterministically from the current state of the RNG. Fortunately, as you notedas you noted, the rule that you're cheating is a useless one: entropy doesn't actually decrease despite what the Linux kernel pretends.
Low entropy by Linux's /dev/random's estimate is common and almost always a false alarm: the estimate is unreasonably conservative.
/dev/urandom is secure for key generation/dev/urandom is secure for key generation, so Pidgin should arguably use /dev/urandom (which doesn't block) instead of /dev/random (which can block, and often does).
There is only one case where /dev/random blocking is legitimate because the system genuinely doesn't have enough entropy: when the system is too new to have accumulated entropy. Linux systems normally save entropy for the next reboot, so in practice genuine low entropy only happens in two circumstances:
- on a brand new installation — this is especially a concern in embedded devices that generate a key the first time they're turned on;
- on a live system.
Where to set the blame isn't really a productive consideration, but if you must: Arch Linux and you are fully innocent. Pidgin should use /dev/urandom or at least offer a way, so it gets part of the blame. The Linux kernel should really provide an interface that's guaranteed to deliver crypto-quality randomness and blocks only if entropy is genuinely lacking (like FreeBSD's /dev/random).
