src/librandom/random_makeseed.c says that that's precisely the point; I
was quoting verbatim.
Ah, indeed. My mistake. Full disclosure: at first I wanted to speed up
the /dev/urandom initialization. Then, after careful re-reading of the
Linux man pages, I realized it wouldn't work; but I found the function
still had value (even if less so), because it would help shuffle the
bits. And I forgot to edit the comment. ^^'
Fixed now.
No, it's not. Roughly, the setup consists of a read-only rootfs
(squashfs, so really readonly), with a set of predefined services. As
part of the first s6-rc-init + s6-rc, a data partition is mounted, and
from the data located there, an additional set of services and/or
dependencies are generated, and only when that new service database is
compiled do we know precisely which services we need to be up at the
end
of the init phase.
OK, point granted. This is clean and legitimate.
Neither the end users, developers, PMs nor the hardware
watchdog will tolerate a boot time of upwards of 30 seconds.
It's a sad fact, but nevertheless a fact, that many embedded systems
out
there simply do not have a lot of sources of entropy, so relying on
getrandom(,,0) not blocking for too long is simply wrong on such
systems.
I know. :(
There's no good solution to that, I'm afraid, and practicality is in
direct opposition to security here. But I agree that for anything that
doesn't require cryptography, the lever should be bent towards
practicality.
But this part I don't understand. Why do you insist on using your own
homebrewed scheme (which will only ever try one - albeit I agree in
practice guaranteed to be universally unique - name), when perfectly
sane and safe standard functions exist that do the same? I mean, what
is
the security issue you see with using mkstemp/mkdtemp?
Frankly, mostly historical reasons. There was a time where the
implementation of these functions in common libcs was just terrible; so
I took the habit of never using them. Also, prejudice: when I (twice
so far) made a modernization pass on skalibs to remove old workarounds
and use standard interfaces where possible, I skipped stdlib.h, because
most of stdlib.h is just unusable crap. So I missed mkstemp and mkdtemp
and never really thought of using them where applicable.
But you make a good point. There are indeed places where
mkstemp/mkdtemp
could be safely used, and I'll do that. s6-rc-update is certainly one of
those places.
--
Laurent
