I don't suppose that trusting #sigstore to run a centralized CA and transparency logs just to issue short-lived certs for me to generate signatures is much more secure than #PGP signing using my own keys. I'm just increasing the attack surface...
The whole Googlesque philosophy of "trust us; don't be evil" is contrary to my take on information security.
But I'm also open to anyone convincing me otherwise.
Back from a multi-day-long rabbit hole:
kasseapparat now builds multi-arch images using Docker Bake, with labels, annotations, and SBOMs – all signed and attested via Cosign in GitHub Actions.
Took way more test builds than expected 🤯. Now back to the fun part: building software.
#DevOps #Cosign #SBOM #MultiArch #GitHubActions
#SigStore rzekomo: ma wiele klientów i jest łatwe w użyciu.
Rzeczywistość:
#Cosign domyślnie używa (starego?) formatu podpisu, którego najwyraźnej klient Pythonowy w ogóle nie obsługuje. Trzeba podawać `--new-bundle-format`, żeby dostać podpisy zgodne z innymi klientami.
Przy weryfikacji też trzeba podawać `--new-format`. W przeciwnym wypadku, otrzymamy zupełnie niejasny komunikat:
Error: bundle does not contain cert for verification, please provide public key
No i oczywiście znaleźć jakiekolwiek informacje jest kosmicznie trudno. Odkryłem, jak to się robi tylko dlatego, że kojarzyłem, że kiedyś na forum Pythona był na ten temat wątek, i ktoś rzucił przykładem, jak weryfikować wydania CPythona za pomocą tego wynalazku.
#SigStore claim: it has multiple clients and it's easy to use.
Reality:
#Cosign defaults to using a bundle format that doesn't seem to be supported by SigStore-python at all. You have to explicitly pass `--new-bundle-format` to create compatible signatures.
You also have to explicitly pass `--new-format` when verifying. Otherwise, Cosign will give you a completely confusing message:
Error: bundle does not contain cert for verification, please provide public key
And of course it's quite hard to find any information on this. I've realized it only because I recalled a SigStore-related thread on discuss.python.org, and a single example of using Cosign to verify CPython signatures was given there.
INBOX: it's a great day for economics #cosign
We have Sigstore `cosign` tool in Debian's NEW queue! Please help test #sigstore #cosign https://lists.debian.org/debian-go/2024/12/msg00005.html
#somf wud go pro #cosign RT @ThatBlackman10: #IfSexWasASport the word "whore" and all its variations would be replaced with the word athlete
Yeah, but then you'd run your own closed instance that wouldn’t be trusted by others and you’re back to square one of identifying which key is trusted. The system works best if everyone trusts Google, Microsoft and Github. I guess you can run your own instance in a closed corporate setting (like a custom CA) but it wouldn’t give any benefits for the wider ecosystem.
That’s how I see it, happy to be corrected by someone more intimately associated with sigstore.
All these web applications handling end-to-end encryption of user content (think @protonprivacy, @cryptpad, or even Whatsapp web) have a common flaw: the user needs to trust the javascript sent by the web servers of the provider. This situation defeats the purpose of E2EE because the point of doing encryption in the user agent is precisely that the provider does not need to be trusted.
For some reason, signed javascript has never been a thing. No transparency program (like cosign), no key commitment, no nothing. Weird. Sad and weird.
The most frequent solutions to this problem is to not use web pages: publish a mobile app, a desktop client or a web browser extension.
I've been thinking about it for a while now, and the "solution" I came up with is to use IPFS.
IPFS uses content addressing, meaning the address of a file is a hash of the content of the file. Every time you request a specific address, you get the same file. If you store that address in your bookmarks, then you are sure that you are using a specific version of the web content. If that web content is a web application (frontend) and all resources referenced in that web application are either linked using IPFS content addresses or linked via the "traditional web" with SRI hashes, then you have an integrity-verified web application.
Put that IPFS content address in a transparency program, and you have a publicly auditable log of the javascript served by the providers.
So, my request to @cryptpad and @protonprivacy is: could you please publish your frontend on IPFS?
@Elleaster #CoSign, blue in Alaska. XO
Wondering whether users of #cosign (by #sigstore) and #slsa (slsa-verifier) would have opinions on how to best make use of these verification tools when downloading binaries for use in container images?
I started a StackOverflow discussion here with more details, since I'm new to playing around with these toolchains:
Updated the #veilid rpm repo path for my container. Nice to see that we now have a nightly build as well ! If you are looking for a #veilid #container with a public build pipeline, signed with #cosign and auto released every sunday.
Checkout https://github.com/chimbosonic/veilid-container.
Container images are uploaded to #dockerhub and #quay.io
@patric and #Wolfi apparently uses #Cosign Wooo! That's perfect, because I am actually working on a type of container registry :)
It's still a glmmer in the postmans eye, but it will be spitting out containers - and signing is so important nowadays, especially when you read about security breaches like with #Polyfill
Shout outs to #Cloudflare for just redirecting all that traffic to a safe #CDN. Credit where credit is due.
Signed container images with buildah, podman and cosign via GitHub Actions: https://tim.siosm.fr/blog/2023/12/20/signed-container-images/
Explaining how I signed the Toolbx and Distrobox container images (https://github.com/toolbx-images/images) and the ones in my personal namespace on Quay.io (https://github.com/travier/quay-containerfiles) using cosign.
Securing CICD pipelines with StackRox and Sigstore https://www.opensourcerers.org/2023/10/09/securing-cicd-pipelines-with-stackrox-and-sigstore/
#cosign #sigstore #tekton #Kubernetes #cicd
🔐 Want to understand the journey of becoming a Sigstore Evangelist and contributing to open-source security?
🌟💻📖 Explore my article "𝑯𝒐𝒘 𝒕𝒐 𝒃𝒆𝒄𝒐𝒎𝒆 𝒕𝒉𝒆 𝒏𝒆𝒙𝒕 𝑺𝒊𝒈𝒔𝒕𝒐𝒓𝒆 𝑬𝒗𝒂𝒏𝒈𝒆𝒍𝒊𝒔𝒕?" and uncover the fascinating history and insights.
https://blog.sigstore.dev/how-to-become-the-next-sigstore-evangelist-9303ed297e54/
🚀 Exciting News! We've just released a new blog post!
📝 In this article, we explore the world of software supply chain security, offering insights into how to safeguard the integrity of your binaries and container images using two powerful tools! ⚡️
💃 Dive into the capabilities of SLSA provenances for enhanced security.💻
👏 A big shoutout to @furkanturkaI and @caarlos0 for their invaluable contributions!
https://goreleaser.com/blog/slsa-generation-for-your-artifacts/
#SLSA #DevSecOps #OpenSource #goreleaser #slsaverifier #cosign 🌟
Gave a lightning talk on Sigstore's policy controller over at the Wellington OpenShift meetup today
Here's a link to the slides!
#wellington #sigstore #openshift #securesoftwaresupplychain #cosign
