Profil OpenVPN dans Git : ce qu'il faut retirer avant de valider
Lisez le fichier pour y repérer les clés intégrées, décidez ce qu'un dépôt a le droit de diffuser, et révoquez avant de réécrire l'historique.
Les profils remplissent deux fonctions à la fois : ils enregistrent les paramètres de connexion et portent un ensemble d'informations d'identification qui fonctionne. L'extension du fichier ne vous dit rien sur celle des deux que vous tenez. Lisez le contenu avant de décider qu'il appartient à un dépôt.
Les étapes ci-dessous supposent qu'un modèle de client est envisagé pour le contrôle de version. Exécutez-les dans l'ordre et arrêtez-vous avant de valider quoi que ce soit que vous ne puissiez révoquer.
Lisez le fichier que vous allez indexer
Commencez par les octets réels, car un profil qui renvoie à des fichiers séparés est très différent de celui qui les intègre. Cherchez les marqueurs de bloc PEM et les balises en ligne nommées ca, cert, key, tls-auth et tls-crypt, et la même passe vous montrera les deux cas. Une clé privée chiffrée compte toujours comme matériel sensible, et une clé tls-auth ou tls-crypt partagée est une information d'identification même si ce n'est pas l'identité d'un utilisateur. Appliquez la même revue à tout ce qui est indexé avec le profil, y compris les archives et les scripts d'installation qui renvoient à un fichier d'identification.
Regardez ensuite l'ensemble indexé plutôt que l'arbre de travail. git diff --cached montre ce que la validation contiendra réellement, et c'est la seule version qui compte pour cette décision.
Décidez ce que le dépôt a le droit de diffuser
Un modèle peut porter les paramètres partagés et revus et des espaces réservés nommés pour tout ce qu'une personne reçoit à l'inscription. Ce qu'il ne peut pas porter, c'est une identité utilisable, car un dépôt diffuse à tous ceux qui peuvent le lire, automatisation comprise. Un dépôt privé réduit l'audience sans changer la question de savoir si chaque lecteur est autorisé pour cette information d'identification.
Une règle d'exclusion empêche les ajouts futurs et ne fait rien pour ce qui est déjà enregistré. Cette asymétrie vaut la peine d'être intégrée avant la première validation plutôt qu'après la dixième. Les noms et les adresses d'infrastructure relèvent d'un jugement distinct : ce ne sont pas des secrets d'authentification, mais ils peuvent divulguer plus qu'une équipe n'entend publier. Prenez cette décision explicitement au lieu de classer chaque ligne en mot de passe ou public.
Si le matériel figure déjà dans l'historique
Supprimer la ligne dans une nouvelle validation laisse l'ancienne version intacte pour quiconque la récupère. Traitez l'exposition comme réelle : identifiez le type d'information d'identification, puis trouvez l'autorité qui peut l'invalider. Le certificat client est révoqué et la liste de révocation régénérée ; une clé de canal de contrôle partagée est remplacée sur le serveur et sur chaque client qui l'utilise.
Les deux ont des rayonnements très différents, et le plan doit indiquer lequel vous exécutez avant de commencer. Localisez la validation qui a introduit le matériel avec une recherche du type git log --all -S 'BEGIN PRIVATE KEY', pour que l'étendue du nettoyage soit connue et non devinée. Le clone d'un collègue ou une bifurcation peut déjà détenir l'ancien objet, c'est pourquoi la révocation vient d'abord et le nettoyage ensuite.
Nettoyez seulement après avoir contenu
Réécrire l'historique change chaque validation après celle que vous modifiez, il faut donc d'abord l'accord du propriétaire du dépôt et des personnes qui y travaillent. Un envoi forcé n'est pas une réparation ; c'est un événement de coordination avec son propre risque de retour arrière. Planifiez-le, faites une sauvegarde et dites à l'équipe quand il aura lieu.
Ensuite, vérifiez l'arbre actuel et l'historique restant au lieu de faire confiance au résumé de l'outil.
Conservez le résultat sous forme de deux artefacts : le modèle sûr à partager et l'inventaire des informations d'identification émises pendant le processus d'inscription. Ni l'un ni l'autre n'exige qu'une identité utilisable vive dans le dépôt.
Cette séparation est la véritable solution, et elle survit à la personne suivante qui voudra valider un profil.