86bdc78365
feat: add optional digital signature verification for HDF5 filter plugins Introduce an opt-in plugin signing and verification system that allows HDF5 deployments to require cryptographically signed filter plugins before loading them. Disabled by default (HDF5_REQUIRE_SIGNED_PLUGINS=OFF). New tool: h5sign - Signs plugin shared libraries by appending an RSA signature and a 14-byte footer (algo_id | sig_len | 8-byte magic | format_ver) to the binary without modifying the original content. - Supports SHA-512 (default), SHA-256, SHA-384, and their PSS variants (-a/--algorithm flag). - Detects already-signed plugins; --force strips the old signature and re-signs. - Security hardened: keeps the file descriptor open through hashing and appending (no TOCTOU window), enforces a 2048-bit minimum RSA key size, rolls back partial writes on failure, and rejects paths that are not regular files. Verification (H5PLsig.c) - At plugin load time, reads the footer, validates the magic and format version, then checks the RSA signature against all public keys found in the KeyStore directory. - File is hashed once; per-key verification operates on the pre-computed digest (no redundant I/O for multi-key keystores). - Plugins whose signature hash appears in revoked_signatures.txt are rejected regardless of key validity. - Runtime debug output via HDF5_DEBUG=pl. KeyStore management - Trusted public keys are PEM files in a directory specified by HDF5_PLUGIN_KEYSTORE_DIR (build time) or HDF5_PLUGIN_KEYSTORE (env var). - HDF5_LOCK_PLUGIN_KEYSTORE cmake option disables the env-var override for security-hardened deployments. Test infrastructure - h5signverifytest: positive, negative, tamper, re-sign, and revocation test cases. - CTest fixture-based dependency graph (FIXTURES_SETUP/FIXTURES_REQUIRED) replaces fragile DEPENDS chains so tests remain correct under -R filtering. - Dedicated signed-plugins.yml CI workflow; full test suite scoped to H5SIGN and H5PLUGIN-signature tests to avoid unrelated flaky failures. - Cross-platform: Linux, macOS, and Windows (MSVC-compatible, BIO-based OpenSSL I/O, HDsleep/HDsetenv portability wrappers). Documentation: docs/PLUGIN_SIGNATURE_README.md covers usage, footer format, revocation file format, FAQ, and troubleshooting. Co-authored-by: Glenn Song <gsong@hdfgroup.org> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
The release_docs directory
This directory contains release artifacts only: changelogs, version history, release process documentation, and maintainer information.
User-facing guides (installation, build instructions, platform-specific docs)
have been moved to the docs/ directory.
Contents
CHANGELOG.md (formerly RELEASE.txt)
This is the changelog for the current version of the library.
For a MAJOR release (or in develop) this file lists all the changes since the
last major version. For a MINOR release (or in a maintenance branch), this file
lists all the changes since the last release in the maintenance branch.
Examples:
- The file for HDF5 1.14.0 includes all the changes since HDF5 1.12.0
- The file for HDF5 1.10.9 includes all the changes since HDF5 1.10.8
- The file in
developincludes all the changes since the last major release - The file in
hdf5_1_14includes all the changes since the last minor HDF5 1.14 release
HISTORY files
The HISTORY files contain the history of this branch of HDF5. They fall into
three categories.
HISTORY-[VERSION 1]-[VERSION 2].txt
These files are created when we release a new major version and include all
the changes that were made to the develop branch while creating a major release.
HISTORY-[VERSION].txt
This file contains the changes that were made to a maintenance branch since
it split off from develop. It will also be found in the develop branch
when experimental releases have been created.
Note that we make no effort to bring maintenance branch HISTORY files back to
develop. If you want to compare, say, 1.10.4 with 1.12.3, you'd have to get
the history files from those releases and compare them by hand.
RELEASE_PROCESS.md
Documentation for how releases are created and managed.
MAINTAINERS.md
Maintainer information for the project.
Creating new releases
MAJOR release
-
If there were experimental releases, merge the experimental
HISTORYfile and the currentCHANGELOG.mdby category to create a separate, unified file that ignores the experimental releases. Don't check this in yet or clobber any existingHISTORY/RELEASEfiles, but put it someplace handy for use in later steps. -
Create the new maintenance branch
In develop:
- Create the new
HISTORY-\[VERSION 1\]-\[VERSION 2\].txtfile- If there is an experimental
HISTORYfile, addCHANGELOG.mdto the beginning of it and use that - Otherwise, start with
CHANGELOG.md - Add the introduction boilerplate like in the other
HISTORYfiles (TOC, etc.)
- If there is an experimental
- Delete any experimental
HISTORYfile - Clear out
CHANGELOG.md
Note that we're KEEPING any experimental release history information in the
HISTORY-\[VERSION 1\]-\[VERSION 2\].txt file, so do NOT use the merged file in
the above steps!
In the new maintenance branch:
-
Create the new
HISTORY-\[VERSION\].txtfile- If there is an experimental
HISTORYfile use the combined file you created earlier - Otherwise, start with
CHANGELOG.md - Add the introduction boilerplate like in the other
HISTORYfiles (TOC, etc.)
- If there is an experimental
-
Delete any experimental
HISTORYfile -
Clear out
CHANGELOG.md -
Create the new release branch
In the new release branch:
- If there were experimental releases, use the combined file you created earlier as
CHANGELOG.md - Otherwise the
CHANGELOG.mdwill be used as-is
MINOR release
- Create the release branch
In the maintenance branch:
- Add the contents of
CHANGELOG.mdto the beginnnig ofHISTORY-\[VERSION\].txt - Clear out
CHANGELOG.md
EXPERIMENTAL release
- Add the contents of
CHANGELOG.mdto the beginnnig ofHISTORY-\[VERSION\].txt - Clear out
CHANGELOG.md