Re: [Buildroot] [PATCH v3] package/urandom-scripts: actually credit seed files via seedrng

["Yann E. MORIN" <yann.morin.1998@free.fr>]

All,

On 2022-04-02 19:08 +0200, Arnout Vandecappelle spake thusly:
> On 01/04/2022 13:34, David Laight wrote:
> >From: Jason A. Donenfeld
> >>Sent: 01 April 2022 12:05
> >>On 4/1/22, James Hilliard <james.hilliard1@gmail.com> wrote:
> >>>I should add that I do also think this should be upstreamed to busybox,
> >>>which
> >>>will also reduce the amount of duplicate work as busybox is commonly used
> >>>across many distros.
> >>I'll work on that.
>  +1 to have it in busybox.

I still fail to understand why this can't be a standalone project.

The reasoning offered by Jason is that the code should be included
and duplicated into all and each init systems out there.

However, this increases the maintenance burden, as each implementation
has to be actively tracked (FTR: Jason said he would actively maintain
the implementation in Buildroot, which is very nice of him, so I
understand that he would also do so for all other projects where he'd
have seedrng included).

Instead of having one implementation suitable for every init systems
that use shell scripts, we'd end up with many different and diverging
implementations that each have their own warts and fixes (or worse,
counter-productive fixes that actually decrease the robustness of that
implementation).

On the other hand, having a common project would alow to centralise the
fixes. It would also allow to ensure that changes do not actually break
security. Finally, any evolution, be it fixes or features, would be
easily available to every init systems using the common project.

Furthermore, the level of customisation is very low. All that we can
expect to be customisable is the location where the seeds are stored.
This is already accounted for in the existing seedrng git tree. Using
another hash implementation could be another thing, but there's not
much point here, Blake2 being already pretty strong and known. So there
is probably not much more customisation left to do.

Moving it into busybox might seem a good idea at first, but this would
still make for an n-th implementation to track, and since busybox has a
focus on code size, the implementation there would probably diverge
substantially from the canonical code we saw so far, further increasing
the maintenance burden.

That would also not address distributions that do not use busybox (and
do not use systemd either). Buildroot can even be configured in such a
way, using a sys-v init system with coreutils et al,. and no busybox, in
which case having seedrng only in busybox would still not solve the
problem in such a case. And init systems are not limited to what we can
see publicly; there are maybe hundreds or thousands of such custom init
systems behind private doors. Buildroot even has an option to configure
for such an init system (BR2_INIT_NONE, which really means 'custom').

On a final note: systemd has native support for this feature, and thus
one may argue that the feature is indeed already duplicated there.
However, this is different in two ways: first, systemd needs random
numbers for itself already, very early in the boot, possibly in an
initramfs, so it can't easily rely on an external tool to do that;
second, systemd is already C, so it does not make sense for the feature
to be implemented as an external tool either.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot