Lei Yu <yulei.sh@bytedance.com> wrote:
    > For dev builds, it uses the insecure development key in the tree.
    > For release builds, it requires the `SIGNING_KEY` env to point to a
    > secure key to sign the image.

    > It is considered insecure because it requires the build server to
    > access the private key.

The build server requires authorization from the holder of the private key to
create signatures.   One way is have direst access to the private key.
I think that if the build server is so untrusted, then maybe there are other
problems :-)

I didn't find where SIGNING_KEY is used.
I suspect that the signature is generated by an openssl command, and so
actually it could be directed to an engine/HSM.

BUT, in some cases the process is to build something as a devel-ish build,
and then if QA approves, it is signed with the release key afterwards, and so
your process would make sense.

    > An alternative is proposed:
    > * A new `SIGNING_PUBLIC_KEY` env is defined to point to a public key.
    > * The above key is default to empty, and the behavior is the same as
    > before, using the insecure development key to generate and sign the
    > image.
    > * With a valid `SIGNING_PUBLIC_KEY`:
    > * The public key is installed into the BMC image.
    > * The generated tarball is not signed, only containing the MANIFEST
    > and the image.
    > * A new `gen-bmc-tar` tool will be introduced to sign the above
    > tarball, like `gen-bios-tar`.
    > * If both `SIGNING_PUBLIC_KEY` and `SIGNING_KEY` is set, throw an error.

There is a chain of custody concern between building tarbar and running gen-bmc-tar.
So, I'd always sign with the development key, and I'd validate that signature
and then replace it.

    > With the above proposal, the build does not require the private key
    > anymore and the user could install the public key during build, and
    > sign the image separately.

    > Comments are welcome.