Personally I think we really should not convolute the two issues of:
- warning if entropy is low
- changing the default source of entropy.
those should really be 2 completely distinct discussions.
one is an simple choice/discussion: is there any cost/overhead of giving the user a warning about entropy?
The other is a more nuanced discussion about the risks/rewards of using diff sources of entropy and how that affects the confidence in our encryption based features: that deserves a lot more discussion in it's own jira.
With that said: here are my thoughts on the current patch/commit made so far in this jira...
I don't think it's useful as implemented.
IIUC having this type of check solely on startup may be missleading to users – just because there is "low" entropy available when solr starts up doesn't mean there will be low of entropy for the (long) life of the solr server process. LIkewise if there is "high" entropy on startup that doesn't mean everything will be fine and there's nothing to worry about: the available entropy could drop over time and cause performance issues later.
Rather then warning about this in bin/solr I feel like this type of information should be exposed by the solr metrics code, so people can easily monitor it over the life of the solr server process – either via a command line script we could provide, or via JMX, or via the admin UI ... we could even consider putting incorporating some specific "node health" metrics (entropy level, max open files, free disk, etc...) directly into the main screen of the Admin UI along with specific warnings/suggestions such as the text this issue added about SSL & UUIDField.