クイズ: 搬入バンドルと完全性

번들 전체의 해시 하나만으로 무결성을 확인하는 방식의 가장 큰 한계는?

• 해시 계산에 시간이 오래 걸려 대용량 번들에서 실용적이지 않다
• 무언가 다르다는 것까지만 알려 주고 어느 파일이 다른지 모르면 조사할 곳이 번들 전체가 된다
• 압축 형식이 바뀌면 같은 내용이라도 해시가 달라진다
• 받는 쪽이 압축을 풀기 전에는 확인할 수 없어 순서가 꼬인다

받는 쪽이 서명 검증보다 파일별 해시 대조를 먼저 하면 무슨 일이 생기는가?

• 파일 수가 많을 때 검증 시간이 두 배로 늘어난다
• 해시 대조 결과가 캐시되어 서명 검증이 건너뛰어진다
• 매니페스트의 상대 경로가 해석되지 않아 대조 자체가 실패한다
• 아직 진위가 확인되지 않은 매니페스트를 기준으로 대조하게 되어, 목록까지 고친 변조가 전부 통과한다

공개키를 번들 안에 함께 넣어 보내면 왜 위험한가?

• 번들을 쥔 사람이 자기 키쌍으로 페이로드·매니페스트·서명·공개키를 한꺼번에 바꿔도 검증이 통과하기 때문에
• 번들 크기가 커져 매체 반입 한도를 넘길 수 있어서
• 공개키가 번들 안에 있으면 개인키를 역산할 수 있기 때문에
• 받는 쪽이 공개키를 신뢰 저장소에 등록하지 못해 검증 명령이 실패하기 때문에

받은 번들에서 파일 해시는 전부 일치하는데 서명 검증만 실패했다. 가장 그럴듯한 해석은?

• 전송 중 손상이므로 다시 받아 보면 대개 해결된다
• 매니페스트 자체가 바뀐 것이므로 다시 받는 것으로 끝날 문제가 아니다
• 받는 쪽 openssl 버전이 달라 서명 알고리즘이 호환되지 않는 경우다
• 매니페스트에 적힌 경로가 절대 경로여서 대조 기준이 어긋난 경우다

반입 번들에서 바이너리 파일이 바뀌었는지 확인할 때 쓰면 안 되는 방법은?

• file 로 형식이 그대로인지 본다
• sha256sum 으로 지문을 대조한다
• head 나 grep 으로 앞부분을 열어 눈으로 비교한다
• openssl 로 서명된 매니페스트를 통해 간접 확인한다

폐쇄망 반입에서 '빠진 의존성 하나' 의 비용이 특히 큰 이유는?

• 설치 스크립트가 중간에 멈추면 롤백이 불가능하기 때문에
• 의존성 하나가 빠지면 매니페스트 해시가 전부 어긋나기 때문에
• 빠진 의존성은 서명 검증 단계에서 잡히지 않고 설치 후에야 드러나기 때문에
• 안에서는 채울 방법이 없어 다시 나가서 담고 다시 심사를 받아야 하고, 심사 주기가 주 단위인 곳도 있기 때문에