#1064839 Consider not using an ephemeral key or document its security model

#1064839#5
Date:
2024-02-26 13:45:19 UTC
From:
To:
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040901 I asked you
to switch to an ephemeral key which was a misunderstanding from a
discussion with xnox, which we still need to sort out fully.

Please either document how the buildds ensure that

- private key generation has enough, and high quality enough, entropy
- private keys are safely erased after not being needed anymore

or revert to signing modules with the CA key and use MODVERSIONS
and co to ensure that modules built for one ABI cannot be used
with another.

I need to update the question in shim-review accordingly, I think
I never reverted it or adjusted it, but it will likely take the
form of the previous three paragraphs.

I sincerely apologize for causing this misunderstanding.

#1064839#10
Date:
2024-02-26 15:53:11 UTC
From:
To:
you

Are those really that hard of a problem to solve? Running any modern
kernel entropy shouldn't be an issue, certainly not on controlled
environment like the buildds - if an attacker has complete control of
the buildds environment, then we can pack up and go home, given the
kernel build is not reproducible. And likewise key handling could be
done in a non-swappable tmpfs tied to the lifetime of the build process
via a namespace, that ought to be enough for peace of mind?

Using an ephemeral key makes things so much simpler and nicer and
quicker at signing time, and so much simpler to reason about. One
kernel, one set of modules, and that's it.