Perfil d'OpenVPN a Git: què cal eliminar abans de confirmar els canvis

Els perfils compleixen dues funcions alhora: enregistren la configuració de connexió i porten un paquet de credencials que funciona. L'extensió del fitxer no us diu res sobre quina de les dues coses teniu a les mans. Llegiu el contingut abans de decidir que pertany a un repositori.

Els passos següents assumeixen que es valora una plantilla de client per al control de versions. Executeu-los en ordre i atureu-vos abans de confirmar res que no pugueu revocar.

Llegiu el fitxer que esteu a punt de preparar

Comenceu pels bytes reals, perquè un perfil que fa referència a fitxers separats es veu molt diferent d'un que els incrusta. Cerqueu els marcadors de bloc PEM i les etiquetes en línia anomenades ca, cert, key, tls-auth i tls-crypt, i la mateixa passada us mostrarà tots dos casos. Una clau privada xifrada continua comptant com a material sensible, i una clau compartida tls-auth o tls-crypt és una credencial encara que no sigui la identitat d'un usuari. Apliqueu la mateixa revisió a tot el que es prepara al costat del perfil, inclosos els arxius i els scripts de configuració que fan referència a un fitxer de credencials.

Després mireu el conjunt preparat i no l'arbre de treball. git diff --cached mostra què contindrà realment la confirmació, i aquesta és l'única versió que importa per a aquesta decisió.

Decidiu què pot distribuir el repositori

Una plantilla pot portar la configuració compartida i revisada i marcadors de posició amb nom per a tot el que una persona rep en el moment de l'alta. El que no pot portar és una identitat utilitzable, perquè un repositori distribueix a tothom qui el pugui llegir, automatització inclosa. Un repositori privat redueix l'audiència sense canviar la pregunta de si cada lector està autoritzat per a aquesta credencial.

Una regla d'ignorar impedeix afegiments futurs i no fa res amb el que ja està enregistrat. Val la pena interioritzar aquesta asimetria abans de la primera confirmació i no després de la desena. Els noms i les adreces d'infraestructura són un judici a part: no són secrets d'autenticació, però poden revelar més del que un equip vol publicar. Preneu aquesta decisió explícitament en lloc de classificar cada línia en contrasenya o públic.

Si el material ja és a l'historial

Eliminar la línia en una confirmació nova deixa la versió antiga intacta per a qualsevol que la baixi. Tracteu l'exposició com a real: identifiqueu el tipus de credencial i després trobeu l'autoritat que la pot invalidar. Es revoca el certificat del client i es regenera la llista de revocació; una clau compartida del canal de control se substitueix al servidor i a cada client que la fa servir.

Les dues coses tenen un radi d'abast molt diferent, i el pla ha d'indicar quina executeu abans de començar. Localitzeu la confirmació que va introduir el material amb una cerca tipus git log --all -S 'BEGIN PRIVATE KEY', perquè l'abast de la neteja sigui conegut i no endevinat. El clon d'un company o una bifurcació pot tenir ja l'objecte antic, i per això la revocació va primer i la neteja després.

Netegeu només després de contenir-lo

Reescriure l'historial canvia cada confirmació posterior a la que editeu, de manera que primer cal l'acord del propietari del repositori i de les persones que hi treballen. Un enviament forçat no és cap reparació; és un esdeveniment de coordinació amb el seu propi risc de reversió. Planifiqueu-lo, feu una còpia de seguretat i digueu a l'equip quan passarà.

Després, verifiqueu l'arbre actual i l'historial restant en lloc de confiar en el resum de l'eina.

Guardeu el resultat com dos artefactes: la plantilla que és segura de compartir i l'inventari de credencials emeses durant el procés d'alta. Cap dels dos no requereix que una identitat utilitzable visqui al repositori.

Aquesta separació és la solució real, i sobreviu a la propera persona que vulgui confirmar un perfil.