-
Notifications
You must be signed in to change notification settings - Fork 444
Release process
The following files are to be updated
- The top-level
CMakeLists.txt:- Update the
OQS_VERSION_TEXTvariable. - Update
SOVERSIONif applicable
- Update the
-
RELEASE.md- Update version number, fill in text -
SECURITY.md- Update support level, latest security status
Running the script to include upstream algorithm code should not result in any changes.
Most notably, constant time tests need to be executed locally without skipping any algorithms (as is done to allow CCI task weekly to pass), i.e., run python3 -m pytest --verbose --numprocesses=auto tests/test_constant_time.py after building liboqs via cmake -GNinja -DOQS_DIST_BUILD=OFF -DOQS_OPT_TARGET=haswell -DCMAKE_BUILD_TYPE=Debug -DOQS_ENABLE_TEST_CONSTANT_TIME=ON .. and cmake -GNinja -DOQS_DIST_BUILD=OFF -DOQS_OPT_TARGET=generic -DCMAKE_BUILD_TYPE=Debug -DOQS_ENABLE_TEST_CONSTANT_TIME=ON ...
To ascertain that no performance regressions have crept in, running the script noregress.sh in the scripts folder is recommended on an RC. It needs to be passed as parameter the tag of the previous release and run on the different platforms supported (x86_64, aarch64). Further optional parameters permit defining cmake build parameters and setting a platform-specific build command to check different configurations. The output needs to be reviewed as to whether unacceptable or unexplicable deviations (beyond deemed acceptable 15%) have occurred.
For subproject oqs-provider, a specific release-test script should be run on a suitably powerful (many-core) machine: It enables all algorithm combinations and tests those. This test will run automatically in CI once a release candidate is tagged. The CI workflow will run using the liboqs release candidate tag and oqs-provider branch (or tag) <liboqs RC tag>-tracker. If the latter does not exist, the main branch of oqs-provider will be used instead. For example, if the liboqs release candidate tag is 0.9.3-rc1, the CI workflow will attempt to build liboqs from the tag 0.9.3-rc1 and oqs-provider from the branch (or tag) 0.9.3-rc1-tracker. Before publishing the liboqs release candidate tag, it is recommended to create an appropriate -tracker branch, which can then be converted into an oqs-provider release candidate if so desired.
Docker images resulting from the build in oqs-demos should be tagged to the same version number as liboqs as and when they have been built and deployed by the CCI automation. Sample command: docker tag openquantumsafe/curl:latest openquantumsafe/curl:0.5. The binary image of chromium has to be built in a bespoke ubuntu image with all prerequisites as documented. Be sure to set -DOQS_DIST_BUILD=ON to execute the resultant binary on any CPU. There presently is no docker-based build infrastructure available to generate and test-run this binary.
The benchmarking image is presently not automatically built at each merge to (OQS-OpenSSL or liboqs) main, so the build task in oqs-profiling should be manually triggered, e.g., by a version bump in the project's README, if a new liboqs release has been done.
Subsequent a successful new release, follow the documentation at oqs-demos/nginx/fulltest to install a new interop test server. Possible procedure:
- Update version tags of
liboqsandoqs-providerinbuild-ubuntu.sh - build server and certificates
- deploy to actual server
All three steps could be performed at once when executed at the configured test server (
test.openquantumsafe.org).
After a release candidate (RC) passed all internal and downstream project tests, downstream projects --unless following their own release strategy-- should be tagged, too.
Create a pull request for the OQS website updating the liboqs algorithm version in submodule (_include/liboqs), as well as the version log and adding a news item to the front page