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

Пасля гэтага праверце бягучае дрэва і астатнюю гісторыю, а не давярайце зводцы інструмента.

Захоўвайце вынік як два артэфакты: шаблон, які бяспечна дзяліць, і інвентар уліковых даных, выдадзеных падчас рэгістрацыі. Ні адзін з іх не патрабуе, каб у рэпазіторыі жыла працоўная ідэнтычнасць.

Гэтае раздзяленне і ёсць сапраўднае рашэнне, і яно перажыве наступнага чалавека, які захоча зафіксаваць профіль.