Python Package Index ondersteunt digital attestations voor signeren packages
De Python Package Index (PyPI) ondersteunt voortaan digital attestations als manier om packages te signeren, zo is gisteren aangekondigd. Attestations zijn digitaal gesigneerde, publiek verifieerbare statements over Python-packages, waaronder de exacte source repository waarvandaan ze afkomstig zijn. Ze zijn gebaseerd op de Python-standaard PEP 740. Afhankelijk van verschillende voorwaarden, waaronder gebruik van GitHub Actions voor de publicatie van een package, worden de attestations automatisch gegenereerd en gepubliceerd. Iets wat volgens critici GitHub als publicatieplatform bevoordeeld.
De Python Package Index is een repository voor de Python-programmeertaal en bevat allerlei door de Python-community ontwikkelde packages. Om gebruikers meer zekerheid over de integriteit en authenticiteit van een package te geven konden ontwikkelaars via PGP hun package van een digitale handtekening voorzien. Hiervoor wordt gebruikgemaakt van private-public key cryptografie, waarbij er een public key beschikbaar moet zijn om de signature te verifiëren. Dergelijke keys zijn vaak via public key-servers te vinden.
Vorig jaar besloot PyPI de support voor PGP-signatures te stoppen. Uit onderzoek bleek dat een groot aantal keys niet beschikbaar was op een grote public key-server, waardoor het zo goed als onmogelijk was om de digitale handtekening te controleren. Een ander probleem waar ontwikkelaars volgens PyPI mee te maken kregen was het verliezen of de compromittering van hun keys.
Om ontwikkelaars toch de mogelijkheid te bieden hun packages te signeren ondersteunt PyPI nu digital attestations, dat samen met securitybedrijf Trail of Bits is ontwikkeld. Een verschil met PGP is dat attestations worden gesigneerd door een signing identity en niet een key pair. In het geval van PyPI wordt er gebruikgemaakt van Open ID Connect (OIDC) identities. "Door het signeren van attestations met identities, en niet een public/private key pair, mitigeren we de kans dat de key van een individu kwijtraakt of gecompromitteerd wordt", zegt PyPI-maintainer Dustin Ingram.
Volgens de omschrijving zouden attestations het lastiger voor een aanvaller moeten maken om een Python-package te kapen, aangezien de aanvaller dan ook toegang tot de signing identity moet krijgen. Attestations worden tijdens het uploaden geverifieerd en moeten verifieerbaar zijn om te worden geüpload. Alleen attestations met een verifieerbare signature worden toegestaan. Gebruikers kunnen daarnaast de attestations van een package controleren. Hiervoor is er een nieuwe API en een gebruikersinterface beschikbaar gemaakt.
Het genereren en publiceren van attestations gebeurt standaard voor Python-projecten die via GitHub Actions worden gepubliceerd. Dit is een platform voor het publiceren van software. Daarnaast moet de software via een Trusted Publisher naar PyPI worden gepubliceerd en moet de 'pypa/gh-action-pypi-publish action' voor het publiceren worden gebruikt. Alleen dan zullen de attestations standaard worden gegenereerd. Critici vinden dat deze werkwijze GitHub bevooroordeeld en de openheid van Python en PyPI niet ten goede komt.
Overigens lijkt het bij linux prima te lukken om source code digitaal te ondertekenen met PGP.
Naar Anoniem@17:23: De Linux ontwikkeling is veel strakker georganiseerd dan PyPI. PyPI is een verzameling van losse pakketten met makers die onafhankelijk van elkaar werken.
Naar Anoniem@17:23: De Linux ontwikkeling is veel strakker georganiseerd dan PyPI. PyPI is een verzameling van losse pakketten met makers die onafhankelijk van elkaar werken.
Inderdaad, ik kon ook niet meteen opmaken hoe de flow van developer tot gesigned package loopt.
En de flow van controle door een gebruiker.
En gpg signing in Linux werkt omdat het een hierarchie is.
In de zin van 'distributies' is het heel duidelijk - de distro maker signed alles, en de gebruiker hoeft (alleen) de allereerste image install op een betrouwbare manier te downloaden.
Die 'trust-bootstrap' hangt dan op TLS en het downloaden van het image (of de hash ervan) van "de echte" site van de distro.
Voor de distro-maker - die moeten van alles wat ze packagen valideren dat ze 'de echte' source downloaden. Dat zal best een stuk lastiger zijn .
De kernel (git commits kunnen gesigned worden, en Linus duwt wel om de developers dat te laten doen) hangt alleen op het onderling hebben van de keys om commits te controleren - naar boven toe. Linus wil de keys van iedereen wiens commit's hij rechtstreeks pulled - maintainers dus.
Een 'eindgebruiker' die de git repo van Linus cloned heeft feitelijk genoeg aan Linus' key. De structuur van git garandeert de integriteit van de rest van de repo.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
