Přejmenování kryptografické knihovny starý klient nespraví
Symbolický odkaz mění, který soubor zavaděč otevře, ne rozhraní, proti kterému byl binární soubor sestaven. Než se dotknete jakékoli knihovny, zjistěte typ selhání.
Projděte chybu zavaděče popořadě: který soubor chybí, jakou architekturu binární soubor používá, který symbol chtěl, a zda k selhání došlo před spuštěním procesu, nebo po něm. To jsou čtyři různé problémy a symbolický odkaz řeší jen první z nich. Provádění v tomto pořadí zabrání obvyklému výsledku, kdy se klient spustí a potom selže při prvním handshake. Kontrolní seznam končí ověřením přes skutečný spouštěč, nikoli ručním testem.
Před jakoukoli změnou si doslova poznamenejte cestu ke spustitelnému souboru, jeho architekturu a první chybu.
Čtyři různá selhání za jednou chybou
Chybějící sdílený objekt je problém hledání souboru: zavaděč hledal jméno a nic nenašel. Chybějící symbol je problém rozhraní: soubor existuje a neexportuje to, na co se binární soubor odkazuje. Nesoulad verze symbolu je stejná třída s více podrobnostmi. Nepodporovaný algoritmus hlášený po spuštění je změna chování uvnitř knihovny, která se načetla úspěšně. Každý vyžaduje jinou reakci a jen první je otázkou jména.
ldd na binární soubor a readelf -d na jeho dynamickou sekci ukazují, co vyžaduje, což obvykle stačí k oddělení problému souboru od problému rozhraní.
Co OpenSSL 3 skutečně vyžaduje
Průvodce migrací na OpenSSL 3 to říká přímo: aplikace sestavené proti starším verzím potřebují přinejmenším rekompilaci a kompatibilita zdrojového kódu není zaručena. Rozhraní se změnila a některá byla označena za zastaralá nebo odstraněna. Alias názvu souboru nemůže provést rekompilaci a nemůže naučit starý binární soubor nové rozhraní. Propojení novější knihovny pod názvem, který vypadá starší, vytváří program, který se může spustit a potom selhat na mnohem méně zřejmém místě.
To je horší než čisté selhání. Chyba zavaděče pojmenuje problém okamžitě, zatímco pozdní selhání uvnitř operace vypadá jako problém sítí nebo přihlašovacích údajů a vyšetřování nasměruje špatným směrem.
Proč je distribuční knihovna špatné místo
Nahrazení distribuční knihovny kvůli jednomu klientovi mění prostředí pro každý program na stroji, včetně bezpečnostních aktualizací a všeho, co spoléhá na stávající rozhraní. Zkopírování staré knihovny vedle binárního souboru je užší, ale stále vytváří závislost, kterou musí někdo udržovat a záplatovat. Ani jedno není schválená cesta kompatibility, i když se v den použití zdá, že funguje. Globální alias ponechaný po experimentu je horší, protože si nikdo nepamatuje, proč existuje.
Použijte dodavatelem podporovaný klient a sadu závislostí pro skutečnou verzi operačního systému, architekturu a bránu. Formát balíčku, který někomu fungoval, neprokazuje správnou současnou cestu a archivovaný recept je dokladem o minulosti.
Ověřte spouštěč, ne spuštění
Po podporované výměně zkontrolujte, co normální spouštěč vyřeší: ldd na nainstalovaný spustitelný soubor, verze knihoven, které uvádí, a prostředí, které služba předává. Potom spusťte zamýšlenou autentizaci a jednu skutečnou operaci. Ruční volání s upraveným prostředím dokazuje jen to, že váš shell ho dokáže spustit. Spouštěč, položka na ploše nebo služba je to, co uživatelé skutečně spouštějí.
Pokud podporované sestavení neexistuje, požádejte vlastníka VPN o alternativu nebo cestu migrace. Tiché přepnutí na jiný protokol nebo předpoklad, že klient se známým jménem dodavatele bráně vyhoví, selhání přesouvá, místo aby ho opravil.
Kde je dočasné uspořádání kompatibility nevyhnutelné, zdokumentujte ho, omezte na tento binární soubor a odstraňte, až podporované sestavení dorazí.