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.

#cosign #rekor #flucio

#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.

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?

#javascript #cosign #e2ee #ipfs