Профиль OpenVPN в Git: что удалить до коммита

Профили служат сразу двум целям: они фиксируют настройки подключения и несут рабочий набор учётных данных. Расширение файла ничего не говорит о том, что именно у вас в руках. Прочитайте содержимое, прежде чем решать, что оно принадлежит репозиторию.

Шаги ниже предполагают, что рассматривается клиентский шаблон для системы контроля версий. Выполняйте их по порядку и остановитесь до того, как закоммитите то, что не сможете отозвать.

Прочитайте файл, который собираетесь добавить в индекс

Начните с реальных байтов, потому что профиль, ссылающийся на отдельные файлы, выглядит совсем не так, как тот, что встраивает их. Ищите маркеры блока PEM и встроенные теги с именами ca, cert, key, tls-auth и tls-crypt, и тот же проход покажет оба случая. Зашифрованный закрытый ключ по-прежнему считается чувствительным материалом, а общий ключ tls-auth или tls-crypt является учётными данными, даже если это не личность пользователя. Примените ту же проверку ко всему, что добавляется в индекс вместе с профилем, включая архивы и установочные скрипты, ссылающиеся на файл учётных данных.

Затем смотрите на подготовленный набор, а не на рабочее дерево. git diff --cached показывает, что коммит действительно будет содержать, и это единственная версия, которая имеет значение для этого решения.

Решите, что репозиторию разрешено распространять

Шаблон может нести общие, проверенные настройки и именованные заполнители для всего, что человек получает при регистрации. Чего он нести не может, так это пригодной к использованию личности, потому что репозиторий распространяется на всех, кто может его читать, включая автоматизацию. Закрытый репозиторий сужает аудиторию, но не меняет вопрос о том, имеет ли каждый читатель право на эти учётные данные.

Правило игнорирования предотвращает будущие добавления и ничего не делает с тем, что уже записано. Эту асимметрию стоит усвоить до первого коммита, а не после десятого. Имена и адреса инфраструктуры — отдельное суждение: это не секреты аутентификации, но они могут раскрыть больше, чем команда намерена опубликовать. Примите это решение явно, вместо того чтобы раскладывать каждую строку на пароль или публичное.

Если материал уже в истории

Удаление строки в новом коммите оставляет старую версию нетронутой для каждого, кто её получит. Относитесь к раскрытию как к реальному: определите тип учётных данных, затем найдите инстанцию, которая может их аннулировать. Клиентский сертификат отзывается, а список отзыва создаётся заново; общий ключ канала управления заменяется на сервере и на каждом клиенте, который его использует.

У обоих очень разный радиус действия, и план должен до начала указать, какой из них вы выполняете. Найдите коммит, внёсший материал, поиском вида git log --all -S 'BEGIN PRIVATE KEY', чтобы объём уборки был известен, а не угадан. Клон коллеги или форк может уже хранить старый объект, поэтому отзыв идёт первым, а уборка вторым.

Убирайте только после локализации

Перезапись истории меняет каждый коммит после того, который вы правите, поэтому сначала нужно согласие владельца репозитория и людей, работающих в нём. Принудительный push — не починка; это событие координации с собственным риском отката. Запланируйте его, сделайте резервную копию и скажите команде, когда это произойдёт.

После этого проверьте текущее дерево и оставшуюся историю, а не доверяйте сводке инструмента.

Сохраните результат как два артефакта: шаблон, который безопасно распространять, и перечень учётных данных, выданных в процессе регистрации. Ни один из них не требует, чтобы в репозитории жила пригодная к использованию личность.

Это разделение и есть настоящее исправление, и оно переживёт следующего человека, который захочет закоммитить профиль.