And the connection with setup component is? If you are talking about system installation, you probably meant anaconda, right?

The anaconda team suggested this as the best solution for everyone. The %post section does run until after a whole lot of disk activity has occurred so that kernel entropy should be good. They don't want to own creating the random-seed file. They said that in %post, we should be able to key on upgrade or install, so those doing 'rpm -Uvh' won't always have /var/lib/random-seed regenerated.

So what should be done in %post of setup package? It is not clear to me from the description. Please remember, that I'm limited to lua scriptlet in setup's %post section - and that because of the dependencies there will be almost nothing available on the system.
I guess with this change, setup package should own the /var/lib/random-seed file after the change...

This is what's normally done on shutdown:

touch /var/lib/random-seed
chmod 600 /var/lib/random-seed
dd if=/dev/urandom of=/var/lib/random-seed count=1 bs=512 2>/dev/null

Duplicating that is all that's needed.

And now in lua and without dependency on coreutils :)

I really think that this is something hard (or nearly impossible) to achieve in %post of setup installation ... I can't have dependency on bash or coreutils there...

Maybe something like:
local f = assert(io.open("/dev/urandom", "rb"))
local data = f:read(512)
local out = assert(io.open("/var/lib/random-seed", "wb"))
out:write(data)
assert(f:close())
assert(out:close())
with some posix.access checks... not checked and I'm not sure if rpm lua has support for this.

or... just making /var/lib/random-seed symlink to /dev/urandom 
with posix.symlink("/dev/urandom", "/var/lib/random-seed") in the case that it doesn't exists (and something later could replace it).

You can't make it a symlink. The idea is to save and restore a chunk of what's in urandom because when it reboots for the first time, there is no saved entropy. Somewhere along the way, the file permission needs to be 0600 and owned by root. Not sure if that is simply handled in the spec file or not.

The setup RPM was just an example.  Really, the creation of this file can go in to any RPM that every system will have installed.  The RPM itself should have a file entry for /var/lib/random-seed so the packaging system knows that some package owns the file.  If 'setup' cannot depend on coreutils and such, handle this in another package.  We have thousands to choose from.

initscripts might be a reasonable choice. However, one concern with going to this as a paradigm is that you're making system images *less* random, as an installed image base will now all have identical seeds unless you do some cleaning of them first.

Well, its true that any liveCD would not like this. But for bare metal installs this would help things so that we don't generate sshd keys based on almost no entropy.

Based on notting's suggestion moving to initscripts ...

Created attachment 560939 [details]
spec patch

Here's the spec changes. This isn't going on master, because initscripts is the wrong place in later Fedora releases.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, in the first boot there was no /var/lib/random-seed file, so there was relatively low entropy when sshd keys were generated. This version of initscripts creates /var/lib/random-seed during installation.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0816.html