GnuPG doet zelf ook niet meer aan keyservers. Bovendien worden de keyservers aangevallen de laatste tijd door ze te overspoelen met willekeurige publieke sleutels. https://lists.gnupg.org/pipermail/gnupg-devel/2021-June/034889.html

Maar GnuPG functioneert gelukkig ook zonder keyservers. Je zou je publieke sleutel bijvoorbeeld op een website kunnen zetten. Of meer modern, op social media.

Python heeft zelf ook problemen met aanvallen op de servers waar de libraries op staan. https://www.security.nl/posting/764872/Opnieuw+malafide+Python-packages+in+PyPI+die+inloggegevens+stelen. Dit lijkt op de problemen die keyservers hebben. Namelijk dat je ze niet meer kunt vertrouwen. Dus ook stoppen met Python?

Iedereen, ook crininelen, kunnen een asymmetrisch sleutelpaar genereren, daar bijv. software digitaal mee ondertekenen en de public key uploaden naar een keyserver.

Dat een PGP public key (samen met een unieke identifier -vaak een e-mailadres- in een soort certificaat), verder "kaal" of voorzien van waardeloze en misleidende "Web of Trust" signatures (https://en.wikipedia.org/wiki/Web_of_trust), op een keyserver staat, zegt dus helemaal niets.

Meestal zal, op z'n minst één, door jou vertrouwde derde partij (TTP), met een minimale betrouwbaarheid, moeten hebben vastgesteld dat de unieke identifier toebehoort aan de entiteit die rechtmatig toegang heeft tot een private key passend bij de betreffende public key, voordat die TTP -middels een digitale handtekening- aangeeft dat een public key en een unieke identifier daadwerkelijk bij elkaar horen.

Als die entiteit een mens claimt te zijn en de unieke identifier een e-mailadres is (dat door iedereen kan zijn aangemaakt of kan zijn gehacked) zegt dat nog weinig tot niets. Meestal zijn aanvullende identificerende gegevens nodig, die door de TTP moeten zijn geverifieerd (met minimale betrouwbaarheid) en zijn opgenomen in het (daarna door de TTP ondertekende) certificaat.

Kortom: een digitale handtekening is schijnveiligheid als je niet zeker weet door wie exact die digitale handtekening is gezet (en hoe goed die persoon voorkómt dat diens private key in verkeerde handen valt of wordt misbruikt). Pas als je dat voldoende zeker weet, kun je gaan uitzoeken hoe de reputatie van die persoon is. En als die goed is, hopen dat dit zo blijft.

PyPi wordt weliswaar door de Python Software Foundation in de lucht gehouden, maar het is niet Python zelf en ook niet de standaardlibrary van Python.

PyPi is eigenlijk niet meer dan een prikbord waarop derden die een pakket hebben gemaakt dat wereldkundig kunnen maken. Verwacht niet dat pakketten pas worden toegelaten als ze op kwaliteit en veiligheid zijn doorgelicht, PyPi heeft maar een handjevol adminstrators en die kunnen dat echt niet voor honderdduizenden pakketten bolwerken. Ze kunnen reageren op meldingen dat iets malware is of bevat door het te verwijderen, maar verwacht geen wonderen in het voorkomen ervan.

Je kan PyPi dus gebruiken om op het spoor te komen van pakketten die mogelijk nuttig voor je zijn, maar denk niet dat je je huiswerk niet hoeft te doen en blind kan vertrouwen op de kwaliteit en betrouwbaarheid ervan.

En dat zegt niets over de kwaliteit en betrouwbaarheid van Python (de taal, de standard library) zelf. PyPi gaat over pakketten van derden.

Dit geldt net zo goed voor soortgelijke package repository's voor andere talen. Besef wat je gebruikt en besef dat het aan jou zelf is om te overzien of wat je gebruikt eigenlijk wel deugt. Het is heel fijn dat je als ontwikkelaar niet alle wielen zelf opnieuw hoeft uit te vinden, maar bedenk wel dat je zelf verantwoordelijk bent voor de betrouwbaarheid en veiligheid van wat je binnen haalt, en dat dat eigenlijk impliceert dat wat je allemaal binnen sleept niet zo groot mag worden dat je het niet meer kan overzien.

PyPI accepteert weer nieuwe projecten na golf van malafide packages
maandag 22 mei 2023, 12:06 door Redactie

https://www.security.nl/posting/796970/PyPI+accepteert+weer+nieuwe+projecten+na+golf+van+malafide+packages


Nu PyPI is gestopt met PGP-signatures is men aan de wolven overgeleverd.

De site PyPi is dan wel een smet op de programmeertaal Python. Vanwege hun onkunde met PGP die uit het artikel blijkt. Ik heb keyservers altijd gemeden met PGP omdat ik niet mijn e-mail adres makkelijk toegankelijk voor spammers wil hebben. Encrypted spam..

Anoniem 15:09

In de tijd van Phil Zimmermann werd het toch aangeraden om digitale vingerafdruk van de uitgewisselde publieke sleutels o.a. telefonisch met elkaar te verifiëren.

Het hele web of trust model gewoon niet schaalbaar gebleken.
Natuurlijk kan Some Dev z'n key op een/ (is het z'n ? ) SomeDev94 twitter profiel zetten .
Het verlegt de vertrouwensvraag naar de beveiliging - en eigendom - van het betreffende social media account, of persoonlijke website .
En/of het hebben van een keten van signatures waarmee een derde partij kan valideren dat die key van de echte Some Dev is .

Voor mij als eventuele gebruiker van enkele PyPi packages zou ik misschien die moeite doen, om all die verschillende keys van al die verschillende "logische" plaatsen op te halen, en dat misschien nog een paar keer voor signatures op de key die ik ook al niet ken totdat je dan genoeg om te vertrouwen dat de keten klopt.


Ik heb maar de hoop (terecht? ) dat het build team van een distributie behoorlijk checked dat ze de echte/goede versie van een taal + de modules die ze ervan opnemen in de distributie goed checken .

Ja, dat was de aanname dat je degene van wie je een sleutel kreeg (of tekende) ook persoonlijk kende, zodat je op basis van een telefoongesprek _kon_ beslissen dat je met "de echte" sprak , en zodoende de sleutel accepteren.

Vertel eens, hoe stel je je dat voor in het geval van een willekeurige python package ?
En verder : stel dat JIJ een package zou maken, zet je daar dan ook je telefoonnummer bij ?

Onkunde is wel heel arrogant .

Leg eens uit wat je dan precies verwacht dat "de site" PyPi dan had moeten doen met PGP om het wel te laten werken voor al hun packages en al hun devs ?

Er zijn verschillende manieren om PGP te gebruiken.

Vroeger zat PGP 2.x in een .zip bestand. Daarop zat een detached signature en die twee bestanden zaten weer in een .zip bestand.

Bij GnuPG staan het archief en de detached signature apart op hun download server.

Bij Ubuntu en Mozilla is er één SHA256SUMS.txt bestand met alle hashes van alle bestanden, en daar is weer een detached signature op gemaakt.

Een groot voordeel van PGP is dat je meteen een e-mail adres hebt voor responsible disclosure. Dit hoeft niet het e-mail adres te zijn dat je ook privé gebruikt maar mag speciaal zijn voor vulnerabilities (met E2E encryptie).

Anoniem 15:09

Je laat nu alleen maar je onkunde zien voor het werkelijke probleem dat PyPi heeft met gesignde packages.
Dat heeft allemaal niks te maken met wat je hier beschrijft als gebruiks mogelijkheden.

Terwijl het artikel al een paar prima links had naar uitleg met _wat_ er niet werkt, en waarom "hetzelfde als wat Linux distro's doen" voor hen geen oplossing is.
Lees dat eens, en roep dan nog eens wat ze 'gewoon' moeten doen .

Ik heb een van de links gelezen waarop de keuze voor het verlaten van PGP is gebaseerd, en het lijkt wel of het geschreven is door ChatGPT. De auteur lijkt niets van PGP te snappen. Wat zijn 'binding signatures'? In PGP heb je geen CA, dat is de kracht van PGP. Een PGP sleutel hoeft ook niet naar een persoon te wijzen. Iets als "Ubuntu CD Image Automatic Signing Key" is genoeg.

Ook is het erg vals om 1024 bit signing keys van PGP aan te halen. DH/DSS sleutels waren voor het verlopen van het patent op RSA in Amerika de norm voor nieuwe PGP sleutels en de DSA component van 1024 was de standaard omdat de Amerikaanse overheid toen dacht dat dat genoeg was. Meer was niet mogelijk volgens de Amerikaanse standaard.

Mijn grootste vraag is, wat komt er voor PGP in de plaats wat wel makkelijk en gebruikersvriendelijk is? Hoe controleer je dat een overheid niet je source code heeft aangepast na het uploaden naar PyPi? Met PGP is deze controle triviaal. Zolang je private key veilig is.

Is S/MIME wel makkelijk en transparant in het gebruik?

Anoniem 15:09

Ja - wanneer je - net als Ubuntu - een heel build & maintain team hebt dat al die programma's die ze mee packagen ophaalt, build en valideert dat ze de echte source van de echte auteur hebben, en ook nog dat het geen malware is .

*Dan* tekent Ubuntu zelf alle packages, en de hele distributie - en neemt, als Ubuntu project - een forse verantwoording *dat* wat ze op die basis distribueren de "originele" versie is, eventueel met eigen Ubuntu patches, en ook nog dat de betreffende packages 'betrouwbaar' zijn .
Datzelfde doet Oracle/Redhat voor hun distro , en doet het Debian project .

Dat is ook precies wat ik (en heel velen met mij) verwachten van een distro, en waarom ik "third party repositories" zelden of nooit gebruikt - want min of meer iedereen kan wel een .rpm/.dpkg bakken van iets, maar dat is garantie tot eth0 .

Is het echt zo moeilijk om in te zien hoeveel werk _dat_ deel is ? *Als* je dat allemaal gedaan hebt, is het technisch valideren/tekenen ervan ook echt niet moeilijk , *door een distributie* .
Dus heb je - als gebruiker van een distro - ook alleen te maken met de Ubuntu distro signing key , als je die (op basis van TLS) ophaalt van ubuntu.com ben je wel fors zeker dat je precies krijgt *wat de ubuntu packager* getekend heeft .

De term 'binding signature' is/was me ook niet helemaal duidelijk - uit de context lijkt het te gaan om
1) niet self-signed
2) nul actieve signatures -

Dan kun je wel gaan miepen dat "geen CA" de kracht van PGP is - maar effectief zegt een PGP key met een naam/identiteit erin en verder niks ook *helemaal niks* .
Wat moet je - wanneer je wilt weten of een package van een bepaalde persoon is, als je een PGP key hebt met de naam van die persoon erin ? En dan ?
Dat een groot deel van die keys dan publiek onvindbaar zijn is ook wel een teken dat geen hond er iets mee doet .


Wat voor excuus is dat in 2023 ?
Alleen maar een signaal van "bitrot" - het kan de gebruiker/eigenaar van z'n key duidelijk niks (meer) schelen wanneer je dat nog gebruikt als signing key .


Nog steeds snap je er niet veel van.

Hoe controleer ik nou dat JOUW package onveranderd is als ik JOUW key , met een goede keten van signatures zodat ik kan weten dat het ECHT JOUW KEY is - helemaal nergens kan vinden ?
Want dat is de situatie van een enorm percentage "gesignde" packages op PyPi - leg nog eens wat de onkunde is van PyPi daarin ?

Verder - in de context van package validatie - jouw key is eigenlijk alleen maar goed om te tekenen voor jouw package.
Als ik 'gewoon' jouw key in een keyring hebt , kun jij evenzeer tekenen voor gcc, llvm, linux.image - dat is niet de bedoeling.
En als je verwacht dat "het Pypi project" al die validatie doet - automatisch ? - is dat al helemaal niet de bedoeling .

Ik zie - voor het soort probleem dat PyPi heeft - geen oplossing met alleen maar een andere tool.

Je wilt een betrouwbare koppeling tussen de identiteit van een willekeurige 'contributor' en een bepaalde public key.
En dan wil je daarnaast dat die bepaalde public key vertrouwd is om alleen de software van die willekeurige contributor te valideren als "onveranderd" .

https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/
legt dat netjes uit. Jij hangt op 'the boring easy part' , (tools om een signature te maken of te controleren).
en het hele probleem dat (oa) PyPi heeft volgt daaronder.

De linux distro's lossen dat op door feitelijk de hele keten van alle controle verantwoordelijkheden op zich te nemen, en de oorspronkelijke developer van een bepaald package staat min of meer alleen in de readme en sources.
Maar alle crypto signatures valideren dat ik krijg/heb wat "het Ubuntu project" op de "very secure Ubuntu build server" gemaakt heeft ; Of het nu gcc, llvm,python, of een van de standaard python packages is .
En daar hebben ze een fors team voor - die hopelijk - netjes en goed hun best doen om te valideren de bron-sources die ze gebruiken "de echte" zijn.

Wanneer je - zoals PyPi - alleen maar een verzamel plaats bent waar iedere jan lul dev dingetjes kan neerzetten zie ik geen manier waarop PyPi - (of ik als gebruiker) die controles altijd goed kan doen voor de hele verzameling packages.
Een CA gebaseerd systeem is ook zo goed als de controle op de identiteit van de certificaat houder , en dat heeft ook de nodige beperkingen . Evenzeer blijft , zonder een forse berg tooling , ook het probleem om de trust voor een bepaald certificaat te beperking tot het package waar die developer over gaat .

(tsja, iemand kan gaan dromen over een digitale europese identiteit, als bron voor persoonlijke public keys met een behoorlijk trusted koppeling tussen identiteit en een bepaalde key . Effectief is dan een overheid de CA.
Je zou kunnen zeggen dat bij PGP eigenlijk ook al gold - het normale advies voor keysigning parties was om paspoort/rijbewijs te controleren voordat je iemands key sign-de .
Je moet maar hopen dat degen die signed ook wel redelijk in staat was om een nep-ID te herkennen, en dan ook nog de ballen had om iemand in z'n gezicht te zeggen "je paspoort lijkt me vals dus ik ga jouw key niet signen" .
Beveiligers en KMAR krijgen er echt les in , valse IDs herkennen.
Heb je echt zorgen over overheids inmenging - die kunnen , net als makro maffia , gewoon een echt vals paspoort regelen.
)

Ik heb het toch kunnen vinden in RFC 4880 (OpenPGP). Type 0x18 en 0x19 zijn 'binding signatures'. Ik had niet verwacht dat die een los nummer zouden hebben omdat je gewoon kan zien wie de 'binding signature' gezet heeft. Namelijk de primary of the sub key. Of zie ik het te simpel? Als je niet met het editen van je public key zit te kloten, zouden die er gewoon moeten staan.


Dit zijn de Ubuntu signing keys van mijn keyring:

Tot na 2012 (April) had Ubuntu een DH/DSS sleutel. Vanwege legacy. Omdat Ubuntu LTS vijf jaar geldig is (voor bedrijven zelfs meer geloof ik), is tot in 2017 de 'bitrot' sleutel van Ubuntu in gebruik geweest.

Nu heeft Ubuntu ook problemen met het distribueren van hun signing keys omdat ze alleen een long Key ID geven, en dat is niet genoeg in mijn ogen om zeker te weten dat je de juiste key gebruikt. De fingerprint plus de modulus size was vroeger gebruikelijk. Vanwege een fout in PGP 2.x.

Anoniem 15:09

Ah, nice. Thx. Ik had niet zo uitgebreid gezocht.

Mijn _indruk_ (zonder uitgebreid testen ) van de tekst is dan hetzelfde . En als dat klopt kun je inderdaad wel zeggen dat het onbreken van z'n binding signature inderdaad wel raar is . De analyse van die yossarian blogger dat het 'validatie ecosysteem' voor PyPi heel hard faalt is dan wel terecht.

Ik kwam nu (weer ? weet niet meer of ik dit eerder las) https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ . Oef. (Mathhew Green is iemand die echt wel snapt Hoe Het werkt ) - .Niet gerealiseerd dit het _zo_ klote was.


De pech van een traag veranderend ecosysteem.
Nu is het nog simpel om voor een distributie om meerdere keys (of meer hashes) te gebruiken voor image signing.

Ik heb ook wel MD5 gebruikt om install images te checken , als ik ter plaatste niks beters bij de hand/geinstalleerd had.
Prettig dat ze (zo'n beetje alle distro's ) _ook_ een MD5 hash meegaven, naast betere hashes.


Waar baseer je je validatie van die key verder op ? Met of zonder fingerprint+modulus, je leest het ergens op z'n manier dat je gelooft dat dat "de echte" is , en niet de fingerprint van een MITM key .
Persoonlijk krijgen van de bron die je kent - of wiens paspoort je bekijkt is één manier, maar mijn kennisenkring reikt niet tot een rechtstreeks contact met een Ubuntu security officer.
Of welke keten van signatures moet erop zitten voor een link door het web of trust naar jou toe ?

Mijn 'trust-bootstrap' is dat de key in het install image zit , ik de SHASUM van dat install image controleer via de (HTTPS) site van de distributie bron .

Ik heb even gekeken, maar ik zag niet meteen of je gewoon de hele Ubuntu signing key kon downloaden van een (https) ubuntu.com site . (waarmee je dus je trust baseert op TLS+ goed beheer door Ubuntu )

Ubuntu webteam schrijft https://discourse.ubuntu.com/t/how-to-verify-your-ubuntu-download/14010/18 .
Je kunt de key halen van de "ubuntu keyserver" , maar (zo lijkt het) met een http key fetch protocol.
Ik verwacht wel dat de "ubuntu keyserver" geen valse ubuntu keys met hetzelfde key id zal accepteren, alleen een hypothetische superman-in-the-middle kan dat , denk ik, manipuleren in je download.
Of een long keyID nog collision-free is weet ik niet.
Zo ja , dan is het , m.i. net goed genoeg wanneer je het long keyID leest van een trusted bron, en dan controleert dat dat keyID in je keyring is wat je in de "trusted source" meekreeg als "het" keyID .


Bij elkaar denk ik dat 'install image met buildin gpg key" + checksum validatie van image met checksums van 'officiele distro pagina via TLS' ongeveer het beste zijn wat je reeel kunt doen . Voor iets als een Linux distributie .

En datzelfde model werkt niet voor een "losse verzamelsite van spul dat jan en allemaal kunnen aanbieden" zoals PyPi , waar de "verzamelsite" niet de controle/validatie verantwoording neemt of kan nemen zoals een distributie wel doet voor al hun packages.

Ik haal de fingerprint van https://ubuntu.com/tutorials/how-to-verify-ubuntu#4-retrieve-the-correct-signature-key. Deze zit ergens in de tekst.

Het is wel een Let's Encrypt certificaat, maar je kunt niet alles hebben. Als Microsoft of Google een Let's Encrypt certificaat voor zoiets zouden gebruiken dan zouden we dat niet accepteren.

De PGP sleutel van Ubuntu zal ik idd wel ergens van een keyserver hebben gehaald. Vroeger gebruikte ik altijd die op mit.edu via het web, maar ik geloof niet dat die nog bestaat. Daar kon je ook de Amerikaanse versie van PGP downloaden vroeger.

Verder haal ik de SHA256SUMS.txt van twee verschillende mirrors. In verschillende landen. Dat geeft mij een voldoende gevoel van veiligheid.

PGP maakte er vroeger een punt van dat je niet de signature op de PGP software moet verifiëren met de versie die je net gedownload had. GnuPG doet dit nog steeds.

Anoniem 15:09