암호 라이브러리 이름을 바꾼다고 오래된 클라이언트가 고쳐지지 않는다

로더 오류를 순서대로 짚어 보라. 어떤 파일이 없는지, 바이너리가 어떤 아키텍처를 쓰는지, 어떤 심볼을 원했는지, 그리고 실패가 프로세스 시작 전에 일어났는지 후에 일어났는지. 이는 네 가지 서로 다른 문제이며, 심볼릭 링크는 첫 번째만 해결한다. 순서대로 처리하면 클라이언트가 뜬 뒤 첫 핸드셰이크에서 실패하는 흔한 결과를 막을 수 있다. 점검 목록은 수동 테스트가 아니라 실제 실행기를 통한 검증으로 끝난다.

무엇이든 바꾸기 전에 실행 파일의 경로, 아키텍처, 첫 오류 메시지를 그대로 기록하라.

하나의 오류 뒤에 있는 네 가지 실패

공유 객체가 없는 것은 파일 탐색 문제다. 로더가 이름을 찾았지만 아무것도 발견하지 못했다. 심볼이 없는 것은 인터페이스 문제다. 파일은 존재하지만 바이너리가 참조하는 것을 내보내지 않는다. 심볼 버전 불일치는 세부 정보가 더 붙은 같은 부류다. 시작 후 보고되는 미지원 알고리즘은 성공적으로 로드된 라이브러리 내부의 동작 변화다. 각각 다른 대응이 필요하며, 이름의 문제인 것은 첫 번째뿐이다.

ldd 바이너리와 readelf -d 그 동적 섹션에 대해 실행하면 무엇을 요구하는지 보여 주며, 보통 이것만으로 파일 문제와 인터페이스 문제를 구분할 수 있다.

OpenSSL 3이 실제로 요구하는 것

OpenSSL 3 마이그레이션 안내서는 이 점을 분명히 한다. 이전 버전에 맞춰 빌드된 애플리케이션은 최소한 다시 컴파일해야 하며, 소스 호환성은 보장되지 않는다. 인터페이스가 바뀌었고 일부는 폐기되거나 제거되었다. 파일 이름 별칭은 재컴파일을 할 수 없고, 오래된 바이너리에 새 인터페이스를 가르칠 수도 없다. 더 새로운 라이브러리를 더 오래돼 보이는 이름으로 링크하면 시작은 되지만 훨씬 덜 분명한 지점에서 실패하는 프로그램이 만들어진다.

그것은 깔끔한 실패보다 나쁘다. 로더 오류는 문제를 즉시 지목하지만, 작업 도중 늦게 발생하는 실패는 네트워크나 자격 증명 문제처럼 보여 조사를 엉뚱한 방향으로 보낸다.

배포판 라이브러리가 잘못된 이유

클라이언트 하나를 만족시키려고 배포판 라이브러리를 바꾸면 보안 업데이트와 기존 인터페이스에 의존하는 모든 것을 포함해 그 기계의 모든 프로그램 환경이 바뀐다. 오래된 라이브러리를 바이너리 옆에 복사하는 것은 범위가 좁지만, 누군가 유지하고 패치해야 하는 의존성을 여전히 만든다. 둘 다 승인된 호환 경로가 아니며, 적용한 날 동작하는 것처럼 보여도 마찬가지다. 실험 후 남겨진 전역 별칭은 더 나쁘다. 왜 존재하는지 아무도 기억하지 못하기 때문이다.

실제 OS 릴리스, 아키텍처, 게이트웨이에 맞는 공급업체 지원 클라이언트와 의존성 집합을 사용하라. 한 사람에게 통했던 패키지 형식이 올바른 현재 경로를 입증하지는 않으며, 보관된 요리법은 과거에 대한 증거일 뿐이다.

실행기를 검증하라, 실행이 아니라

지원되는 교체 후에 정상 실행기가 무엇을 해석하는지 확인하라. ldd 설치된 실행 파일에 대해, 그것이 지목하는 라이브러리 버전과 서비스가 전달하는 환경을 본다. 그다음 의도한 인증과 실제 작업 하나를 실행하라. 환경을 바꾼 수동 호출은 셸이 그것을 시작할 수 있다는 것만 증명한다. 사용자가 실제로 실행하는 것은 실행기, 데스크톱 항목, 또는 서비스 단위다.

지원되는 빌드가 없으면 VPN 소유자에게 대안이나 마이그레이션 경로를 문의하라. 조용히 다른 프로토콜로 바꾸거나 익숙한 공급업체 이름의 클라이언트면 게이트웨이를 만족한다고 가정하는 것은 실패를 고치는 대신 옮기는 일이다.

임시 호환 조치가 불가피하면 문서화하고, 그 바이너리로 범위를 제한하고, 지원되는 빌드가 나오면 제거하라.