GitHub a blocat cheia API: revocarea vine înaintea curățării istoricului

Dacă GitHub îți blochează push-ul pentru o cheie API reală, revocă acea cheie sau rotește-o la furnizor, apoi elimină valoarea din commiturile afectate. Ghidul GitHub despre date sensibile pune invalidarea credențialului înaintea rescrierii istoricului: după revocare, cheia veche nu mai poate fi folosită pentru acces.

Pentru a debloca push-ul, află în ce commituri apare cheia și corectează fiecare apariție, nu doar fișierul în forma lui actuală. Dacă este numai în ultimul commit, îl poți modifica prin amend; dacă apare mai devreme în ramură, ai nevoie de rebase interactiv. Aceste operațiuni privesc, deocamdată, istoricul pe care încerci să îl trimiți.

Identifică toate commiturile afectate

Mesajul de respingere arată unde a fost detectat secretul, inclusiv identificatorii commiturilor și căile fișierelor. Instrucțiunile GitHub pentru push protection cer eliminarea valorii din toate commiturile în care apare. Un commit nou care șterge cheia din versiunea curentă lasă în urmă commiturile care au conținut-o.

Compară identificatorii din eroare cu ordinea afișată de git log și găsește prima apariție din ramură. Uită-te și la commiturile ulterioare semnalate: același secret poate rămâne în versiuni succesive ale unui fișier sau poate fi adăugat din nou în altă parte. Notează local commiturile și căile, fără să copiezi valoarea cheii în tichete, mesaje ori capturi trimise colegilor.

Verifică dacă șirul detectat este într-adevăr un credențial activ și cine administrează serviciul care l-a emis. Dacă este o cheie reală, curățarea Git nu o dezactivează la furnizor. Pentru un serviciu care depinde de ea, pregătește credențialul înlocuitor și actualizează configurația necesară, astfel încât cheia veche să poată fi retrasă fără a o lăsa validă mai mult decât este necesar.

Secretul este în ultimul commit: corectează acel commit

Elimină cheia din fișierul urmărit, apoi folosește git commit --amend --all pentru a modifica ultimul commit, în loc să adaugi un commit de ștergere. Verifică git status înainte de comandă: opțiunea --all include modificările din fișierele deja urmărite, inclusiv unele care ar putea aparține altei lucrări. După amend, inspectează commitul rezultat și retrimite ramura cu git push.

Dacă secretul se află într-un fișier care nu ar trebui versionat, scoate-l din conținutul urmărit și păstrează local numai copia necesară aplicației. Poți adăuga apoi calea potrivită în .gitignore pentru a preveni o nouă includere accidentală. Această regulă de ignorare nu elimină însă fișierul dintr-un commit deja creat; amend trebuie să corecteze și acel commit.

Înainte de a retrimite ramura, uită-te la conținutul commitului modificat, nu numai la aspectul fișierului din directorul de lucru. Diferența contează când există schimbări neincluse sau când cheia a fost copiată în mai multe fișiere. Dacă push-ul este respins din nou, revino la locațiile indicate de GitHub: poate exista încă o apariție în istoricul trimis.

Secretul este într-un commit mai vechi: folosește rebase interactiv

Pornește de la primul commit afectat și rulează git rebase -i ID_COMMIT~1, înlocuind ID_COMMIT cu identificatorul lui. În lista deschisă, schimbă pick în edit pentru commitul care a introdus cheia. Când rebase-ul se oprește acolo, elimină valoarea din fișier, adaugă modificarea corectată, rulează git commit --amend și continuă cu git rebase --continue.

Marchează pentru editare și un commit ulterior dacă acela introduce din nou secretul. Corectarea primei apariții nu repară automat o adăugare independentă făcută mai târziu. La sfârșit, compară istoricul rezultat cu lista inițială a commiturilor semnalate și reîncearcă push-ul. Dacă rebase-ul produce conflicte, rezolvă-le fără să readuci cheia în fișierele rezultate.

Această procedură este potrivită pentru commiturile locale pe care le pregătești pentru prima publicare. Rebase-ul schimbă identificatorii commitului editat și ai celor care urmează după el. Dacă alte persoane lucrează deja pe aceeași istorie publicată, stabilește cu ele cum vor prelua schimbarea înainte de a forța actualizarea ramurii.

Cheia a fost publicată: neutralizează accesul și verifică alerta

O cheie ajunsă într-un depozit trebuie tratată ca expusă chiar dacă dispare imediat din versiunea curentă a fișierului. Revocă sau rotește credențialul la furnizor, actualizează serviciile care îl folosesc și, dacă furnizorul oferă această posibilitate, verifică jurnalele pentru activitate neautorizată. Procedura GitHub pentru alertele secret scanning cere tratarea unui secret comis ca fiind compromis și actualizarea serviciilor dependente.

Ștergerea tokenului din depozit nu închide automat alerta secret scanning. După remediere, verifică starea ei și închide-o cu motivul potrivit. Dacă regulile ramurii cer rezolvarea alertelor, una deschisă de un pull request poate împiedica îmbinarea acestuia; regula poate aștepta și finalizarea scanării commitului din vârful ramurii.

Distinge între eliminarea valorii din versiunea activă și ștergerea ei din istoricul publicat. Prima schimbare împiedică folosirea ei în codul curent; numai revocarea oprește folosirea credențialului vechi pentru acces. Istoricul poate păstra valoarea, iar această expunere rămasă trebuie evaluată separat.

Când merită rescris întregul istoric

Pentru o cheie revocată, rescrierea completă nu este automată: valoarea poate rămâne vizibilă, dar nu mai oferă acces prin acel credențial. Rescrierea devine mai relevantă dacă datele rămân sensibile după invalidare sau dacă obligațiile proiectului cer eliminarea lor din istoricul publicat. Hotărârea trebuie luată și în funcție de câte ramuri, clone și forkuri pot păstra commiturile afectate.

Dacă alegi curățarea completă, git-filter-repo poate elimina fișierul sau înlocui valoarea în istoricul local, după care depozitul trebuie actualizat. Un push forțat schimbă identificatorii commiturilor și poate afecta semnături, protecția ramurilor și pull requesturile. Colaboratorii cu clone vechi trebuie coordonați: o îmbinare făcută din istoricul contaminat poate readuce datele eliminate.

Nici actualizarea depozitului principal nu șterge copiile din forkuri ori clone și nici toate referințele păstrate de GitHub pentru pull requesturi. Proprietarii fork-urilor trebuie să curețe copiile lor; pentru anumite referințe și vizualizări păstrate pe GitHub poate fi necesar ajutorul GitHub Support. Acesta este un motiv practic pentru a stabili beneficiul curățării înainte de a începe o rescriere care afectează întreaga echipă.

• Push blocat, secret doar în ultimul commit: retrage cheia reală, corectează acel commit prin amend și retrimite ramura.
• Push blocat, secret în commituri locale mai vechi: retrage cheia și folosește rebase interactiv pentru toate aparițiile semnalate.
• Cheie deja publicată și revocabilă: neutralizează accesul, actualizează serviciile dependente și rezolvă alerta; evaluează separat beneficiul rescrierii.
• Date care rămân sensibile după revocare: planifică rescrierea împreună cu colaboratorii și tratează clonele, fork-urile și referințele rămase.

Citește și:

• Google Meet sau Zoom: limita gratuită schimbă alegerea înaintea funcțiilor IA
• Cursor sau GitHub Copilot: acceptarea codului nu alege singură câștigătorul
• Fidelis sau Tezaur: ieșirea înainte de termen schimbă alegerea