GitHub CLI byter signeringsnyckel – kontrollera Linuxmiljön som AI-agenten bygger i

Vilken installation berörs den 5 september?

GitHubs nuvarande PGP-nyckel för Linuxförråden löper ut den 5 september 2026. Från första releasen efter datumet signeras APT- och RPM-metadata samt nya RPM-paket enbart med ersättningsnyckeln. Det skriver GitHub i beskedet den 3 september. Det är alltså inte ett besked om att alla installationer slutar fungera vid midnatt.

Avgränsningen är de officiella APT- och RPM-förråden. GitHub undantar bland annat Windows, macOS, källkodsbyggen, Homebrew, Conda, communitypaket och installation från en direkt hämtad deb-fil eller fristående binär. Har du satt upp det officiella förrådet före den 8 april 2026 utan att uppdatera konfigurationen behöver du åtgärda det. Även en nyare egen image bör kontrolleras mot den faktiska nyckeln, enligt samma besked.

Börja i den miljö som bygger agentens verktyg. Skriv ned vilket CI-jobb, vilken Dockerfile och vilken basimage som används. Om utvecklarens dator kör macOS men bygget installerar paket i Ubuntu är det Ubuntu-steget du ska undersöka. En inventering som stannar vid din egen terminal kan därför ge fel beslutsunderlag.

Hitta APT-källan och jämför hela fingeravtrycket

På Debian och Ubuntu visar GitHubs rotationsärende, öppnat den 8 april 2026, hur du hittar nyckelringen via APT-källans signed-by. Standardplatsen är /etc/apt/keyrings/; äldre installationer kan använda /usr/share/keyrings/. Läs den fil som konfigurationen faktiskt pekar på:

cat /etc/apt/sources.list.d/github-cli.list
gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg

Den nya nyckelns fullständiga fingeravtryck är 7F38BBB59D064DBCB3D84D725612B36462313325, enligt samma ärende. Jämför hela värdet. Ett filnamn eller ett bekant avsändarnamn räcker inte som kontroll. Om källfilen saknas behöver du först lokalisera hur ditt installationsrecept registrerar förrådet; anta inte att en tom träff betyder att miljön är färdigkontrollerad.

Spara källfilens sökväg och fingeravtrycket i provprotokollet. Skriv också vilken image kontrollen gjordes i. Det gör resultatet användbart när någon annan ska uppdatera samma byggkedja. Undvik en skärmbild med hela miljön: ett kort utdrag med just förrådsreferensen och den publika nyckelidentiteten är lättare att granska.

Rätta receptet för rätt pakethanterare

För APT är åtgärden att hämta den uppdaterade nyckelringen och se till att APT-källan refererar till samma fil. GitHubs Linuxguide, kontrollerad den 5 september 2026, innehåller det kompletta installationsreceptet. Följ dess Debian/Ubuntu-avsnitt när du bygger en ny miljö. Har din befintliga konfiguration en annan sökväg måste filen och referensen ändras tillsammans.

På RPM-system behöver du även kontrollera förrådskonfigurationen. GitHubs rotationsärende anger att den ska hämtas på nytt så att den pekar på den uppdaterade nyckelringen. Välj avsnittet för DNF5, DNF4, Yum eller Zypper och jämför fingeravtrycket vid nyckelimporten. Att bara kopiera APT-kommandot till en Fedora-image löser inte samma uppgift.

Gör ändringen i den versionshanterade Dockerfilen eller installationsskriptet och granska diffen. Sätt som eget godkännandekrav att signaturkontrollen finns kvar. Acceptera inte en föreslagen genväg som stänger av kontrollen för att få jobbet grönt. Låt också någon läsa var hämtad kod och paket kommer ifrån; guiden till beroenden som AI föreslår hjälper dig att hålla den granskningen separat från själva felsökningen.

Bygg om utan gamla containerlager

Kör ett nytt bygge av det ändrade receptet och behåll byggloggen. Med Docker kan ett lokalt prov exempelvis se ut så här:

docker build --no-cache --pull --progress=plain -t gh-key-check .

Dockers kommandoreferens, kontrollerad den 5 september 2026, beskriver --no-cache som att byggcache inte används och --pull som att Docker försöker hämta refererade images. --progress=plain visar containerutdata. Exemplet publicerar ingen image. Välj samma byggkontext, mål och plattform som CI använder om ditt ordinarie kommando har sådana inställningar.

Ett ombygge av din Dockerfile skapar däremot inte automatiskt om innehållet i en separat basimage. GitHubs rotationsärende beskriver därför att nyckeln kan behöva uppdateras i ett nytt lager före paketlistornas uppdatering. Kontrollera också egna cache mounts och CI-steg som återställer paketfiler: använd ett isolerat prov utan dessa återställningar för att testa verklig hämtning.

Läs loggen efter provet. Anteckna om nyckeln hämtades, om förrådsmetadata kunde verifieras och om installationen av gh genomfördes. Ett nätverksfel ska få en egen felkategori. Gör inte en DNS-timeout till bevis för en felaktig signeringsnyckel, och skriv inte godkänt om provet aldrig nådde paketinstallationen.

Skilj installation från version och inloggning

Efter installationsprovet kan du köra gh --version i den färdiga miljön och anteckna resultatet. Behandla det som en kontroll av den körbara filen. Det är byggloggen från den rena miljön som ska visa att hämtning och verifiering fungerade. En versionsrad från gårdagens image besvarar en annan fråga.

Autentisering kontrollerar du separat. Manualen för gh auth status, kontrollerad den 5 september 2026, beskriver kommandot som en kontroll av autentiseringstillståndet för GitHub-konton. Kör det först när du ska prova agentens avsedda åtkomst. Ta inte med tokenvärden i protokollet och blanda inte ett inloggningsfel med installationsresultatet.

Avsluta med ett litet överlämningsunderlag: commit för installationsreceptet, imageidentitet, pakethanterare, nyckelfingeravtryck, logg från det rena bygget och observerad gh-version. Markera autentisering som separat godkänd, underkänd eller inte testad. Lägg kontrollen bland dina stoppregler i CI före merge om agentmiljön är en förutsättning för att granskningen ska kunna köras.