This article also appears in the Maven Central blog.
As custodians of the Maven Central registry, it's important to us here at Sonatype to ensure Central remains accessible, secure, and modern for users and publishers.
With this in mind, over the past few years, we have been investing heavily in Maven Central with the goal of modernizing the platform, improving the security of publishing and consumption, and providing a developer experience consistent with expectations of contemporary software registries. This is a wide-ranging effort that is expected to improve upon nearly every aspect of the platform.
As we work through design and planning activities, the emergence of sigstore as a solution to address provenance concerns that are critical to software supply chains is particularly exciting to us.
Like many other software and package registries, Maven Central currently relies heavily on developer GPG signatures of artifacts to guarantee their authenticity and integrity: signatures are a requirement for publication to Maven Central, and while providing for some added security, the implementation has an outsized impact on complexity and publication times for our publishers.
And, like other registries, the value of these signatures is not truly realized due to shortcomings in public key infrastructure, developer tooling, and no extant chain of trust for developers. Sigstore is literally designed to solve this problem with elegance and runtime properties that are especially appealing in common Java development and CI environments.
We have every intent to adopt sigstore as part of the Maven Central platform and we are in the process of considering the dimensions of our participation with OpenSSF to further support activities around software development and security.
Our roadmap for Central
While we are starting to gear up for the implementation of sigstore, there are a few other important milestones that will precede this work. Through the feedback we've received over the past few years, we recognize that the workflows for publishers to manage their components, and the metadata around them, was similar to what the typical consumer wants to see about components… just in read-only mode.
So we're starting with those common, read-only capabilities as the first milestone in our work - the delivery of this UI and set of services will provide scaffolding for future work around publisher services, identity management, and streamlined publishing API.
We can't wait to share our work with you as soon as we can, on the order of weeks to months. In the meantime, some screenshots of what's coming:
