OpenVPN профил во Git: што да се отстрани пред commit

Профилите служат за две цели истовремено: ги запишуваат поставките за поврзување и носат работен пакет акредитиви. Наставката на датотеката не ви кажува ништо за тоа кое од двете го држите. Прочитајте ја содржината пред да одлучите дека ѝ припаѓа на складиште.

Чекорите подолу претпоставуваат дека се разгледува клиентска шаблона за контрола на верзии. Изведете ги по ред и запрете пред да commit-нете нешто што не можете да го откажете.

Прочитајте ја датотеката што ќе ја ставите во индексот

Започнете со вистинските бајти, бидејќи профил што упатува на одделни датотеки изгледа сосема поинаку од оној што ги вградува. Барајте ги маркерите на PEM блокот и вградените ознаки со имиња ca, cert, key, tls-auth и tls-crypt, и истото пребарување ќе ви ги покаже двата случаи. Шифрираниот приватен клуч уште се смета за чувствителен материјал, а споделениот tls-auth или tls-crypt клуч е акредитив дури и кога не е идентитет на корисник. Применете ја истата проверка на сето она што се става во индексот заедно со профилот, вклучително архиви и инсталациски скрипти што упатуваат на датотека со акредитиви.

Потоа гледајте го подготвеното множество, а не работното дрво. git diff --cached покажува што всушност ќе содржи commit-от, и тоа е единствената верзија што е важна за оваа одлука.

Одлучете што смее складиштето да дистрибуира

Шаблоната може да ги носи споделените, прегледани поставки и именувани места-резервати за сето она што човек добива при запишување. Она што не може да го носи е употреблив идентитет, бидејќи складиштето се дистрибуира до сите што можат да го читаат, вклучително автоматизацијата. Приватното складиште ја стеснува публиката без да го смени прашањето дали секој читач е овластен за тој акредитив.

Правилото за игнорирање спречува идни додавања и не прави ништо за она што е веќе запишано. Оваа асиметрија вреди да се усвои пред првиот commit, а не по десеттиот. Имињата и адресите на инфраструктурата се одделна проценка: тие не се тајни за автентикација, но можат да откријат повеќе отколку што тимот има намера да објави. Донесете ја таа одлука експлицитно наместо секоја линија да ја распоредувате во лозинка или јавно.

Ако материјалот е веќе во историјата

Отстранувањето на линијата во нов commit ја остава старата верзија недопрена за секој што ќе ја преземе. Третирајте го изложувањето како вистинско: утврдете го типот на акредитивот, потоа најдете го органот што може да го поништи. Клиентскиот сертификат се отповикува и списокот за отповикување се создава повторно; споделениот клуч на контролниот канал се заменува на серверот и на секој клиент што го користи.

Двете имаат многу различен радиус на влијание, и планот треба да наведе кое го изведувате пред да започнете. Најдете го commit-от што го внесе материјалот со пребарување од типот git log --all -S 'BEGIN PRIVATE KEY', за да биде обемот на чистењето познат, а не претпоставен. Клонот на колега или форк може веќе да го држи стариот објект, затоа отповикувањето доаѓа прво, а чистењето второ.

Чистете само откако ќе го ограничите

Препишувањето на историјата го менува секој commit по оној што го уредувате, затоа прво е потребна согласност од сопственикот на складиштето и од луѓето што работат во него. Присилното туркање не е поправка; тоа е координациски настан со сопствен ризик од враќање. Закажете го, направете резервна копија и кажете му на тимот кога ќе се случи.

Потоа проверете го тековното дрво и преостанатата историја наместо да му верувате на резимето на алатката.

Зачувајте го резултатот како два артефакти: шаблоната што е безбедна за споделување и пописот на акредитиви издадени преку процесот на запишување. Ниту еден од нив не бара употреблив идентитет да живее во складиштето.

Тоа раздвојување е вистинската поправка, и тоа го надживува следниот човек што ќе сака да commit-не профил.