Login

Recent searches

No recent searches

Search options

Only available when logged in.
fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

fosstodon.org: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.5

#sigstore

0 posts0 participants0 posts today
Public
mgorny-nyan (on) :autism:🙀🚂🐧

Jakiś czas temu zaimplementowałem w #Gentoo wsparcie #SigStore, by móc weryfikować nowe wydania CPythona. Dziś dowiedziałem się, że #PyPI również obsługuje takie "poświadczenia". Tylko jak je weryfikować?

blog.sigstore.dev/pypi-attesta

Ten post sugeruje, że na blogu PyPI znajdę "detale istotne dla użytkowników". No więc zajrzyjmy tam.

blog.pypi.org/posts/2024-11-14

Tylko informacje o publikowaniu i przeglądaniu ich (a sposób wymieniony tam nie jest właściwą odpowiedzią na pol.social/@mgorny/11405397625), a nie weryfikacji. Szukamy dalej.

docs.pypi.org/attestations/

Tylko linki do kilku technicznych specyfikacji, nic przydatnego.

docs.pypi.org/attestations/con

O, tu w końcu jest jakiś przykład. Sprawdźmy podlinkowany projekt.

pypi.org/project/pypi-attestat

> [!WAŻNE] Ta biblioteka stanowi szczegół implementacji wewnątrz referencyjnej implementacji PEP 740. Większość użytkowników nie musi korzystać z niej bezpośrednio; więcej szczegółów w dokumentacji PyPI. [tłum. własne]

Tyle że ten link prowadzi do strony ze specyfikacjami! Jak jeszcze trochę pokopiemy, to możemy znaleźć API, które dostarcza nasze "poświadczenie":

docs.pypi.org/api/integrity/

No fajno, tylko co z nim zrobić? Przeskoczmy pół godziny wprzód, które zmarnowałem, próbując go użyć. Pokrótce rzecz biorąc, jedyne co pypi-attestations może zrobić jest pobranie interesującego nas pliku i danych "poświadczenia" *wprost z serwera*, i zweryfikowanie go. Więc trzeba używać dodatkowego narzędzia, które dodatkowo zawsze korzysta z Internetu.

A przynajmniej tak sądzę, bo nie brak wszędzie słów "eksperymentalne", a dokumentacja chyba już gorsza być nie może. No cóż, zgłosiłem prośbę o weryfikację w trybie offline, zobaczymy:

github.com/trailofbits/pypi-at

blog.sigstore.devPyPI's Sigstore-powered attestations are now generally available - Sigstore Blog
#Python#bezpieczeństwo
Public
mgorny-nyan (he) :autism:🙀🚂🐧

So, a while ago I have implemented #SigStore support in #Gentoo, to be able to verify release artifacts for CPython releases. Today, I've learned that the "attestations" are supported on #PyPI now as well. But how to verify them?

blog.sigstore.dev/pypi-attesta

This post suggests that PyPI blog covers the "user-facing details". So let's check that.

blog.pypi.org/posts/2024-11-14

But that just covers publishing and viewing them (and the way listed here is not the answer to social.treehouse.systems/@mgor), not verifying. So let's try searching further.

docs.pypi.org/attestations/

Okay, this just links to a bunch of specifications, nothing useful for us here.

docs.pypi.org/attestations/con

Okay, this one finally provides a snippet. Let's take a look at the project then.

pypi.org/project/pypi-attestat

> [!IMPORTANT] This library is an implementation detail within the reference implementation of PEP 740. Most users should not need to interact with it directly; see the PyPI documentation for full details.

But that just takes us back to the bunch of specifications! If we dig some more, we find the API needed to get the "provenance" file we need:

docs.pypi.org/api/integrity/

Well, that's cool, but what can we do about it? Well, let's skip the half an hour I've wasted trying to do anything about it. Long story short, the only thing you can do is have pypi-attestations fetch both the distribution file and the provenance data *straight from the server*, and verify it directly. So you need an extra tool, and the tool is 100% online.

Or at least I guess so, because it's all full of "experimental" and the documentation is as bad as it could get. Well, filed a bug anyway, hopefully I'll learn more:

github.com/trailofbits/pypi-at

blog.sigstore.devPyPI's Sigstore-powered attestations are now generally available - Sigstore Blog
#Python#security
Public
mgorny-nyan (on) :autism:🙀🚂🐧

Zagadka na #PyPI: jeden z poniższych projektów używa "zaufanego procesu publikacji" (czyli podpisów elektronicznych #SigStore), a drugi nie. Jesteście w stanie odgadnąć który, i w jaki sposób można to stwierdzić? I owszem, jest to widoczne od razu na pierwszej stronie, nie trzeba nigdzie głębiej wchodzić.

pypi.org/project/ansible-keyri
pypi.org/project/sampleproject

Proszę dawać CW na odpowiedzi, żeby nie psuć innym zabawy. A jeżeli nie potraficie odgadnąć, nie szkodzi — to jeden z najgorszych pomysłów na #interfejs, jakie widziałem.

pypi.orgClient Challenge
#Gentoo#Python
Public
mgorny-nyan (he) :autism:🙀🚂🐧

A #PyPI riddle: one of the following projects is using trusted publishing (i.e. #SigStore signatures) and the other isn't. Can you tell which one does, and how can you tell? And yes, it's visible immediately on the top project page, you don't have to click anything.

pypi.org/project/ansible-keyri
pypi.org/project/sampleproject

Please CW your answers not to spoil. And if you can't, don't worry — this is one of the most horrible #UI ideas I've ever seen.

pypi.orgClient Challenge
#Gentoo#Python#packaging
Replied to Todd A. Jacobs | Rubyist
Public *
bignose

Agreed @todd_a_jacobs.

To head off anticipated objections "but PEP 761 doesn't *mandate* using or ": Technically true, but there's no open implementation is willing to rely on today.

PEP 761 steps *backward* from open technology (though imperfect) to a closed platform (even more imperfect).

If were a good idea, it should not have replaced existing open implementations until it also has reliable open implementations. If that's infeasible, why switch to it?

Public
Todd A. Jacobs | Rubyist

I’m *trying* to like #Python again, but PEP-761 requires #sigstore. #OpenPGP key management has issues, but this requires trusting #openidconnect from #Google & #Microsoft. Plus there’s a stated design goal of supporting automated signatures from private keys held by #GitHub.

Easier? Probably. Safer? Probably not. Security is about trust and the required certificate authorities haven’t earned mine over the past 20 years. As always, YMMV.

peps.python.org/pep-0761/

Python Enhancement Proposals (PEPs)PEP 761 – Deprecating PGP signatures for CPython artifacts | peps.python.orgSince Python 3.11.0, CPython has provided two verifiable digital signatures for all CPython artifacts: PGP and Sigstore.
Public
mgorny-nyan (on) :autism:🙀🚂🐧

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

Public
mgorny-nyan (he) :autism:🙀🚂🐧

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

Public
Beth Pariseau

#Sigstore creator, #Chainguard CEO, #OpenSSF TAC member and Season 1 guest Dan Lorenc returns to the #ITOps Query podcast to discuss the year in #opensource and #cybersecurity. Topics range from #softwaresupplychain management, hardening #containerimages and #SBOMs in limbo to #openproduct companies and business models, including his own company's shift in focus this year. Plus: a look ahead to #SecOps and #AI in 2025. #yearinreview #2024yearinreview

podbean.com/ew/pb-ivy26-1778bf

www.podbean.com2024 in review and 2025 predictions with Dan LorencSigstore creator, Chainguard CEO, OpenSSF TAC member and Season 1 guest Dan Lorenc returns to discuss the year in open source and security. Topics range from software supply chain management, hardening container images and SBOMs in limbo to open product companies and business models, including his own company's shift in focus this year. Plus: a look ahead to SecOps and AI in 2025. 
Replied in thread
Public
meejah

@yossarian @whynothugo It does at least "cement" GitHub as _the_ identity-provider.

Am I not being made a second-class PyPI publisher already, because I have nowhere to put my signatures, and no way to use my own identity?

#pypi #python #sigstore

Again, there's sort of a "self-fulfilling prophecy" here (like with signature deletion), because the only way to "publish from CI" is via GHA. And since there's no _other_ way to do it, of course a bunch of users end up using it.

ExploreLive feeds
About