Profily slouží dvěma účelům zároveň: zaznamenávají nastavení připojení a nesou funkční sadu přihlašovacích údajů. Přípona souboru vám nic neřekne o tom, kterou z těch dvou věcí držíte. Přečtěte obsah, než rozhodnete, že patří do repozitáře.

Následující kroky předpokládají, že se zvažuje klientská šablona pro správu verzí. Proveďte je popořadě a zastavte se před zapsáním čehokoli, co nemůžete odvolat.

Přečtěte soubor, který se chystáte přidat do indexu

Začněte od skutečných bajtů, protože profil, který odkazuje na samostatné soubory, vypadá úplně jinak než ten, který je vkládá. Hledejte značky bloku PEM a vložené značky s názvy ca, cert, key, tls-auth a tls-crypt, a tentýž průchod vám ukáže oba případy. Šifrovaný soukromý klíč se stále počítá za citlivý materiál a sdílený klíč tls-auth nebo tls-crypt je přihlašovací údaj, i když to není identita uživatele. Stejnou kontrolu použijte na vše, co se přidává do indexu spolu s profilem, včetně archivů a instalačních skriptů, které odkazují na soubor s údaji.

Pak se dívejte na připravenou sadu, ne na pracovní strom. git diff --cached ukazuje, co bude zapsání skutečně obsahovat, a to je jediná verze, na které u tohoto rozhodnutí záleží.

Rozhodněte, co smí repozitář distribuovat

Šablona může nést sdílené, zkontrolované nastavení a pojmenované zástupné prvky pro vše, co člověk dostane při zápisu. Co nést nemůže, je použitelná identita, protože repozitář distribuuje všem, kdo ho mohou číst, včetně automatizace. Soukromý repozitář zužuje publikum, ale nemění otázku, zda je každý čtenář pro tento údaj oprávněn.

Pravidlo ignorování brání budoucím přírůstkům a nedělá nic s tím, co už je zaznamenáno. Tuto asymetrii stojí za to si osvojit před prvním zapsáním, ne po desátém. Názvy a adresy infrastruktury jsou samostatný úsudek: nejsou to tajemství pro ověřování, ale mohou prozradit víc, než tým hodlá zveřejnit. Rozhodněte o tom výslovně, místo abyste každý řádek třídili na heslo nebo veřejné.

Pokud už je materiál v historii

Odstranění řádku v novém zapsání ponechá starou verzi nedotčenou pro každého, kdo si ji stáhne. Berte expozici jako skutečnou: určete typ údaje a pak najděte orgán, který ho může zneplatnit. Klientský certifikát se odvolá a seznam odvolaných se znovu vygeneruje; sdílený klíč řídicího kanálu se vymění na serveru a u každého klienta, který ho používá.

Obě mají velmi rozdílný dosah a plán by měl před začátkem uvést, kterou z nich provádíte. Najděte zapsání, které materiál zavedlo, hledáním typu git log --all -S 'BEGIN PRIVATE KEY', aby byl rozsah úklidu známý, a ne odhadnutý. Kolegův klon nebo fork už může starý objekt držet, proto odvolání přichází první a úklid druhý.

Čistěte až po zajištění

Přepis historie mění každé zapsání po tom, které upravíte, takže nejdřív potřebuje souhlas vlastníka repozitáře a lidí, kteří v něm pracují. Vynucené odeslání není oprava; je to koordinační událost s vlastním rizikem vrácení. Naplánujte ho, udělejte zálohu a řekněte týmu, kdy se stane.

Potom ověřte aktuální strom a zbývající historii, místo abyste věřili shrnutí nástroje.

Uchovejte výsledek jako dva artefakty: šablonu, která je bezpečná ke sdílení, a soupis údajů vydaných během zápisu. Ani jeden z nich nevyžaduje, aby v repozitáři žila použitelná identita.

Toto rozdělení je skutečná oprava a přežije dalšího člověka, který bude chtít profil zapsat.

Související články