Perfil de OpenVPN en Git: que retirar antes de confirmar

Os perfís cumpren dúas funcións á vez: rexistran a configuración da conexión e levan un paquete de credenciais que funciona. A extensión do ficheiro non lle di nada sobre cal das dúas cousas ten nas mans. Lea o contido antes de decidir que pertence a un repositorio.

Os pasos seguintes supoñen que se está a considerar un modelo de cliente para o control de versións. Execúteos en orde e detéñase antes de confirmar algo que non poida revogar.

Lea o ficheiro que vai preparar

Comece polos bytes reais, porque un perfil que fai referencia a ficheiros separados parece moi distinto dun que os incrusta. Busque os marcadores de bloque PEM e as etiquetas en liña chamadas ca, cert, key, tls-auth e tls-crypt, e a mesma pasada mostraralle ambos os casos. Unha chave privada cifrada segue contando como material sensible, e unha chave compartida tls-auth ou tls-crypt é unha credencial aínda que non sexa a identidade dun usuario. Aplique a mesma revisión a todo o que se prepara xunto ao perfil, incluídos os arquivos e os scripts de instalación que fan referencia a un ficheiro de credenciais.

Despois mire o conxunto preparado e non a árbore de traballo. git diff --cached mostra que conterá realmente a confirmación, e esa é a única versión que importa para esta decisión.

Decida que pode distribuír o repositorio

Un modelo pode levar a configuración compartida e revisada e marcadores de posición con nome para todo o que unha persoa recibe na inscrición. O que non pode levar é unha identidade utilizábel, porque un repositorio distribúe a todos os que poden lelo, automatización incluída. Un repositorio privado reduce a audiencia sen cambiar a pregunta de se cada lector está autorizado para esa credencial.

Unha regra de ignorar impide adicións futuras e non fai nada co que xa está rexistrado. Esa asimetría merece interiorizarse antes da primeira confirmación e non despois da décima. Os nomes e os enderezos de infraestrutura son un xuízo aparte: non son segredos de autenticación, pero poden revelar máis do que un equipo pretende publicar. Tome esa decisión explicitamente en lugar de clasificar cada liña en contrasinal ou público.

Se o material xa está no historial

Eliminar a liña nunha confirmación nova deixa a versión antiga intacta para calquera que a descargue. Trate a exposición como real: identifique o tipo de credencial e logo atope a autoridade que a pode invalidar. Revógase o certificado do cliente e rexenérase a lista de revocación; unha chave compartida da canle de control substitúese no servidor e en cada cliente que a usa.

As dúas teñen un radio de impacto moi distinto, e o plan debe indicar cal está executando antes de comezar. Localice a confirmación que introduciu o material cunha busca do tipo git log --all -S 'BEGIN PRIVATE KEY', para que o alcance da limpeza sexa coñecido e non suposto. O clon dun compañeiro ou unha bifurcación pode conter xa o obxecto antigo, e por iso a revogación vai primeiro e a limpeza despois.

Limpe só despois de contelo

Reescribir o historial cambia cada confirmación posterior á que edita, así que primeiro necesita o acordo do propietario do repositorio e das persoas que traballan nel. Un envío forzado non é unha reparación; é un evento de coordinación co seu propio risco de reversión. Planifíqueo, faga unha copia de seguranza e avise o equipo de cando ocorrerá.

Despois, verifique a árbore actual e o historial restante en lugar de confiar no resumo da ferramenta.

Garde o resultado como dous artefactos: o modelo que é seguro compartir e o inventario de credenciais emitidas durante o proceso de inscrición. Ningún dos dous esixe que unha identidade utilizábel viva no repositorio.

Esa separación é a solución real, e sobrevive á próxima persoa que queira confirmar un perfil.