Perfil OpenVPN no Git: o que remover antes de fazer commit

Os perfis servem dois propósitos ao mesmo tempo: registam as definições de ligação e transportam um conjunto de credenciais que funciona. A extensão do ficheiro não lhe diz nada sobre qual dos dois tem nas mãos. Leia o conteúdo antes de decidir que pertence a um repositório.

Os passos seguintes assumem que está a ser considerada uma predefinição de cliente para controlo de versões. Execute-os pela ordem indicada e pare antes de consolidar algo que não possa revogar.

Leia o ficheiro que vai preparar

Comece pelos bytes reais, porque um perfil que refere ficheiros separados é muito diferente de um que os incorpora. Procure os marcadores de bloco PEM e as etiquetas em linha chamadas ca, cert, key, tls-auth e tls-crypt, e a mesma passagem mostrará os dois casos. Uma chave privada cifrada continua a contar como material sensível, e uma chave tls-auth ou tls-crypt partilhada é uma credencial mesmo que não seja a identidade de um utilizador. Aplique a mesma revisão a tudo o que é preparado ao lado do perfil, incluindo arquivos e scripts de instalação que refiram um ficheiro de credenciais.

Depois olhe para o conjunto preparado e não para a árvore de trabalho. git diff --cached mostra o que a consolidação vai realmente conter, e é a única versão que importa para esta decisão.

Decida o que o repositório pode distribuir

Uma predefinição pode levar as definições partilhadas e revistas e marcadores de posição nomeados para tudo o que uma pessoa recebe no momento da inscrição. O que não pode levar é uma identidade utilizável, porque um repositório é distribuído a todos os que o conseguem ler, incluindo a automatização. Um repositório privado reduz o público sem alterar a questão de saber se cada leitor está autorizado para essa credencial.

Uma regra de exclusão impede adições futuras e não faz nada quanto ao que já está registado. Vale a pena interiorizar essa assimetria antes da primeira consolidação e não depois da décima. Os nomes e endereços de infraestrutura são um juízo à parte: não são segredos de autenticação, mas podem revelar mais do que aquilo que uma equipa tenciona publicar. Tome essa decisão de forma explícita em vez de classificar cada linha em palavra-passe ou público.

Se o material já está no histórico

Remover a linha numa nova consolidação deixa a versão antiga intacta para qualquer pessoa que a obtenha. Trate a exposição como real: identifique o tipo de credencial e depois encontre a entidade que a pode invalidar. O certificado de cliente é revogado e a lista de revogação é regenerada; uma chave partilhada do canal de controlo é substituída no servidor e em cada cliente que a utiliza.

As duas têm raios de impacto muito diferentes, e o plano deve indicar qual está a executar antes de começar. Localize a consolidação que introduziu o material com uma pesquisa do tipo git log --all -S 'BEGIN PRIVATE KEY', para que o âmbito da limpeza seja conhecido e não adivinhado. O clone de um colega ou um fork pode já deter o objeto antigo, e é por isso que a revogação vem primeiro e a limpeza depois.

Limpe apenas depois de o conter

Reescrever o histórico altera todas as consolidações posteriores à que edita, pelo que primeiro é necessário o acordo do proprietário do repositório e das pessoas que nele trabalham. Um envio forçado não é uma reparação; é um acontecimento de coordenação com o seu próprio risco de reversão. Agende-o, faça uma cópia de segurança e diga à equipa quando vai acontecer.

Depois, verifique a árvore atual e o histórico restante em vez de confiar no resumo da ferramenta.

Guarde o resultado como dois artefactos: a predefinição que é segura de partilhar e o inventário de credenciais emitidas durante o processo de inscrição. Nenhum deles exige que uma identidade utilizável viva no repositório.

Essa separação é a correção verdadeira, e sobrevive à próxima pessoa que queira consolidar um perfil.