Git'te OpenVPN profili: commit öncesi neler çıkarılmalı

Profiller aynı anda iki amaca hizmet eder: bağlantı ayarlarını kaydederler ve çalışan bir kimlik bilgisi paketi taşırlar. Dosya uzantısı, elinizde hangisinin olduğu konusunda size hiçbir şey söylemez. Bir depoya ait olduğuna karar vermeden önce içeriği okuyun.

Aşağıdaki adımlar, bir istemci şablonunun sürüm denetimi için değerlendirildiğini varsayar. Bunları sırayla uygulayın ve iptal edemeyeceğiniz bir şeyi commit etmeden önce durun.

İndekse ekleyeceğiniz dosyayı okuyun

Gerçek baytlarla başlayın, çünkü ayrı dosyalara başvuran bir profil, onları gömerek taşıyan bir profilden tamamen farklı görünür. PEM blok işaretlerini ve ca, cert, key, tls-auth ile tls-crypt adlı satır içi etiketleri arayın; aynı tarama size her iki durumu da gösterecektir. Şifrelenmiş özel anahtar hâlâ hassas materyal sayılır ve paylaşılan bir tls-auth veya tls-crypt anahtarı, kullanıcının kimliği olmasa da bir kimlik bilgisidir. Aynı incelemeyi profil ile birlikte indekse eklenen her şeye, kimlik bilgisi dosyasına başvuran arşivler ve kurulum betikleri dâhil, uygulayın.

Ardından çalışma ağacına değil, indekse eklenen kümeye bakın. git diff --cached commit'in gerçekte ne içereceğini gösterir ve bu karar için önemli olan tek sürüm odur.

Deponun neleri dağıtabileceğine karar verin

Bir şablon, paylaşılan ve gözden geçirilmiş ayarları ve kişinin kayıt sırasında aldığı her şey için adlandırılmış yer tutucuları taşıyabilir. Taşıyamadığı şey kullanılabilir bir kimliktir, çünkü bir depo onu okuyabilen herkese, otomasyon dâhil, dağıtılır. Özel bir depo kitleyi daraltır ama her okuyucunun o kimlik bilgisi için yetkili olup olmadığı sorusunu değiştirmez.

Yoksayma kuralı gelecekteki eklemeleri engeller ve zaten kayıtlı olanlar için hiçbir şey yapmaz. Bu asimetriyi onuncu commit'ten sonra değil, birinciden önce içselleştirmek gerekir. Altyapı adları ve adresleri ayrı bir değerlendirmedir: kimlik doğrulama sırları değildir, ancak bir ekibin yayımlamayı düşündüğünden fazlasını açığa çıkarabilirler. Her satırı parola ya da genel olarak sınıflandırmak yerine bu kararı açıkça verin.

Materyal zaten geçmişteyse

Yeni bir commit'te satırı kaldırmak, eski sürümü onu indiren herkes için bozulmadan bırakır. Açığa çıkmayı gerçek olarak ele alın: kimlik bilgisinin türünü belirleyin, ardından onu geçersiz kılabilecek makamı bulun. İstemci sertifikası iptal edilir ve iptal listesi yeniden oluşturulur; paylaşılan denetim kanalı anahtarı sunucuda ve onu kullanan her istemcide değiştirilir.

İkisinin etki yarıçapı çok farklıdır ve plan başlamadan önce hangisini yürüttüğünüzü belirtmelidir. Materyali getiren commit'i git log --all -S 'BEGIN PRIVATE KEY' benzeri bir aramayla bulun, böylece temizliğin kapsamı tahmin değil bilinen olsun. Bir iş arkadaşının klonu veya çatalı eski nesneyi zaten tutuyor olabilir; bu yüzden iptal önce, temizlik sonra gelir.

Yalnızca sınırladıktan sonra temizleyin

Geçmişi yeniden yazmak, düzenlediğiniz commit'ten sonraki her commit'i değiştirir, bu yüzden önce depo sahibinin ve içinde çalışan kişilerin onayı gerekir. Zorla push bir onarım değildir; kendi geri alma riski olan bir eşgüdüm olayıdır. Planlayın, yedek alın ve ekibe ne zaman olacağını söyleyin.

Sonrasında aracın özetine güvenmek yerine geçerli ağacı ve kalan geçmişi doğrulayın.

Sonucu iki eser olarak saklayın: paylaşılması güvenli olan şablon ve kayıt sürecinde verilen kimlik bilgilerinin dökümü. İkisi de depoda kullanılabilir bir kimliğin yaşamasını gerektirmez.

Bu ayrım gerçek düzeltmedir ve profil commit etmek isteyen bir sonraki kişiden sonra da ayakta kalır.