빌드는 초록불이었는데 그 라이브러리는 누가 넣었나 · 서명은 멀쩡한데 그 키를 우리가 회수했다 · 퀴즈
퀴즈: 서명과 검증
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
서명을 파일 전체가 아니라 다이제스트에 거는 결과로 따라오는 성질은?
- 서명 파일이 원본과 같은 크기가 된다
- 한 바이트만 달라져도 같은 서명으로 맞출 수 없게 된다
- 같은 파일에 두 번 서명하면 서명이 합쳐진다
- 공개키 없이도 검증할 수 있게 된다
회수한 옛 키로 만든 서명이 '위조' 와 다른 점은?
- 해시 알고리즘이 다르게 쓰였다는 점
- 서명 파일의 형식이 표준을 벗어난다는 점
- 수학적으로는 멀쩡한 서명이고 그 키의 공개키로는 통과한다는 점
- 서명한 시각이 기록되지 않는다는 점
sigstore 의 기본 흐름에서 서명 직후 비밀키는 어떻게 되는가?
- 곧 파기되고 짧은 수명의 인증서도 만료된다
- 투명성 로그에 암호화되어 보관된다
- 인증 기관이 대신 보관해 준다
- 사용자의 키 저장소에 자동으로 저장된다
검증 명령의 종료 코드를 파이프라인에서 보지 않으면 어떤 상태가 되는가?
- 검증이 느려져 빌드 시간이 늘어난다
- 다음 빌드에서 서명이 자동으로 다시 만들어진다
- 검증 결과가 투명성 로그에 남지 않는다
- 서명을 안 붙인 것보다 나쁜 상태가 된다 — 모두가 보호받는다고 믿는다
키를 교체할 때 옛 키를 등록부에서 그냥 지우는 대신 기한을 적는 이유는?
- 지우면 등록부 파일이 손상될 수 있어서
- 지운 키는 나중에 복구할 수 없어서
- 옛 키로 서명된 아직 배포되지 않은 릴리스가 전부 막히기 때문에
- 기한이 있어야 검증 속도가 빨라지기 때문에
cosign 이 KMS 제공자를 URI 로 가리키게 한 것이 검증 쪽에 주는 이점은?
- 서명 파일이 작아져 저장 비용이 줄어든다
- 비밀키는 보관 자리에 둔 채 공개키만 꺼내 검증할 수 있다
- 검증할 때 인터넷 연결이 아예 필요 없어진다
- 투명성 로그를 쓰지 않아도 검증이 성립한다