Signera Git-commits med SSH – den gröna markeringen räcker inte ensam

För att signera Git-commits med SSH ställer du in Git på SSH-format, anger din publika signeringsnyckel och aktiverar signering. Registrera samma publika nyckel som Signing Key på GitHub. När du har skickat en signerad commit dit kan du kontrollera dess verifieringsstatus.

Verified gäller signaturen på en viss commit. För att märkningen ska ge ett tillförlitligt ursprungsspår genom projektets historik behöver du dessutom skydda den privata nyckeln och signera konsekvent från de miljöer där du arbetar.

Välj en nyckel och registrera den på GitHub

Kontrollera först din version med git --version. GitHubs instruktion för SSH-signering anger Git 2.34 eller senare och låter dig använda antingen en befintlig SSH-nyckel eller en ny nyckel avsedd för signering. En separat nyckel gör det lättare att byta signeringsnyckel utan att samtidigt ändra hur du ansluter till GitHub.

Om du väljer en separat nyckel kan du exempelvis köra ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_signing. E-postadressen är här en exempelkommentar som du byter ut; den privata nyckeln sparas i den angivna filen och den publika i filen med ändelsen .pub. Välj en lösenfras när kommandot frågar efter en. Om du använder ssh-agent kan du sedan lägga till den privata nyckeln med ssh-add ~/.ssh/id_ed25519_signing.

Öppna Settings → SSH and GPG keys → New SSH key på GitHub, välj Signing Key och klistra in hela innehållet i ~/.ssh/id_ed25519_signing.pub. En nyckel som redan används för SSH-inloggning måste registreras en gång till om den också ska användas för signering. En lyckad git push visar därför att anslutningen fungerar, men säger inget om huruvida committen signerades.

Ställ in Git och skapa en signerad commit

För exempelnyckeln anger du git config --global gpg.format ssh och git config --global user.signingkey ~/.ssh/id_ed25519_signing.pub. Git använder sökvägen till den publika filen för att hitta rätt signeringsnyckel; den motsvarande privata nyckeln måste vara tillgänglig när du skapar en commit. Använder du ett annat filnamn ska sökvägen ändras i kommandot.

Slå på signering som standard med git config --global commit.gpgsign true. Inställningen gäller Git-arkiv som använder din globala konfiguration på den datorn. Vill du använda en annan nyckel i ett visst arkiv kan du där ange git config --local user.signingkey /sökväg/till/nyckel.pub. Kommandona git config --show-origin --get user.signingkey och git config --show-origin --get commit.gpgsign visar både värdet och vilken konfigurationsfil det kommer från.

Efter git add skapar git commit -m "Beskriv ändringen" en signerad commit när automatisk signering är aktiv. För en enstaka commit kan du i stället använda git commit -S -m "Beskriv ändringen". Om Git inte kan använda nyckeln, kontrollera att .pub-sökvägen finns och att den tillhör den privata nyckel som är tillgänglig lokalt eller via ssh-agent. Kontrollera inställningarna i den miljö som faktiskt skapar committen, exempelvis om du växlar mellan terminal och en grafisk Git-klient.

Kontrollera signaturen och hitta en oregistrerad nyckel

Direkt efter committen visar git cat-file -p HEAD commitobjektets innehåll. Finns ett gpgsig-fält har objektet en signatur, men kommandot avgör inte om nyckeln är betrodd. För lokal verifiering med git verify-commit HEAD behöver Git också en fil angiven via gpg.ssh.allowedSignersFile. Filen innehåller betrodda publika SSH-nycklar med en identitet före varje nyckel; den lokala tillitslistan hämtas inte automatiskt från ditt GitHub-konto.

Skicka committen med git push och öppna dess status i GitHubs commitvy eller under Commits i en pull request. Öppna statusmärkningen för detaljer. Om objektet har en signatur men visas som Unverified, jämför nyckeln som anges av git config --get user.signingkey med den publika nyckeln under kontots Signing keys. Kontrollera att den registrerades som signeringsnyckel och på rätt konto, särskilt om du använder flera GitHub-konton.

Saknas gpgsig-fältet, kontrollera commit.gpgsign i det aktuella arkivet och hur just den committen skapades. Om signaturen finns men den publika nyckeln inte är registrerad, lägg till rätt nyckel och granska statusen igen. En redan publicerad commit bör inte skrivas om som ett rutinmässigt felsökningsförsök: omskrivning ändrar commit-id och kan påverka andra som arbetar på samma gren.

Vad Verified säger om ursprunget

Enligt GitHubs beskrivning av verifieringsstatus betyder Verified att en signerad commit har verifierats; en signerad commit som inte kan verifieras får Unverified, medan en osignerad commit normalt saknar status. GitHub kan också signera commits som skapas i webbgränssnittet. Märkningen ensam visar alltså inte att utvecklaren använde sin lokala SSH-nyckel.

GitHub sparar verifieringsbeslutet tillsammans med committen. Inom samma nätverk av arkiv behåller en tidigare verifierad commit sin status även om nyckeln senare roteras eller återkallas; den gamla committen verifieras inte om enbart på grund av nyckeländringen. Tidsstämpeln för verifieringen kan visas vid märkningen. För en äldre commit är det därför relevant när verifieringen gjordes och vem som kontrollerade nyckeln då, särskilt om en privat nyckel senare misstänks ha röjts.

Signaturen gäller den signerade committen och nyckeln som användes. Den intygar inte kodens kvalitet och innebär inte automatiskt att personen i commitobjektets author-fält är samma person som signerade den. I projekt där sådana skillnader spelar roll behöver granskningen ta hänsyn till dem tillsammans med signaturstatusen.

Gör signering och nyckelbyte till en sammanhängande rutin

I en studie av drygt 16 miljoner offentliga GitHub-commits hade färre än 6 procent av de aktiva utvecklarna själva signerat en commit utanför plattformens webbgränssnitt. Ungefär var åttonde sådan utvecklarhanterad signatur verifierades inte, och en nyckel som saknades på GitHub var den vanligaste orsaken bland dessa fel. Resultaten beskriver studiens urval; de visar varför både registreringen och den fortlöpande användningen av nyckeln spelar roll.

En användbar projektpolicy är att signera som standard i varje lokal miljö där commits skapas, registrera respektive publik nyckel som Signing Key och kontrollera en ny commit efter en ändring av konfigurationen. Dokumentera vem som får hantera signeringsnycklar och hur en förlorad eller misstänkt röjd privat nyckel tas ur bruk. Då blir en osignerad commit ett tydligare undantag i projektets normala arbetsflöde.

Vid planerat nyckelbyte registrerar du den nya publika nyckeln, uppdaterar user.signingkey i berörda miljöer och verifierar en ny commit innan den gamla nyckeln tas ur bruk. Om bytet beror på misstänkt intrång behöver även äldre commits bedömas mot den möjliga tidpunkten för exponeringen. Deras kvarvarande Verified-status är ett historiskt verifieringsbeslut, inte ett besked om att den gamla privata nyckeln fortfarande är säker.

Läs också:

• Ett lyckat agenttest räcker inte – mät utfallet och upprepningen
• Gamla GitHub-runners stoppas – version 2.329.0 räcker inte alltid
• 500 prenumeranter räcker inte för annonsintäkter på YouTube