Профіль 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 — не лагодження; це подія координації з власним ризиком відкату. Заплануйте її, зробіть резервну копію і скажіть команді, коли це станеться.

Після цього перевірте поточне дерево та решту історії, а не довіряйте підсумку інструмента.

Збережіть результат як два артефакти: шаблон, який безпечно поширювати, і перелік облікових даних, виданих під час реєстрації. Жоден із них не вимагає, щоб у репозиторії жила придатна для використання особистість.

Цей поділ і є справжнім виправленням, і він переживе наступну людину, яка захоче закомітити профіль.