Github user richardcloudsoft commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/117#issuecomment-52497835
This whole idea of manipulating `/dev/random` to `/dev/urandom` is
something that has always made me feel uncomfortable, although I've kept quiet
about it as my experience here is theoretical and others have practical
experience of this problem. But I don't like the idea that apps that have been
deliberately programmed to use what they think is the entropy-based random
number source are being deceived into using the PRNG - plus messing around in
/dev generally sounds a bad idea. Having this as the default behaviour tells me
that Brooklyn values convenience over security.
To be blunt (for which I apologise) my opinion is:
* Worst - compromise the random entropy device on an entire VM for every
application as default behaviour by hacking around in `/dev`
* Bad - compromise the random entropy device on an entire VM for every
application as default behaviour, but at least use `rng-tools` as described by
@ahgittin so we're not hacking around in `/dev`
* Least worst but acceptable option - make the above an option, but keep
the default unchanged, so that the user has to actively decide to do this
* Better - for the individual apps that require this, reconfigure the
individual apps to use `/dev/urandom`, rather than change the default for the
entire system - also make this a default-off option so that the user has to
actively decide to do this
* Best - found out better ways to genuinely replenish the entropy pool on
cloud systems (maybe [like
this](https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged)?)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
