Перейменування криптобібліотеки не виправить старий клієнт

Розберіть помилку завантажувача по черзі: якого файлу бракує, яку архітектуру використовує бінарний файл, який символ йому був потрібен і чи сталася помилка до або після запуску процесу. Це чотири різні проблеми, і символічне посилання вирішує лише першу. Виконання їх по черзі запобігає звичайному результату, коли клієнт запускається і потім зазнає невдачі на першому рукостисканні. Список завершується перевіркою через справжній завантажувач, а не ручним тестом.

Перш ніж щось змінити, дослівно запишіть шлях до виконуваного файлу, його архітектуру та текст першої помилки.

Чотири різні збої за однією помилкою

Відсутній спільний об'єкт — це проблема пошуку файлу: завантажувач шукав ім'я і нічого не знайшов. Відсутній символ — це проблема інтерфейсу: файл існує і не експортує те, на що посилається бінарний файл. Невідповідність версії символу — той самий клас із більшою деталізацією. Непідтримуваний алгоритм, про який повідомляють після запуску, — це зміна поведінки всередині бібліотеки, яка успішно завантажилася. Кожен вимагає іншої реакції, і лише перший є питанням імені.

ldd по бінарному файлу і readelf -d по його динамічній секції показують, що він вимагає, і цього зазвичай достатньо, щоб відокремити проблему файлу від проблеми інтерфейсу.

Що насправді вимагає OpenSSL 3

Посібник із переходу на OpenSSL 3 прямо про це говорить: програми, зібрані під попередні версії, потребують принаймні перекомпіляції, а сумісність вихідного коду не гарантується. Інтерфейси змінилися, а деякі були застарілими або вилученими. Псевдонім імені файлу не може виконати перекомпіляцію і не може навчити старий бінарний файл нового інтерфейсу. Компонування новішої бібліотеки під старомодним ім'ям дає програму, яка може запуститися і потім відмовити в куди менш очевидному місці.

Це гірше за чистий збій. Помилка завантажувача одразу називає проблему, тоді як пізній збій усередині операції виглядає як проблема мережі або облікових даних і скеровує розслідування в хибному напрямку.

Чому бібліотека дистрибутива — неправильне місце

Заміна бібліотеки дистрибутива заради одного клієнта змінює середовище для кожної програми на машині, включно з оновленнями безпеки та всім, що спирається на наявний інтерфейс. Копіювання старої бібліотеки поруч із бінарним файлом вужче, але все одно створює залежність, яку хтось має супроводжувати й латати. Жодне з них не є схваленим шляхом сумісності, навіть коли в день застосування здається, що це працює. Глобальний псевдонім, залишений після експерименту, гірший, бо ніхто не пам'ятає, навіщо він існує.

Використовуйте підтримуваний постачальником клієнт і набір залежностей для фактичного випуску ОС, архітектури та шлюзу. Формат пакета, який спрацював в однієї людини, не встановлює правильний поточний шлях, а архівний рецепт — це свідчення про минуле.

Перевіряйте завантажувач, а не запуск

Після підтримуваної заміни перевірте, що розв'язує звичайний завантажувач: ldd по встановленому виконуваному файлу, версії бібліотек, які він називає, і середовище, яке передає служба. Потім виконайте передбачувану автентифікацію та одну реальну операцію. Ручний виклик зі зміненим середовищем доводить лише те, що ваша оболонка вміє його запускати. Користувачі насправді запускають завантажувач, запис робочого столу або юніт служби.

Якщо підтримуваної збірки немає, запитайте власника VPN про альтернативу або шлях міграції. Мовчазний перехід на інший протокол або припущення, що клієнт із відомим ім'ям постачальника задовольняє шлюз, переносить збій замість того, щоб його виправити.

Там, де тимчасове рішення сумісності неминуче, задокументуйте його, обмежте тим самим бінарним файлом і вилучіть, коли з'явиться підтримувана збірка.