By Mike Dolan, Linux Foundation
The primary activity for The Linux Foundation projects is open collaboration on technical challenges that deliver tangible improvements for developers, companies, industries, and society at large. The focus we’ve always taken is on open source code as a starting point for truly great outcomes that improve the technologies we – and the world – depend on every day.
Often that open collaboration extends beyond just open source code. Communities use events to come together to communicate what they’re working on and plan what they do next. Communities also work on tools together – systems that they use to build, test, and manage the software development lifecycle. What we also see is many communities have opportunities to improve their desired outcomes by hosting implementations of their open software project so that everyone can benefit from a running instance.
Some projects are innately more helpful by enabling open collaboration by running a shared implementation of software, in addition to making available the source code for that implementation. A prime example is the Sigstore project. Sigstore’s vision is equally as ambitious as it is simple to understand:
“Sigstore was started to improve supply chain technology for anyone using open source projects. It’s for open source maintainers, by open source maintainers. And it’s a direct response to today’s challenges, a work in progress for a future where the integrity of what we build and use is up to standard.”
But for Sigstore to achieve its vision, there needs to be a transparent, public record of supply chain artifacts. That public record is essential for enabling anyone to interrogate the record and identify and verify the signatures for software artifacts they receive (or pass along to someone else). One unique element of Sigstore is the use of ephemeral keys to sign software – which only works if there is a hosted system somewhere to validate the software a party receives against a public record signed with a key.
So from the beginning, Sigstore needs to have a running implementation for its mission to succeed. Running an instance of software then raises questions about what are the terms under which anyone can access or interact with the particular community-hosted instance of the software. Additionally, in light of regulatory considerations and users’ expectations, communities that host instances of software which will collect data from individuals need to think carefully about the data they collect and the manner in which it is made available — particularly where the intent is for the data to be stored in an immutable record.
Today we have clarified the terms that apply when users submit data to the community-hosted instance of Sigstore. We would like to share some of the changes with you to help the community better understand what we’ve put together.
- For hosted software that collects data that is intended to be stored indefinitely, the Immutable Record notice sets forth additional expectations. Particularly relevant for Sigstore, this includes the expectation that users must NOT submit data about individuals other than themselves, and clear acknowledgments about the purpose and nature of the public record.
- Finally, the Sigstore CLI tool and documentation have been updated to clarify and include notices that make reference to these terms.
These core terms have been updated on the LF Projects, LLC website to be reusable for other similarly-situated projects. The Sigstore community operates within the LF Projects, LLC framework and it was important to align policies to enable other communities that need to host online tools to do so as well. By reusing a common framework, we can empower other tools ecosystems beyond Sigstore. This has included LF Projects, LLC establishing a policy and review process (similar in nature to the Linux Foundation’s Telemetry Data Collection and Usage Policy). This new policy is based on learnings from working with the Sigstore community, to help ensure that there is a level of review of the nature of data that would be collected and made available. Future projects that are considering central hosting of a community instance of their project software will use this new process to undergo this review and obtain approval.
We hope everyone appreciates having better clarity around the use of Sigstore and the terms under which we are operating. If you have any suggestions for changes, please feel free to file an Issue or PR.