پروفایل OpenVPN در Git: چه چیزی را پیش از ثبت حذف کنیم
پرونده را برای کلیدهای جاسازی‌شده بخوانید، تصمیم بگیرید یک مخزن اجازه دارد چه چیزی را توزیع کند، و پیش از بازنویسی تاریخچه اعتبار را باطل کنید.
پروفایل‌ها هم‌زمان دو کار می‌کنند: تنظیمات اتصال را ثبت می‌کنند و یک بسته اعتبارنامه کارآمد را با خود می‌برند. پسوند پرونده هیچ چیزی درباره اینکه کدام‌یک را در دست دارید نمی‌گوید. پیش از آنکه تصمیم بگیرید به یک مخزن تعلق دارد، محتوا را بخوانید.
مراحل زیر فرض می‌کنند که یک قالب کارخواه برای کنترل نسخه در نظر گرفته شده است. آنها را به ترتیب اجرا کنید و پیش از ثبت چیزی که نمی‌توانید باطل کنید بایستید.
پرونده‌ای را که می‌خواهید آماده کنید بخوانید
از بایت‌های واقعی شروع کنید، زیرا پروفایلی که به پرونده‌های جداگانه ارجاع می‌دهد بسیار متفاوت از پروفایلی است که آنها را در خود جاسازی می‌کند. نشانگرهای بلوک PEM و برچسب‌های درون‌خطی با نام‌های ca و cert و key و tls-auth و tls-crypt را جست‌وجو کنید، و همان جست‌وجو هر دو حالت را به شما نشان می‌دهد. کلید خصوصی رمزگذاری‌شده هنوز مطالب حساس به شمار می‌رود، و کلید مشترک tls-auth یا tls-crypt یک اعتبارنامه است حتی اگر هویت یک کاربر نباشد. همان بازبینی را روی هر چیزی که در کنار پروفایل آماده می‌شود اعمال کنید، از جمله بایگانی‌ها و اسکریپت‌های نصب که به یک پرونده اعتبارنامه ارجاع می‌دهند.
سپس به مجموعه آماده‌شده نگاه کنید نه درخت کاری. git diff --cached نشان می‌دهد ثبت واقعاً چه چیزی در بر خواهد داشت، و آن تنها نسخه‌ای است که برای این تصمیم اهمیت دارد.
تصمیم بگیرید مخزن اجازه دارد چه چیزی را توزیع کند
یک قالب می‌تواند تنظیمات مشترک و بازبینی‌شده و جای‌نگهدارهای نام‌دار را برای هر چیزی که یک شخص هنگام ثبت‌نام دریافت می‌کند حمل کند. آنچه نمی‌تواند حمل کند هویت قابل استفاده است، زیرا یک مخزن به همه کسانی توزیع می‌شود که می‌توانند آن را بخوانند، از جمله خودکارسازی. یک مخزن خصوصی مخاطبان را باریک می‌کند بدون آنکه این پرسش را تغییر دهد که آیا هر خواننده برای آن اعتبارنامه مجاز است.
یک قاعده نادیده‌گرفتن از افزوده‌های آینده جلوگیری می‌کند و درباره آنچه از پیش ثبت شده هیچ کاری نمی‌کند. این نابرابری ارزش درونی‌کردن را پیش از نخستین ثبت دارد، نه پس از دهمین. نام‌ها و نشانی‌های زیرساخت داوری جداگانه‌اند: آنها رازهای احراز هویت نیستند، اما می‌توانند بیش از آنچه یک تیم قصد انتشارش را دارد فاش کنند. این تصمیم را صریح بگیرید به جای آنکه هر خط را در دسته گذرواژه یا عمومی بگذارید.
اگر مطالب از قبل در تاریخچه است
حذف خط در یک ثبت تازه نسخه قدیمی را برای هر کسی که آن را دریافت می‌کند دست‌نخورده می‌گذارد. افشا را واقعی بدانید: نوع اعتبارنامه را مشخص کنید، سپس مرجعی را بیابید که می‌تواند آن را باطل کند. گواهی کارخواه باطل و فهرست ابطال دوباره تولید می‌شود؛ کلید مشترک کانال کنترل روی سرور و روی هر کارخواهی که از آن استفاده می‌کند جایگزین می‌شود.
این دو شعاع اثر بسیار متفاوتی دارند، و طرح باید پیش از آغاز بگوید کدام‌یک را اجرا می‌کنید. ثبتی را که مطالب را وارد کرده با جست‌وجویی از نوع git log --all -S 'BEGIN PRIVATE KEY' بیابید تا دامنه پاک‌سازی دانسته باشد نه حدس‌زده. کلون همکار یا یک انشعاب ممکن است از قبل شیء قدیمی را داشته باشد، از این رو ابطال نخست و پاک‌سازی دوم می‌آید.
پاک‌سازی را تنها پس از مهار انجام دهید
بازنویسی تاریخچه هر ثبت پس از ثبتی را که ویرایش می‌کنید تغییر می‌دهد، پس نخست به توافق مالک مخزن و افرادی که در آن کار می‌کنند نیاز دارد. یک فشار اجباری تعمیر نیست؛ رویدادی هماهنگی با ریسک بازگردانی خودش است. آن را زمان‌بندی کنید، نسخه پشتیبان بگیرید و به تیم بگویید چه زمانی رخ می‌دهد.
پس از آن، درخت کنونی و تاریخچه باقی‌مانده را بازبینی کنید نه آنکه به خلاصه ابزار اعتماد کنید.
نتیجه را به دو اثر نگه دارید: قالبی که اشتراکش ایمن است، و فهرست اعتبارنامه‌هایی که در فرایند ثبت‌نام صادر شده‌اند. هیچ‌یک نیاز ندارد هویت قابل استفاده‌ای در مخزن زندگی کند.
همین تفکیک راه‌حل واقعی است، و از شخص بعدی که می‌خواهد پروفایلی ثبت کند جان سالم به در می‌برد.