“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 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, 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).
