Hi Nia,

I think you are mixing a few issues here into one discussion - which might
make sense from a user perspective, but does not help us to get forward.

>From my POV the interacting-but-need-to-be-solved-individually issues

 - The libc or kernel<->userland API. This is what the core decision was
   about. The API is well (enough) defined, same on multiple OSes,
   and provides all the flexibility we need.

 - Making entropy available "early enough" during the boot process. This
   is a hard problem on *many* machines, but no big deal at all on modern
   x86 and a few modern aarch64.
   For me this is looks like still work in progress with no "good enough"
   solution yet. I understood Taylor would like to improve this next.
   I personally would define "early enough" as "during rc.d" and this makes
   the problem relatively easily solvable for "real installations" (see
   below) by just manually (or "someway") seeding the individual installations
   entropy file.
   IIUC Taylor would like to also enhance/add kernel parts providing entropy.

 - Related to above: how to deal with one-off setups like first boots of
   install images or clones of virtual machines.
   This will be solvable (probably by a combination of better scripting
   and/or documented "best practices") once the point above is more or
   less settled.

 - Finaly the grey area of "which variant of our API should applications
   use" (and even more complex: libraries). This needs individual answers
   on a case by case basis and might need some upstream battle - but we
   should be able to give good guidance and clear rules once the items
   above are cleared.


Reply via email to