Release Process Proposal

[cfrantz]

Release Process Proposal

Goal: avoid committing binaries to this repo.

Proposal: Use github releases as the provider for binary artifacts. Use bazel
to reference github release archive URLs to access the necessary binary
artifacts.

Pre-work

1. Allow attaching additional bazel repos into the provisioning extensions repo.
   These additional repos get symlinked into a hub repo named
   @provisioning_exts_extra. These additional repos are:

   • presign_perso
   • presign_rom_ext
   • perso_release
   • rom_ext_release

   The URIs and names of these additional repos are controlled by
   //skus/extras.json.

Release Process

1. Tag the codebase:
   • ROM_EXT_BUILD_20260513_rc00
   • PERSO_BUILD_20260513_rc00
2. Build the ROM_EXT or perso binaries at the tag. Publish the resulting
   archives as a github release. Note: the release archive contains both
   presigning binaries and digests.
3. Create a branch at the tag and update the presign_ member(s) of
   extras.json. Push the branch.
4. Perform the offline signing ceremony and sign the digests in the presigning
   archive.
5. Create a PR with the signatures from the offline ceremony. Submit that PR to
   the branch.
6. Build signed binaries from the the release branch using the presigning
   binaries from the archive. Publish the signed binaries as a github release.
7. Update the release member(s) of extras.json. Tag the branch with a
   release tag (e.g. ROM_EXT_RELEASE_20260513_rc00). Push the branch and
   tags.
8. Merge the changes to extras.json from the branch into the main branch.

Automation

Add github actions to assist with automating the two halves of the release
process.

• Pre-signing automation: Steps 1..3.
• Post-signing release: Steps 5..8.

Potential Problems

The opentitan codebase currently uses a repository extension to hook the
ot-sku codebase into the opentitan codebase (as @provisioning_exts). The
opentitan repo doesn't watch the extras.json file in the downstream codebase.
Updates to extras.json require refreshing the repository mapping to allow the
hub repo @provisioning_exts_extra to see the updates.

TODO: Investigate making the @provisioning_exts repo a bazel_dep and use the
commandline --override_repository=provisioning_exts=<path> to connect ot-sku
into the main repo. Build the hub repository as an extension inside of the
ot-sku repo. Does this resolve the issue?

[cfrantz]

FYI @moidx @BenBenderOT

[cfrantz]

Re: potential problems. I've been forcibly refreshing the repository mapping after changing extras.json like this:

rm MODULE.bazel.lock
bazel mod deps

[cfrantz]

The current "FAKE" release was created with the following:

1. Build perso and ROM_EXT presigning artifacts

bazel build --stamp @provisioning_exts//open/perso:presign_perso  @provisioning_exts//open/rom_ext:presign_rom_ext

gh release -R lowRISC/ot-sku create FAKE_BUILD_20260518_rc00 \
    -p -t FAKE_BUILD_20260518_rc00 \
    -n "Fake build for build/release testing" \
    bazel-out/k8-fastbuild/bin/external/+hooks+provisioning_exts/open/perso/presign_perso.tar.xz \ 
    bazel-out/k8-fastbuild/bin/external/+hooks+provisioning_exts/open/rom_ext/presign_rom_ext.tar.xz

2. Update ot-sku/sku/extras.json to reference the presigning artifacts. Refresh the repository mapping.
3. Offline sign the artifacts (this build was signed with fake keys):

# Download the archives and unpack them
source ot-sku/skus/open/fake_keygen/softhsm_sourceme.sh

# Build hsmtool in the opentitan repo and use it to sign
hsmtool --token test -u user -p 123456 exec <name-of-signing-directives.json>

# Copy signatures to the appropriate locations.  For a real build, you'd send a PR with these files.
cp perso*_sig skus/open/signatures/perso
cp rom_ext*_sig skus/open/signatures/rom_ext

4. Build and test the final signed binaries

bazel test @provisioning_exts//open/rom_ext:signature_test @provisioning_exts//open/perso:signature_test

bazel build --stamp @provisioning_exts//open/perso:perso_release  @provisioning_exts//open/rom_ext:rom_ext_release

gh release -R lowRISC/ot-sku create FAKE_RELEASE_20260518_rc00 \
    -p -t FAKE_RELEASE_20260518_rc00 \
    -n "Fake release for build/release testing" \
    bazel-out/k8-fastbuild/bin/external/+hooks+provisioning_exts/open/perso/perso_release.tar.xz \
    bazel-out/k8-fastbuild/bin/external/+hooks+provisioning_exts/open/rom_ext/rom_ext_release.tar.xz

5. Update ot-sku/sku/extras.json to reference the signed artifacts. Refresh the repository mapping.\
6. Run the full orchestrator test suite.

bazel test --test_output=streamed //sw/host/provisioning/orchestrator/tests:e2e_multistage_ot00_staging_hyper310_test

Ideally, we'd run step 6 before the gh release command. In order to do that, we need to adjust some filepaths and dependencies that refer to the perso and rom_ext binaries as outputs from the build step rather than files referenced in the release repo.