Want to bring a topic to your attention which falls into the Security category and goes kind of hand-in-hand with #16
This issue describes the idea and asks for confirmation from the project leads whether this fits Work Package A: Enhancing Developer Tooling and Experience @juergen-albert
Motivation
Modern Maven (see https://maven.apache.org/resolver-1.x/expected-checksums.html) supports a trusted checksum mechanism: instead of trusting the checksums retrieved from the Maven remote (which can be compromised), you keep a file of expected checksums for each GAV groupId:artifactId:version. The Maven resolver then verifies downloaded artifacts against these recorded hashes to protect against supply chain attacks. This practise is already known by pinning github actions to specific SHAs.
Currently, bnd's Maven-related repos (notably MavenBndRepository and related tools using IndexFile, including both text .mvn and pom.xml list formats) only verify transport-level checksums (.sha1 or .md5 files retrieved from remote). There is no way to configure a trusted, locally-defined set of checksums for dependencies.
Proposal
- Add support for an optional sidecar checksums file (e.g.,
myindex.checksums) to be placed next to the index/definition file (myindex could be .mvn text or pom.xml format):
- Format: simple lines:
groupId:artifactId:version=sha-256:<hex>
- For each dependency in the index file, if a matching entry exists in the checksums file, after download, compute the checksum of the downloaded artifact and reject (fail verification) if the checksum does not match.
- The checksums file can be generated by an external tool, from trusted current copies or from a trusted lock state. This approach is independent of the index's storage format and supports both text and XML index files (other other future formats).
- Implementation would likely add logic just after repository resolution/fetch (
repo.get(archive)), so the additional check is performed before an artifact is exposed to the user or the build.
- (Optionally) support more than one digest algorithm (at least SHA-256, optionally SHA-512 or others).
Benefits
- improves supply-chain security for bnd-based builds using Maven artifacts
- Keeps compatibility with existing index formats and allows easily regenerating/updating trust state as artifacts are vetted.
- Aligns with security practices established by new versions of the Maven Resolver.
Notes
- The sidecar checksums file should be kept in version control with the index file.
- Extra validation should be available as a configurable policy (fail, warn, ignore) for backwards compatibility.
Want to bring a topic to your attention which falls into the Security category and goes kind of hand-in-hand with #16
This issue describes the idea and asks for confirmation from the project leads whether this fits Work Package A: Enhancing Developer Tooling and Experience @juergen-albert
Motivation
Modern Maven (see https://maven.apache.org/resolver-1.x/expected-checksums.html) supports a trusted checksum mechanism: instead of trusting the checksums retrieved from the Maven remote (which can be compromised), you keep a file of expected checksums for each GAV
groupId:artifactId:version. The Maven resolver then verifies downloaded artifacts against these recorded hashes to protect against supply chain attacks. This practise is already known by pinning github actions to specific SHAs.Currently, bnd's Maven-related repos (notably
MavenBndRepositoryand related tools usingIndexFile, including both text.mvnandpom.xmllist formats) only verify transport-level checksums (.sha1or.md5files retrieved from remote). There is no way to configure a trusted, locally-defined set of checksums for dependencies.Proposal
myindex.checksums) to be placed next to the index/definition file (myindexcould be.mvntext orpom.xmlformat):groupId:artifactId:version=sha-256:<hex>repo.get(archive)), so the additional check is performed before an artifact is exposed to the user or the build.Benefits
Notes