Skip to content

{

Choose a tag to compare

@tobrien tobrien released this 01 Jan 15:30
· 7 commits to working since this release
5d30825

"RELEASE_NOTES": {
"title": "v1.0.11 — Conditional ML-KEM benchmark compilation; release/version bump",
"body": "Overview

  • This release bumps the package version to 1.0.11 and introduces a safe build-time change to the Docker image: the ML-KEM benchmark (mlkem_bench) is now only compiled when OpenSSL 3.x is available. No other functional/source-code changes were made.

What changed

  1. Docker: only compile ML-KEM benchmark when OpenSSL 3.x is present
  • Previously the Dockerfile always attempted to compile src/mlkem_bench.c during image build. That could fail when the image is built against OpenSSL releases that do not provide the ML-KEM APIs.
  • The Dockerfile's compile step now checks the OPENSSL_VERSION environment variable and:
    • compiles mlkem_bench only if OPENSSL_VERSION starts with "3." (OpenSSL 3.x), and
    • otherwise logs a message and skips compilation.

Why this matters

  • Prevents build-time failures on images that use OpenSSL < 3.x (or where OPENSSL_VERSION does not indicate a 3.x release).
  • Avoids producing a broken or non-functional mlkem_bench binary when the necessary OpenSSL APIs are unavailable.

Impact and migration notes

  • For users running or building the Docker image:

    • The mlkem_bench binary may be absent from the final image when OpenSSL < 3.x or when OPENSSL_VERSION is unset/not matching "3.". Build scripts or runtime callers that assume mlkem_bench is always present should handle its absence (for example, check for the executable before invoking it).
    • If you need mlkem_bench in the image, ensure the build environment exposes OPENSSL_VERSION beginning with "3." (i.e., OpenSSL 3.x). How you set that depends on your CI/build pipeline (set the environment variable earlier in the Dockerfile or map a build argument into the environment). If you prefer a stricter policy (error when OPENSSL_VERSION is unset or not 3.x), update the Dockerfile to fail instead of skipping.
  • For developers:

    • No API or source-code behavior changes besides the Dockerfile behavior described above.
    • Unit tests and runtime files are unchanged; only the compile step is conditional.
  1. Package version bump to 1.0.11
  • package.json version updated from 1.0.10 to 1.0.11 to mark a non-dev release.
  • There were no functional/source-code changes associated with this version bump.

Repository hygiene note

  • The release commit included regenerated artifacts under node_modules (node_modules/.package-lock.json and node_modules/.vite/vitest/results.json). These are generated/test-run artifacts and are typically not tracked in source control.
  • If these files were committed accidentally, consider removing them from the repo and adding/updating .gitignore rules to prevent future commits. For example, maintainers can remove them with git rm --cached and commit the change.

Breaking changes

  • There are no breaking API changes.
  • Behavioral change to be aware of: the mlkem_bench binary may not be produced on image builds that do not have OpenSSL 3.x (or where OPENSSL_VERSION does not indicate 3.x). Treat this as a deliberate safety change (avoids build failures), but update any automation that assumed the binary was always present.

Practical examples and checks

  • To detect presence of the benchmark in a built image before attempting to run it:

    • check for existence and execute permission: [ -x /benchmark/mlkem_bench ] && /benchmark/mlkem_bench || echo "mlkem_bench not present"
  • To ensure compilation happens, make sure the build environment exposes OPENSSL_VERSION beginning with 3. (Exact method depends on your Dockerfile and CI; ensure the shell that runs RUN sees the variable.)

Summary

This release is primarily a maintenance/versioning release (1.0.11) with a single, practical Docker improvement: the ML-KEM benchmark build is now conditional on OpenSSL 3.x being present. That prevents needless build failures and avoids shipping a broken benchmark binary when the required OpenSSL APIs are unavailable. There are no source/API breaking changes, but consumers should handle the potential absence of mlkem_bench in images built without OpenSSL 3.x.
"
}
}