> Date: Sun, 07 Jan 2001 01:34:40 +0100 (MET)
> Subject: Re: Random seed and possible blocking of /dev/random
> From: Richard Levitte - VMS Whacker <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
[snip]
>
> However, if we so choose, would it be really bad to simply create a
> /var/run if not present when installing prngd? Another variant would
> be to have it configured in some "standard" file, perhaps
> /etc/egd.conf or /etc/prngd.conf?
>
> Personally, I still see nothing wrong with having that socket name in
> /etc/...
Methinks there are two separate questions floating around here...
1) what should the _client_ code assume/look for/do in an attempt to
auto-magically locate a (possibly pseudo-)hardware RNG,
2) what should a specific "random number server" with regard to 'announcing'
itself -- so as to make it easy for potential clients to locate it.
I will merely note that these issues are not symmetric.
Addressing how the 'server' side shoud do things....
For some of my 'semi-weird' environments, I like the idea of having:
a) the actual place/type of the socket specified as a start-up option to
the server daemon.
b) the -specification- of that socket saved (as text, preferably) in a
'well known' place.
With this arrangement, one can put the socket "wherever is appropriate"
to ones needs -- including, for example, in a sub-directory that only
a limited set of users have "can use in a path" access to. However,
regardless of where the socet really is, any application does know
'where to look' to find the location.
There is a great deal to be said in favor of 'indirect' access like this.
Particularly because a system manager can re-organize things (i.e. "move
'em somewhere else"), and update the 'pointer'; whereupon things _continue_
to work, with NO CHANGES required to user-level applications.
In fact, the 'random number server' and the client don't even have to be on
the same machine, in this set-up. The 'specification' of the RNG could
be a 'filename' describing a local 'named socket', or it could be a
host:protocol:port triple, describing a *remote* random number source
Comment: I'm lazy, _professionally_. I *LIKE* things that do -not- make for
extra work for me down-the-road.
My other recent pontification dissected the question of 'client' side
behavior, no need to belabor that again, in any detail. Something like
the way DNS _client_ (i.e. 'resolver' library) code decides: what to look
for, where, and in what order -- a nice -flexible-, and extensible, model,
would seem to have a lot to recommend it.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
