I was reading the old prng paper come across the follwoing:

The Linux boot process does not provide much entropy in the different sources available to the
PRNG. There is usually little to no user input and network events at this stage, and disk activity
at startup is very deterministic. Therefore, the designer of the Linux PRNG recommends a
script which, at shutdown, generates data from /dev/urandom and saves it in a file, and at
startup, writes the saved data to /dev/urandom. This mixes the same data into the blocking
and nonblocking pools without increasing their entropy counters.
Such a script is provided in the default installation of most Linux distributions. In situations
where this procedure is not possible, for example in Live CD systems, the nonblocking random
number generator should be used with caution directly after the boot process since it might not
contain enough entropy.

boils down to:

• public track record of tracking and fixing (within 10 days) vulnerabilities for over 1y
• capability for private issue tracking
• contributing back (based on the jobs listed for the distros list)
• being able to receive gpg mails
• getting someone to vouch for us who is already on the list

In reply to @vcunat:matrix.org
IIRC one of the major blockers is that we don't have infrastructure to privately prepare binaries.

In reply to @winterqt:nixos.dev
I wonder if we could create a private Hydra jobset, run the jobs on there so the binaries are cached, maybe do ACLs on the binaries on S3 if someone somehow manages to guess the store path, and then assuming there are no intermediate rebuilds required in between this and the embargo lifting... profit?