Capability for GitLab CI/CD to sign artifacts
Problem to solve
As a developer who uses GitLab CI/CD to build packages, I want a capability to have GitLab sign artifacts as an attestation of GitLab's having built that artifact so that I don't have to manage my own signing keys.
Intended users
Anyone who uses packages that are built with GitLab CI/CD and wants to automatically determine that they were really built by GitLab.
User experience goal
The goal is to have a minimum level of assurance that artifacts haven't been tampered with by the time they are installed. By having the capability to have GitLab CI/CD sign artifacts it produces, that's one less thing for many different CI/CD users to manage or configure. Additionally, by having a centralized signing capability, greater security is possible. In particular, if I want a hardware security module to sign my packages, I can't currently automate that.
The user should be able to identify types of artifacts that a CI/CD pipeline produces and configure the pipeline to sign them. Different package types have different signing mechanisms, and that's more easily gotten right centrally.
Proposal
My experience is mostly with signed RPMs and how that works. We are reluctant to install unsigned packages, but some software packagers don't have the experience or the means to do package signing correctly. (For instance, there are very subtle differences between how RPMs are signed for RHEL 7 and RHEL 8.)
As a consumer, it's hard to convince my organization that a particular unsigned RPM is OK - how do we know that the package is authentic? There's a similar problem with garden-variety signing keys. If someone without a significant reputation signs a package, how do we know that someone hasn't compromised the key for the sole purpose of publishing tampered packages?
Further details
It's important to note that having GitLab sign packages (such as RPM) would only be a statement that GitLab CI/CD actually build the package and doesn't make any statement about the repute of the package itself. (Similarly, I know of bots that will sign someone's GPG key automatically based on web credentials. The amount that such a signature should be trusted only goes so far.)
Ideally, the signing capability could add metadata to the package (or its signature) to identify which job built the package.
Permissions and Security
This would be part of the general CI/CD configuration.
Documentation
Availability & Testing
This would require updates to CI/CD documentation.
What does success look like, and how can we measure that?
The success metrics are how many packages are being signed and how often GitLab's public keys are accessed, which indicates that end-users are verifying the authenticity of packages. The acceptance criteria are that it's easy to configure a CI/CD pipeline to sign packages before publishing them.
What is the type of buyer?
The biggest buyer would be organizations that want to add additional security to the packages they build with GitLab CI/CD for others to consume. As an add-on, GitLab could manage custom signing keys for enterprise customers.
Is this a cross-stage feature?
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.