[JonnieCache]

If the whole project is about signing code packages to prevent the platform being hacked, you would've thought the key generation would be considered a critical part of the application code, rather than a detail of the build process. Even if the code necessarily exists in the build script. The build script is the project in this case.

If a developer has ever even thought about generating a list of 1000 random numbers to pick from at a later date, then they shouldn't be developing production code.

[phirephly]

Yeah. You don't generate a list. You have make automatically dd 16 bytes from /dev/random, pipe it through hexdump, and then use that as your seed. You don't even have to check for dupes. There are 3.4 * 10^38 possible keys; You will not pick the same one twice.

That way, you can't even accidentally reuse a seed in development, or leak that list of the previously used seeds. When something compromises the system, and you don't need it any more, it should be destroyed.

[Swannie]

I was suggesting a one time list. You need to keep a list of past random numbers anyway so you can verify no repeats.

But sadly, I have to agree, this is epic fail.

[JonnieCache]

You are probably more likely to spontaneously rearrange your constituent atoms into cheese or something than to generate the same random 16 bytes twice, assuming a new number needs to be generated only once for each package of code signed. If there was one needed for each packet on a network or something it might be different.

In any case, this risk is orders of magnitude lower than the risk of someone leaking your list of past numbers, especially when they're this valuable.

[marshray]

Even worse, if you are using a list to eliminate the possibility of repeats then you aren't generating a perfect random distribution any more. The possibility of repeated numbers, however small, is explicitly allowed.