Home Search
lin - search results
If you're not happy with the results, please do another search
Oracle Linux and BPF
Oracle Linux contains all of the tooling
Click to Read More at Oracle Linux Kernel Development
Adopting Sigstore Incrementally – Linux Foundation
This post is authored by Hayden Blauzvern and originally appeared on Sigstore’s blog. Sigstore is a new standard for signing, verifying, and protecting software. It is a project of the Linux Foundation.
Developers, package maintainers, and enterprises that would like to adopt Sigstore may already sign published artifacts. Signers may have existing procedures to securely store and use signing keys. Sigstore can be used to sign artifacts with existing self-managed, long-lived signing keys. Sigstore provides a simple user experience for signing, verification, and generating structured signature metadata for artifacts and container signatures. Sigstore also offers a community-operated, free-to-use transparency log for auditing signature generation.
Sigstore additionally has the ability to use code signing certificates with short-lived signing keys bound to OpenID Connect identities. This signing approach offers simplicity due to the lack of key management; however, this may be too drastic of a change for enterprises that have existing infrastructure for signing. This blog post outlines strategies to ease adoption of Sigstore while still using existing signing approaches.
Signing with self-managed, long-lived keys
Developers that maintain their own signing keys but want to migrate to Sigstore can first switch to using Cosign to generate a signature over an artifact. Cosign supports importing an existing RSA, ECDSA, or ED25519 PEM-encoded PKCS#1 or PKCS#8 key with cosign import-key-pair –key key.pem, and can sign and verify with cosign sign-blob –key cosign.key artifact-path and cosign verify-blob –key cosign.pub artifact-path.
Benefits
Developers can get accustomed to Sigstore tooling to sign and verify artifacts.
Sigstore tooling can be integrated into CI/CD pipelines.
For signing containers, signature metadata is published with the OCI image in an OCI registry.
Signing with self-managed keys with auditability
While maintaining their own signing keys, developers can increase auditability of signing events by publishing signatures to the Sigstore transparency log, Rekor. This allows developers to audit when signatures are generated for artifacts they maintain, and also monitor when their signing key is used to create a signature.
Developers can upload a signature to the transparency log during signing with COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key artifact-path. If developers would like to use their own signing infrastructure while still publishing to a transparency log, developers can use the Rekor CLI or API. To upload an artifact and cryptographically verify its inclusion in the log using the Rekor CLI:
rekor-cli upload --rekor_server https://rekor.sigstore.dev
--signature <artifact_signature>
--public-key <your_public_key>
--artifact <url_to_artifact|local_path>
rekor-cli verify --rekor_server https://rekor.sigstore.dev
--signature <artifact-signature>
--public-key <your_public_key>
--artifact <url_to_artifact|local_path>
In addition to PEM-encoded certificates and public keys, Sigstore supports uploading many different key formats, including PGP, Minisign, SSH, PKCS#7, and TUF. When uploading using the Rekor CLI, specify the –pki-format flag. For example, to upload an artifact signed with a PGP key:
gpg --armor -u user@example.com --output signature.asc --detach-sig package.tar.gz
gpg --export --armor "user@example.com" > public.key
rekor-cli upload --rekor_server https://rekor.sigstore.dev
--signature signature.asc
--public-key public.key
--pki-format=pgp
--artifact package.tar.gz
Benefits
Developers begin to publish signing events for auditability.
Artifact consumers can create a verification policy that requires a signature be published to a transparency log.
Self-managed keys in identity-based code signing certificate with auditability
When requesting a code signing certificate from the Sigstore certificate authority Fulcio, Fulcio binds an OpenID Connect identity to a key, allowing for a verification policy based on identity rather than a key. Developers can request a code signing certificate from Fulcio with a self-managed long-lived key, sign an artifact with Cosign, and upload the artifact signature to the transparency log.
However, artifact consumers can still fail-open with verification (allow the artifact, while logging the failure) if they do not want to take a hard dependency on Sigstore (require that Sigstore services be used for signature generation). A developer can use their self-managed key to generate a signature. A verifier can simply extract the verification key from the certificate without verification of the certificate’s signature. (Note that verification can occur offline, since inclusion in a transparency log can be verified using a persisted signed bundle from Rekor and code signing certificates can be verified with the CA root certificate. See Cosign’s verification code for an example of verifying the Rekor bundle.)
Once a consumer takes a hard dependency on Sigstore, a CI/CD pipeline can move to fail-closed (forbid the artifact if verification fails).
Benefits
A stronger verification policy that enforces both the presence of the signature in a transparency log and the identity of the signer.
Verification policies can be enforced fail-closed.
Identity-based (“keyless”) signing
This final step is added for completeness. Signing is done using code signing certificates, and signatures must be published to a transparency log for verification. With identity-based signing, fail-closed is the only option, since Sigstore services must be online to retrieve code signing certificates and append entries to the transparency log. Developers will no longer need to maintain signing keys.
Conclusion
The Sigstore tooling and infrastructure can be used as a whole or modularly. Each separate integration can help to improve the security of artifact distribution while allowing for incremental updates and verifying each step of the integration.
Linux tool alternatives, configuring firewalls, and more sysadmin tips
Check out Enable Sysadmin's top 10 articles from July 2022.
Read More at Enable Sysadmin
The Linux Foundation Announces Keynote Speakers for Open Source Summit Europe 2022
Global visionaries headline the premier open source event in Europe to share on OSS adoption in Europe, driving the circular economy, finding inspiration through...
The American Association of Insurance Services & The Linux Foundation Welcome Jefferson Braswell as...
LISLE, IL., August 3, 2022 — The American Association of Insurance Services (AAIS) and the Linux Foundation welcome Jefferson Braswell as the new Executive...
Linux tool alternatives: 6 replacements for traditional favorites
Consider swapping Linux tools for these alternatives that provide more features and functionality.
Read More at Enable Sysadmin
How to hide PID listings from non-root users in Linux
Prevent average users from viewing your Linux system's processes with the hidepid command.
Read More at Enable Sysadmin
How to generate a Red Hat Enterprise Linux 9 image with MicroShift
Learn how to use MicroShift, an exploratory, open source project to bring OpenShift to edge computing and field-deployed devices, to generate a custom RHEL...
Linux skills: 9 tutorials to get more from your text editor
Are you getting everything you need out of your text editor? Read Enable Sysadmin's recent articles about Linux text editors to find out what...
Linux fundamentals: How to copy, move, and rename files and directories
Learn how to use the mv and cp commands to manage your Linux files and directories.
Read More at Enable Sysadmin