gitlabMar 31, 2026

Changes to packages.gitlab.com: What you need to know (opens in new tab)

GitLab is migrating `packages.gitlab.com` to a new package hosting system while keeping the base domain unchanged. Existing configurations will continue working through rewrite rules until September 30, 2026, but old URL formats, GPG key locations, network requirements, and download paths must be updated before then. New installations already use the updated formats. ## Timeline and Required Updates - The legacy PackageCloud system and UI shut down on March 31, 2026. - Backward-compatible URL rewrites will be removed by the end of September 2026. - Existing users should: - Re-run the latest DEB or RPM installation script, or update repository configuration manually. - Change the GPG key URL to `https://packages.gitlab.com/gpgkey/gpg.key`. - Allow `https://storage.googleapis.com/packages-ops` through firewalls and proxies. - Update repository mirrors and direct-download automation. - Change GitLab Runner RPM references from `noarch` to `x86_64`. ## DEB Repository URL Changes - `gitlab/*` repositories such as `gitlab-ee` and `gitlab-ce` now include the distribution codename in the URL path. - Example: - Old: `.../ubuntu/` - New: `.../ubuntu/jammy` - This produces standard Debian paths containing `dists/jammy` and `pool`. - Re-running the installation script is the simplest migration method: - DEB: `script.deb.sh` - RPM: `script.rpm.sh` - `runner/*` DEB repositories, including `runner/gitlab-runner`, are unchanged. ## GPG Keys and Installation Scripts - Replace: - `https://packages.gitlab.com/gpg.key` - With: - `https://packages.gitlab.com/gpgkey/gpg.key` - Previously saved installation scripts should not be reused; download current versions from GitLab. ## Direct Package Downloads - The old PackageCloud UI used URLs ending in `download.deb` or `download.rpm`. - The new UI links directly to the actual package paths. - Automation that scrapes the old UI or constructs these legacy URLs must be changed to use the new paths or standard package-manager repositories. ## GitLab Runner RPM Packages - Runner RPM packages that were previously under a `noarch` path have moved to `x86_64`. - This affects RPM-based systems such as EL8 and EL9. - Debian-based Runner packages are unaffected. - Update scripts or configurations that reference the old `noarch/Packages` paths. ## Firewall and Network Requirements - Package downloads now redirect to Google Cloud Storage instead of AWS CloudFront. - Permit both `packages.gitlab.com` and `storage.googleapis.com/packages-ops`. - Missing allowlist entries can cause HTTP 503 errors or connection timeouts. Existing installations should be migrated well before September 30, 2026. For new setups, following GitLab’s current installation documentation handles the changes automatically.

gpggitlabcloud-storagedeb+4

gitlabFeb 24, 2026

GPG key used to sign GitLab package repositories' metadata has been extended (opens in new tab)

GitLab has extended the expiration date of the GPG key used to sign metadata for its APT and YUM repositories. The key, fingerprint `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`, now expires on February 6, 2028, rather than February 27, 2026. Existing users may need to refresh the key, while new users can follow the standard GitLab installation instructions. ## Purpose of the Signing Key - GitLab uses GPG signatures to protect repository metadata for: - `omnibus-gitlab` packages - `gitlab-runner` packages - Repository metadata signing is separate from package signing. - The key’s expiration is periodically extended to follow security policies and reduce exposure if it is compromised. ## Required Actions - Users who configured GitLab repositories before February 17, 2026, should follow GitLab’s documentation to fetch and install the updated key. - New users do not need special steps beyond following the GitLab or GitLab Runner installation guides. - The public key can be retrieved: - From GPG keyservers using the fingerprint or associated email address - Directly at `https://packages.gitlab.com/gpg.key` ## Getting Help - Documentation explains how to verify repository metadata signatures. - Additional issues should be reported in the `omnibus-gitlab` issue tracker. Users with existing GitLab package repositories should refresh their trusted GPG key to avoid future signature-validation problems.

gpggitlabdevsecopssecurity-policies+2

gitlabFeb 20, 2026

GitLab extends Omnibus package signing key expiration to 2028 (opens in new tab)

GitLab has extended the expiration of its GNU Privacy Guard (GPG) key used for signing Omnibus packages from February 2026 to February 16, 2028. This extension ensures the continued integrity of packages created within CI pipelines while remaining compliant with GitLab’s internal security policies regarding key exposure. By opting to extend the current key rather than rotating to a new one, GitLab aims to minimize administrative overhead for users who would otherwise be required to replace their trusted keys. ### Purpose and Scope of the Key Extension * The GPG key is specifically dedicated to signing Omnibus packages to prevent tampering; it is distinct from the keys used for repository metadata (apt/yum) and the GitLab Runner. * GitLab periodically extends the expiration of these keys to limit the potential impact of a compromise while adhering to modern security standards. * The decision to extend rather than rotate was made specifically to be less disruptive to the user base, as rotation mandates a manual replacement of the trusted key on all client systems. ### Impact and Required Actions * Users who do not specifically verify package signatures or have not configured their package managers to do so require no action to continue installing updates. * Administrators who validate Omnibus package signatures must update their local copies of the public key to reflect the 2028 expiration date. * The updated key can be found on GPG keyservers by searching for the ID `98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D` or the email `packages@gitlab.com`. * A direct download of the public key is also available through the official GitLab packages repository URL. Organizations that verify package signatures should refresh their trusted GPG keys as soon as possible to ensure seamless updates leading up to the original 2026 deadline. If technical issues arise during the update process, GitLab recommends opening an issue in the omnibus-gitlab tracker for support.

gpggitlabdevsecopsapt+3

datadogJun 3, 2019

Secure publication of Datadog Agent integrations with TUF and in-toto (opens in new tab)

Datadog built a compromise-resilient CI/CD system to publish Agent integrations independently of full Agent releases. It combines in-toto for end-to-end supply-chain verification with TUF for secure key and metadata distribution. Together, these technologies ensure that users install only integrations derived from developer-approved source code, even if parts of the infrastructure are compromised. ## Independent Integration Publishing - Agent integrations were traditionally bundled into full Agent releases. - This delayed important integration updates and prevented users from trying new integrations immediately. - Datadog wanted automation to build and publish integrations on demand without fully trusting the automation itself. ## End-to-End Verification with in-toto - TLS and GPG package signatures help prevent man-in-the-middle attacks but do not protect against compromised build or publishing infrastructure. - in-toto defines the software supply chain as a fixed sequence of signed steps. - Each step records the inputs it received and the outputs it produced, allowing the Agent to verify that only authorized parties performed the required work. - The integration pipeline includes: - Developers signing Python and YAML source files. - CI/CD packaging the source into Python wheels without modifying existing wheels. - A signing step applying TUF signatures to the wheels. - The Datadog Agent verifying that the downloaded wheel matches the developer-signed source. ## Secure Distribution with TUF - in-toto does not itself provide a secure way to distribute, revoke, or replace verification keys. - TUF supplies signed, compromise-resilient metadata for: - The root of trust for wheels and supply-chain metadata. - The in-toto-defined workflow. - Public keys used to verify the workflow. - TUF protects against tampering, rollback attacks, and indefinite replay of outdated metadata. - Offline trust bootstrapping and protected developer keys are essential to the overall security model. ## Hardware-Protected Developer Signing - Developers use Yubikeys to generate and store GPG signing keys. - Private keys cannot be exported from the device, assuming correct firmware. - Signing requires both a secret PIN and physical interaction with the Yubikey. - A command-line tool integrates in-toto and GPG, preserving a convenient developer workflow while reducing key-compromise risk. ## Transparent Verification for Users - The Datadog Agent automatically invokes TUF and in-toto when downloading or updating integrations. - Users need no workflow changes under normal conditions. - If metadata, signatures, or supply-chain steps fail verification, installation is blocked and the Agent reports the failure. Datadog’s approach demonstrates that secure automated publishing requires layered controls: in-toto verifies how software was produced, while TUF securely manages the trust and distribution mechanisms needed to validate it.

gpgdatabase-designdatadogpython+4