تغییر نام یک کتابخانه رمزنگاری کلاینت قدیمی را درست نمی‌کند
یک پیوند نمادین تغییر می‌دهد که بارگذار کدام فایل را باز می‌کند، نه رابطی که باینری برای آن ساخته شده است. پیش از دست زدن به هر کتابخانه‌ای، نوع خطا را بررسی کنید.
خطای بارگذار را به ترتیب بررسی کنید: کدام فایل گم شده است، باینری از کدام معماری استفاده می‌کند، چه نمادی را می‌خواست، و اینکه خطا پیش از شروع فرایند رخ داده یا پس از آن. این‌ها چهار مسئله متفاوت‌اند و یک پیوند نمادین تنها اولی را حل می‌کند. انجام آن‌ها به ترتیب از نتیجه رایجی جلوگیری می‌کند که در آن کلاینت اجرا می‌شود و سپس در نخستین handshake شکست می‌خورد. این فهرست با بررسی از طریق اجراکننده واقعی پایان می‌یابد، نه با یک آزمون دستی.
پیش از هر تغییری، مسیر فایل اجرایی، معماری آن و متن نخستین خطا را عیناً یادداشت کنید.
چهار شکست متفاوت پشت یک خطا
شیء مشترک گمشده یک مسئله یافتن فایل است: بارگذار نامی را جست‌وجو کرد و چیزی نیافت. نماد گمشده یک مسئله رابط است: فایل وجود دارد اما آنچه باینری به آن ارجاع می‌دهد را صادر نمی‌کند. ناسازگاری نسخه نماد همان دسته است با جزئیات بیشتر. الگوریتم پشتیبانی‌نشده‌ای که پس از اجرا گزارش می‌شود تغییری رفتاری درون کتابخانه‌ای است که با موفقیت بار شده است. هر یک پاسخ متفاوتی می‌خواهد و تنها اولی مسئله نام است.
ldd روی باینری و readelf -d روی بخش پویای آن نشان می‌دهند چه می‌خواهد، که معمولاً برای جدا کردن مسئله فایل از مسئله رابط کافی است.
OpenSSL 3 در واقع چه می‌خواهد
راهنمای مهاجرت به OpenSSL 3 در این باره صریح است: برنامه‌هایی که برای نسخه‌های پیشین ساخته شده‌اند دست‌کم به بازکامپایل نیاز دارند و سازگاری کد منبع تضمین نمی‌شود. رابط‌ها تغییر کردند و برخی منسوخ یا حذف شدند. نام مستعار یک نام فایل نمی‌تواند بازکامپایل انجام دهد و نمی‌تواند به باینری قدیمی رابطی تازه بیاموزد. پیوند دادن کتابخانه‌ای تازه‌تر زیر نامی که قدیمی‌تر به نظر می‌رسد برنامه‌ای می‌سازد که ممکن است اجرا شود و سپس در جایی بسیار کم‌آشکار‌تر شکست بخورد.
این بدتر از یک شکست پاک است. خطای بارگذار بی‌درنگ مسئله را نام می‌برد، در حالی که شکستی دیرهنگام درون یک عملیات مانند مسئله شبکه یا اعتبارنامه به نظر می‌رسد و بررسی را به مسیر نادرست می‌فرستد.
چرا کتابخانه توزیع جای نادرستی است
جایگزینی کتابخانه توزیع برای راضی کردن یک کلاینت، محیط را برای هر برنامه روی دستگاه تغییر می‌دهد، از جمله به‌روزرسانی‌های امنیتی و هر چیزی که به رابط موجود تکیه دارد. کپی کردن کتابخانه قدیمی در کنار باینری دامنه محدودتری دارد، اما باز هم وابستگی‌ای می‌سازد که کسی باید نگهداری و وصله‌کاری کند. هیچ‌کدام مسیر سازگاری تأییدشده نیست، حتی وقتی در روز اعمال کار می‌کند. نام مستعار سراسری که پس از آزمایش باقی می‌ماند بدتر است، چون هیچ‌کس به یاد نمی‌آورد چرا وجود دارد.
کلاینت پشتیبانی‌شده و مجموعه وابستگی‌های فروشنده را برای نسخه واقعی سیستم‌عامل، معماری و دروازه به کار ببرید. قالبی از بسته که برای یک نفر کار کرد مسیر درست کنونی را اثبات نمی‌کند، و دستور کار بایگانی‌شده شاهدی درباره گذشته است.
اجراکننده را بررسی کنید، نه اجرا را
پس از جایگزینی پشتیبانی‌شده، بررسی کنید اجراکننده معمولی چه چیزی را حل می‌کند: ldd روی فایل اجرایی نصب‌شده، نسخه‌های کتابخانه‌ای که نام می‌برد، و محیطی که سرویس منتقل می‌کند. سپس احراز هویت موردنظر و یک عملیات واقعی را اجرا کنید. فراخوانی دستی با محیط تغییریافته تنها اثبات می‌کند که پوسته شما می‌تواند آن را اجرا کند. اجراکننده، ورودی میزکار یا واحد سرویس همان چیزی است که کاربران واقعاً اجرا می‌کنند.
اگر هیچ ساخت پشتیبانی‌شده‌ای وجود ندارد، از مالک VPN جایگزین یا مسیر مهاجرت بخواهید. جابه‌جایی خاموش به پروتکل دیگر، یا فرض اینکه کلاینتی با نام فروشنده آشنا دروازه را راضی می‌کند، شکست را جابه‌جا می‌کند نه اینکه آن را درست کند.
جایی که ترتیبی موقت برای سازگاری ناگزیر است، آن را مستند کنید، به همان باینری محدودش کنید و وقتی ساخت پشتیبانی‌شده رسید حذفش کنید.