>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
Received on Wed Sep 27 2017 - 12:21:05 UTC