I think that logging SSL library used for generating random numbers is still worth it. We do not need it in the GUI though, I agree.

Great to see this removed from the GUI.

utACK 5ecfa36. (building right now)

Tested ACK 5ecfa36

(I am ok to keep it in the debug.log, but I don't have a strong opinion here)

I also think it should be in the debug log but I do not think it serves a purpose in the Qt Information dialog.

Way off topic but in my dialog, the Build date appears to be wrong, reporting 17 Feb which is before 0.12.0 was released. Wonder if that is a bug in my chroot build environment.

I also think it should be in the debug log

Imo it's just not worth the effort to maintain. (We've had more than 3 pull request about "fixing" this in the last month). There are other trivial ways to determine the version of the library you are using

Way off topic but in my dialog, the Build date appears to be wrong, reporting 17 Feb which is before 0.12.0 was released. Wonder if that is a bug in my chroot build environment.

The build date for releases is the date when the last commit was commited:

$ git log  --format=%cD 188ca9c305d3dd0fb462b9d6a44048b1d99a05f3 -1
Wed, 17 Feb 2016 09:40:03 +0100

@MarcoFalke The sentence "There are other trivial ways to determine the version of the library you are using" unfortunately applies only to users with deep technical knowledge. Our users mix different versions of SSL libraries, at compile time and at runtime. The fixes applied to this part of our code only handle such strange instances. It is very useful to know what was used at runtime, really.

Thanks @MarcoFalke so it isn't really the "build" date as I think of "build" date (compile)
-=-
sorry for OT

I like this solution.

The build date should probably go away as well, it's confusing at least for the executables built in gitian, as the date/time is overridden to create deterministic executables. I don't think it adds very much in any case.

Imo it's just not worth the effort to maintain. (We've had more than 3 pull request about "fixing" this in the last month).

Yes, that's kind of annoying, and usually means a deeper solution is desirable.
OTOH we probably got it right now, finally. Removing it from just the GUI is fine with me too.

Agree with removing the build-date (in another PR), an alternative solution would be to only show the build date in non release builds (!CLIENT_VERSION_IS_RELEASE).

I think we should merge this PR and remove openssl from the logs and the GUI. IMO there is not much value in logging the openssl version regarding to PRNG, and, eventually we'll end up with a custom PRNG implementation (#5885) anyways.

It may actually be useful to log the version/hash of every library being used, but probably no reason to single out OpenSSL.

@luke-jr Well we log BerkeleyDB version as well. But at least there's a good reason for that, to troubleshoot wallet incompatibility.