An Update on General Availability
This is an update on the plans to make the sigstore community infrastructure Generally Available. sigstore is a bit different from many other open source projects in that we provide a maintained, running instance of the open source components for the public to use for free, with an alert referring to it as experimental. Today, we’re excited to announce the timeline for this work to complete, as well as share what has already been done and what work is remaining. But first, we’ll start with a bit of history!
A Bit of History
Every time a user adds an entry to rekor.sigstore.dev or requests a certificate from fulcio.sigstore.dev using any of the sigstore signing clients (such as cosign or libraries like sigstore-python or sigstore-java), they interact with our public good instance of the sigstore infrastructure.
This infrastructure has been operated by the community on a best-effort basis for a little over a year, with disclaimers referring to it as “experimental”. These warnings are in place because the infrastructure is currently operated on a best-effort basis, and we’ve been learning how to run the system under load as we go.
Over the past six months, the sigstore GA working group comprised of representatives from several organizations (Priya Wadhwa, Kenny Leung, Simon Kent, Hayden Blauzvern, Carlos Panato, Adolfo Garcia Veytia, Bob Callaway and others) has been hard at work operationalizing this infrastructure in an effort to provide production-grade support and SLOs for the community to rely on, allowing us to remove these experimental warnings.
Looking Ahead
We’ve made considerable progress in maturing our operations and code base, so going forward, we’ll be establishing a multi-vendor on-call rotation, backed with commitments from several different organizations to staff this team for an extended period of time.
This rotation will be responsible for maintaining, updating, and deploying the public good infrastructure, publishing SLOs and error budgets, and handling any escalations and outages. They’ll operate as transparently as possible, and we plan to offer the ability for other organizations and community members to join the group over time.
Before we declare the service to be Generally Available and appropriate for production use, we’d like to give the community every confidence that the systems are as reliable as we claim. We’re targeting four months from today. We think this is achievable given the work items remaining and current system stability, but road blocks may always occur.
During this four-month window, we plan on refining our operational documentation and tooling, as well as simulating disaster scenarios and outages to ensure we’ve exercised all of our emergency playbook entries. This time period will give us the confidence we need that the system can be operated reliably by our new rotation before we declare the system Generally Available and remove the experimental warnings.
Stability
The sigstore General Availability release will also consist of 1.0 releases of all critical components (i.e. fulcio, and rekor) that come with API stability guidelines, following the general SemVer and Golang API deprecation policies. It will also come with a published SLO for availability, and a status page the community can use to monitor our performance and understand what incidents have affected availability as well as how the on-call engineers resolved them.
We also recognize that reliability is more than just an uptime percentage, especially for security-critical systems like sigstore. To help increase confidence in the platform architecture, operational practices, and vulnerability management processes, we also worked with the Open Source Technology Improvement Fund to complete a security audit. Include Security performed the audit and authored a report of findings, which included several major and minor vulnerabilities that the community worked to address. The full report will be available soon.
Future
The push towards General Availability is just one of the first steps in making production-grade sigstore available to everyone. In the coming months, we’ll also be designing our federation model so other organizations can operate their own log instances. We’re also planning to improve the support for transparency log auditors and monitors, making these easier to operate in an effort to strengthen trust in the entire network. Please reach out to us on Slack or GitHub if you’re interested in working with us here.
