GitHub esti API-avaimen pushin – ohitus jättää silti hälytyksen

Jos GitHubin push protection estää API-avaimen sisältävän pushin, poista avain jokaisesta sitä sisältävästä lähetettävästä commitista ja yritä pushia uudelleen. GitHubin push protection -kuvaus kertoo, että arkiston suojauksen ohitus syyllä ”I'll fix it later” luo avoimen hälytyksen. Ohitus päästää muutoksen läpi, mutta avain jää historiaan.

Ratkaise ensin, missä avain on ollut. Vain estyneessä paikallisessa historiassa oleva arvo poistetaan commiteista ennen uutta pushia. Jos sama avain on jo julkaistu GitHubissa tai muualla, mitätöi tai vaihda se ennen historian siivousta. Jos löydös ei ole oikea salaisuus, väärän positiivisen kuittaus on eri päätös kuin toimivan avaimen ohittaminen.

Selvitä, missä avain esiintyy

Lue estoviestistä tunnisteen tyyppi sekä ilmoitetut commitit ja tiedostopolut. Etsi samaa arvoa myös muista lähetettävistä muutoksista: avain voi olla esimerkiksi asetustiedostossa ja myöhemmin kopioituna testiin. Työpuun nykyisen tiedoston korjaaminen ei yksin auta, jos vanhempi commit sisältää arvon edelleen.

Estynyt push kertoo kyseisen lähetyksen pysähtyneen ennen suojattuun arkistoon pääsyä. Se ei kerro, onko sama avain jo ollut toisessa haarassa, toisessa arkistossa, viestissä tai lokissa. Jos näin on voinut käydä, käsittele avainta paljastuneena. Tarkista avaimen myöntäneestä palvelusta sen käyttöoikeudet ja saatavilla olevat käyttötiedot, mutta älä odota selvityksen valmistumista ennen toimivan, julkaistun avaimen mitätöintiä.

Korjaa estyneen pushin commitit

GitHubin komentoriviohje edellyttää salaisuuden poistamista kaikista sitä sisältävistä commiteista. Jos lisäsit avaimen viimeisimmässä commitissa, poista arvo koodista, tarkista muutokset ja päivitä sama commit komennolla git commit --amend --all. Yritä sen jälkeen komentoa git push. Pelkkä uusi poistocommit ei riitä, sillä alkuperäinen, avaimen sisältävä commit lähtisi yhä mukaan.

Jos avain tuli mukaan aiemmassa commitissa, vertaa estoviestin commit-tunnuksia komennon git log näyttämään järjestykseen. Aloita vuorovaikutteinen rebase ensimmäistä saastunutta committia edeltävästä kohdasta ja merkitse kyseinen commit muokattavaksi. Poista avain, päivitä commit komennolla git commit --amend ja jatka komennolla git rebase --continue. Käy läpi myös muut ilmoitetut osumat ennen uutta pushia. Tämä muuttaa paikallisten committien tunnuksia, joten tarkista samalla, ettei muokkaukseen päädy muita keskeneräisiä muutoksia.

Säilytä sovelluksen tarvitsema avain versionhallinnan ulkopuolella, esimerkiksi ympäristömuuttujassa tai salaisuuksien hallintapalvelussa. Jos arvo oli paikallisessa asetustiedostossa, lisää sopiva tiedostopolku .gitignoreen tulevien lisäysten estämiseksi. Jo seurattua tiedostoa tai aiempaa committia .gitignore ei kuitenkaan siivoa. Korvaa koodissa oleva oikea avain esimerkiksi asetuksen lukemisella, jotta sovellus toimii myös korjatun pushin jälkeen.

Vaihda jo julkaistu avain ennen historian siivousta

Jos avain on jo ollut jaetussa arkistossa, katkaise sen käyttö ensin. GitHubin arkiston siivousohje asettaa salaisuuden mitätöinnin tai vaihdon ensimmäiseksi toimeksi ja toteaa, ettei historian uudelleenkirjoitus aina ole sen jälkeen tarpeen. Luo korvaava avain sen myöntäneessä palvelussa, päivitä sitä käyttävät sovellukset ja poista vanhan avaimen käyttömahdollisuus palvelun tarjoamalla tavalla.

Arvioi erikseen, pitääkö vanha arvo poistaa julkaistusta historiasta. GitHub kuvaa tähän git-filter-repo-työkalun, mutta historian uudelleenkirjoitus muuttaa commit-tunnuksia ja voi sotkea yhteistyökumppaneiden haaroja sekä pull requestien näkymiä. Sovi työstä arkiston muiden käyttäjien kanssa ja selvitä, missä haaroissa ja tunnisteissa arvo esiintyy. Puhdistettu päähaara ei yksin poista sitä muista viitteistä.

Pakotettu push ei myöskään pyyhi vanhoja committeja muiden klooneista tai forkeista. GitHubissa niitä voi lisäksi jäädä pull requestien viitteisiin tai välimuistiin, joiden käsittely voi edellyttää yhteydenottoa GitHubin tukeen. Siksi avaimen vaihto ja historian siivous ratkaisevat eri ongelmat: vaihto katkaisee vanhan tunnisteen käyttökelpoisuuden, siivous vähentää sen näkyvyyttä ja tahattoman uudelleenjulkaisun mahdollisuutta.

Kuittaa väärä positiivinen eri tavalla kuin oikea avain

Kun estetty merkkijono ei ole salaisuus, ohituksen syyksi sopii ”It's a false positive”. Kun arvoa käytetään vain testeissä eikä se anna pääsyä suojattuun palveluun, vaihtoehto on ”It's used in tests”. Arkiston push protection luo näistä ohituksista suljetun hälytyksen. Tarkista arvo ennen valintaa: tuotannossa toimiva API-avain ei muutu vaarattomaksi testiarvoksi vain siksi, että se on testitiedostossa.

Jos valitset oikealle salaisuudelle ”I'll fix it later”, arkiston suojauksen hälytys jää avoimeksi. Ohitustapahtuma kirjautuu valvontaan, ja siitä voidaan lähettää ilmoituksia arkiston ylläpitäjille ja muille määritetyille vastaanottajille. Käyttäjätilin oma push protection eroaa tästä: pelkkä sen ohitus ei luo arkiston hälytystä, ellei suojaus ole käytössä myös arkistossa. Tunnista siis estoviestistä ja arkiston asetuksista, kumpi suojaus pysäytti lähetyksen.

Pyydä ohituslupa vain perusteltuun poikkeukseen

Jos suoraa ohitusvalintaa ei ole ja GitHub tarjoaa ohitusluvan pyytämistä, avaa estoviestin osoite samalla tunnuksella, jolla yritit pushia. Kirjoita pyyntöön, miksi juuri tämä löydös on turvallista päästää arkistoon. Nimetty tarkastaja voi hyväksyä tai hylätä pyynnön; hyväksynnän jälkeen estetty commit voidaan lähettää. Hyväksyntä koskee lähetyslupaa, eikä se mitätöi toimivaa avainta.

Dokumentoitu poikkeus voi koskea esimerkiksi tarkistettua, käyttökelvotonta testiarvoa. Jos arvo antaa edelleen pääsyn palveluun, turvallinen ratkaisu on poistaa se lähetettävistä commiteista ja vaihtaa se, jos se on jo ollut saatavilla muualla. Näin työn voi julkaista ilman, että avaimen käsittely jää avoimen hälytyksen varaan.

Lue myös:

• SvelteKit 3 tuli jakoon – automaattinen siirto jättää silti TODO-listan
• Gemini API vai Mistral API? Ensimmäinen vastaus kääntää nopeusvertailun
• GitHub Actions vai GitLab CI? Minuutit peittävät todellisen laskun