버전 번호에 따른 버전 빌드 시간 해석(예: OpenSSL 1.0.1e 대 h)

버전 번호에 따른 버전 빌드 시간 해석(예: OpenSSL 1.0.1e 대 h)

최근에 새로 발견된 SSL 오류를 처리하기 위해 순수 데비안 배포판을 업그레이드했습니다. OpenSSL에서 보고한 버전 번호는 1.0.1e이며 최신은 아니지만 보고된 빌드 시간은 다음에 의해 생성되므로 중요하지 않다고 들었습니다.

openssl 버전 -b

2014년 6월 4일이에요. 따라서 "버전"이 오래되었더라도 데비안이 어떻게든 취약점을 "패치"했다고 확신합니다. 따라서 보안 게시물에서 주장하는 것처럼 1.0.1e가 패치되었기 때문에 실제로는 1.0.1h가 필요하지 않습니다.

나는 이것을 이해하지 못하는 것 같습니다. 누군가 정확히 무슨 일이 일어나고 있는지 설명해 줄 수 있습니까? 1.0.1h 대신 1.0.1e가 표시되는 경우 취약점이 패치되었는지 어떻게 알 수 있습니까? 왜 데비안은 배포판에 1.0.1h를 넣지 않습니까? 나는 그것을 이해하지 못한다.

답변1

당신은 아마도 정의에 따라 패키지 버전을 안정적으로 유지하는 Debian stable을 찾고 있을 것입니다. 특정 버전의 stable과 함께 제공되는 모든 openssl 버전은 유지됩니다. 보안 수정을 위해 데비안 관리자는 안정 릴리스를 업그레이드하는 대신 업스트림 보안 패치를 안정 릴리스로 백포트합니다. 모든 것의 최신 업스트림 버전을 원한다면 불안정한 브랜치가 필요할 것입니다.

~에서데비안 보안팀 FAQ:

Q: 이 패키지의 이전 버전을 사용하는 이유는 무엇입니까?

보안 문제를 해결하는 새 패키지를 만들 때 가장 중요한 지침 원칙은 가능한 한 적은 변경 사항을 적용하는 것입니다. 우리 사용자와 개발자는 출시 이후의 정확한 동작에 의존하므로 우리가 변경하는 사항으로 인해 누군가의 시스템이 손상될 수 있습니다. 이는 특히 라이브러리의 경우에 해당됩니다. API(애플리케이션 프로그래밍 인터페이스) 또는 ABI(애플리케이션 바이너리 인터페이스)가 아무리 작더라도 절대 변경되지 않도록 하세요.

이는 새로운 업스트림 버전으로 마이그레이션하는 것이 좋은 솔루션이 아니며 대신 관련 변경 사항을 백포트해야 함을 의미합니다. 일반적으로 말하면, 업스트림 관리자는 필요할 경우 기꺼이 도움을 주고, 그렇지 않은 경우 데비안 보안 팀이 도움을 줄 수 있습니다.

상당한 양의 소스 코드를 수정하거나 다시 작성해야 하는 경우와 같이 보안 수정 사항을 백포트할 수 없는 상황이 있습니다. 이러한 경우 새로운 업스트림 버전으로의 마이그레이션이 필요할 수 있으나 사전에 보안팀과 조율해야 합니다.

관련 정보