rhboot/shim-reviewshim 리뷰
이 저장소는 shim 서명 요청을 검토하기 위한 것입니다. 요청을 생성하려면:
참고로, 저희는 주로 Linux에서 GRUB2나 systemd-boot를 사용한 경험만 있으므로, 저희가 다른 것을 서명하도록 승인하도록 요청하려면 상당한 설득이 필요할 것입니다.
2025년 10월 20일 기준으로, Microsoft로 보내진 shim은 2011년 및 2023년 키로 서명됩니다. 제출한 각 shim에 대해 서로 다른 키로 서명된 두 개의 사본을 받게 됩니다. Microsoft의 최신 정보는 여기: https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787
새로운 서명 요구 사항도 발효되었으며, 여기에서 확인할 수 있습니다: https://techcommunity.microsoft.com/blog/hardware-dev-center/updated-microsoft-uefi-signing-requirements/1062916 이 shim 검토를 거치면, shim이 오픈 소스 부트 로더에만 핸드오프하는 한 연례 보안 감사가 면제됩니다.
힌트: 제출 및 shim 서명 관련 안내는 이 저장소의 docs 디렉토리를 확인하세요.
템플릿은 다음과 같습니다:
조직 이름 및 웹사이트:
[여기에 텍스트를 입력하세요]
검토자는 악용을 방지하기 위해 귀하의 조직이 법적实体임을 쉽게 확인할 수 있어야 합니다. 진정성을 확실히 증명할 수 있는 정보를 제공하십시오.
회사/세무 등록 항목 또는 이에 상응하는 정보:
(귀하의 관할 구역 등록부에 있는 조직 항목에 대한 링크면 충분합니다)
[여기에 텍스트를 입력하세요]
Microsoft Hardware Dev Center 파일 서명 서비스에서 .cab 파일 서명에 사용된 EV 인증서에 있는 귀하의 조직 및 발급자의 공개 세부 정보. (shim 바이너리에 포함된 CA 인증서가 아닙니다)
예시:``` Issuer: O=MyIssuer, Ltd., CN=MyIssuer EV Code Signing CA Subject: C=XX, O=MyCompany, Inc., CN=MyCompany, Inc.
*******************************************************************************
### 이 제품 또는 서비스는 무엇을 위한 것인가요?
*******************************************************************************
[여기에 텍스트를 입력하세요]
*******************************************************************************
### 전 세계가 부팅할 수 있도록 실제로 서명이 필요한 이유는 무엇인가요?
*******************************************************************************
[여기에 텍스트를 입력하세요]
*******************************************************************************
### 이미 서명된 다른 배포판의 shim을 재사용할 수 없는 이유는 무엇인가요?
*******************************************************************************
[여기에 텍스트를 입력하세요]
*******************************************************************************
### 보안 업데이트 등에 대한 기본 연락처는 누구인가요?
보안 연락처는 shim이 승인되기 전에 확인되어야 합니다. 후속 요청의 경우, 이전 성공적인 확인 이후 보안 연락처나 PGP 키가 변경된 경우에만 연락처 확인이 필요합니다.
승인된 검토자는 각 보안 연락처에게 PGP로 암호화된 이메일(임의의 단어 포함)을 보내 연락처 확인을 시작합니다.
이메일 내용을 `shim-review` 이슈에 게시하여 이메일 주소와 PGP 키의 소유권을 증명해야 합니다.
PGP 키를 keyserver.ubuntu.com과 같은 잘 알려진 키 서버에 업로드하거나, 검토에 .asc 파일로 포함시키고 여기에 링크를 제공해 주세요.
*******************************************************************************
- 이름:
- 직책:
- 이메일 주소:
- PGP 키 지문:
- 파일/키서버 위치:
*******************************************************************************
### 보안 업데이트 등에 대한 보조 연락처는 누구인가요?
*******************************************************************************
- 이름:
- 직책:
- 이메일 주소:
- PGP 키 지문:
- 파일/키서버 위치:
*******************************************************************************
### 이 바이너리가 16.1 shim 릴리스 tar에서 생성되었나요?
16.1 shim 릴리스 tar 파일을 사용하여 shim 바이너리를 생성해 주세요: https://github.com/rhboot/shim/releases/download/16.1/shim-16.1.tar.bz2
이는 https://github.com/rhboot/shim/releases/tag/16.1 과 일치하며 적절한 gnu-efi 소스를 포함하고 있습니다.
다운로드의 체크섬(SHA256, SHA512)을 다음 값과 비교하여 tarball이 올바른지 확인하세요:```
46319cd228d8f2c06c744241c0f342412329a7c630436fce7f82cf6936b1d603 shim-16.1.tar.bz2
ca5f80e82f3b80b622028f03ef23105c98ee1b6a25f52a59c823080a3202dd4b9962266489296e99f955eb92e36ce13e0b1d57f688350006bba45f2718f159fb shim-16.1.tar.bz2
빌드 프로세스가 해당 파일을 (외부 패치를 제외한) 진실의 원천으로 사용하고 있으며 체크섬이 일치하는지 확인했는지 확인하세요. 또한 PGP 서명을 확인하여 릴리스를 추가로 검증할 수 있습니다: 분리된 서명이 있습니다.
릴리스는 관리자 Peter Jones가 서명했습니다. 그의 마스터 키 지문은 B00B48BC731AA8840FED9FB0EED266B70F4FEF10이고, 여기 서명에 있는 서명 하위 키의 지문은 02093E0D19DDE0F7DFFBB53C1FD3F540256A1372입니다. 그의 공개 키 사본은 참고용으로 여기에 포함되어 있습니다:
pjones.asc
사용 중인 타르볼이 정확하고 신뢰할 수 있다고 확신하면, 여기에 간단히 yes로 확인해 주세요.
공개 키와 서명을 확인하는 방법에 대한 간단한 안내는 docs 디렉토리에서 확인할 수 있습니다.
[your text here]
힌트: 애플리케이션에 사용 중인 모든 패치와 수정 사항을 첨부하는 경우, 여기에 애플리케이션의 URL을 지정할 수 있습니다 (https://github.com/YOUR_ORGANIZATION/shim-review).
코드가 호스팅된 사용자 정의 git 서버를 가리킬 수도 있습니다.
[your url here]
빌드 과정에서 사용된 모든 외부 패치와 빌드 프로세스 수정 사항을 명시하여, 이 애플리케이션의 일부로 제출한 shim 바이너리가 정확히 일치하도록 만든 내용을 기재하세요.
[your text here]
NX 비트 없이 shim 서명에 대한 자세한 내용은 https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 를 참조하세요.
[your text here]
GRUB2를 사용하지 않는 경우 이 항목을 건너뛰세요.
[your text here]
GRUB2를 사용하지 않는 경우 이 항목을 건너뛰고, 사용 중이라면 해당 사항이 있는지 확인하고 _yes_로 확인하세요.
[your text here]
GRUB2를 사용하지 않는 경우 이 항목을 건너뛰세요. 그렇지 않으면 GRUB2 바이너리에 다음과 유사한 항목이 있습니까?
grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/?
[your text here]
이전에 서명된 shim이 없었다면 여기에 그렇게 명시하세요. 그렇지 않으면 간단한 _yes_로 충분합니다.
[your text here]
힌트: 업스트림 커널은 이 모든 것이 적용되어야 하지만, 업스트림과는 별도로 유지 관리되는 자체 대규모 수정된 이전 커널 버전을 제공하는 경우에는 그렇지 않을 수 있습니다.
이전 커널을 제공하는 경우 소스를 다시 확인하세요. 모든 패치가 없을 수 있지만, 문제를 노출하지 않는 구성을 제공할 수도 있습니다.
[your text here]
힌트: lockdown이 적용되지 않으면 shim 서명이 승인되지 않을 가능성이 높습니다.
[your text here]
[your text here]
[your text here]
[your text here]
이렇게 하면 새로운 shim+GRUB2가 문제가 있는 이전 GRUB2 바이너리를 체인로드할 수 없습니다.
첫 번째 신청이거나 새 CA 인증서를 사용하는 경우 여기에 그렇게 명시하세요.
[your text here]
리뷰어는 항상 docker build .를 실행하여 애플리케이션에 첨부한 정확한 바이너리를 얻을 수 있어야 합니다.
힌트: GCC, binutils, gnu-efi 업데이트로 인해 체크섬이 다른 shim 바이너리가 빌드될 수 있으므로 툴체인에 고정된 패키지를 사용하는 것이 좋습니다.
제공된 Dockerfile을 사용하여 shim 바이너리를 재현할 수 없는 경우, 그 이유와 차이점, 그리고 이 빌드를 재현하는 데 사용되는 빌드 환경(OS 및 툴체인)을 설명해 주세요. 이 경우 처음부터 빌드 환경을 설정하는 방법에 대한 자세한 안내를 작성해 주세요.
[your text here]
여기에는 빌드 루트 생성, 패치 적용, 빌드 수행, 아카이브 생성 등에 대한 로그가 포함되어야 합니다.
[your text here]
예를 들어, 새 커널 변형, UKI, systemd-boot, 새 인증서, 새 CA 등에 서명하는 경우 등입니다.
shim 서명 신청이 처음인 경우 이 항목을 건너뛰세요.
[your text here]
[your text here]
키 보호에 사용되는 보안 전략을 설명하세요. HSM이나 스마트카드와 같은 하드웨어 토큰 사용, 공기 격리 금고, 물리적 금고에서 기타 모범 사례까지 다양할 수 있습니다.
[your text here]
yes 또는 _no_로 답변하세요. 후자에 불이익은 없습니다.
[your text here]
yes 또는 _no_로 답변하세요. 후자에 불이익은 없습니다. 하지만, _yes_인 경우: 해당 인증서가 CA임을 명시하는 X509v3 Basic Constraints를 포함합니까? 이에 대한 자세한 안내는 docs를 참조하세요.
[your text here]
힌트: SBAT의 역사와 작동 방식에 대한 자세한 정보는 여기에서 확인할 수 있습니다. 해당 문서는 방대하므로 몇 가지 예제는 SBAT.example.md를 확인하세요.
GRUB2의 다운스트림 구현(예: Fedora 또는 Debian)을 사용하는 경우 해당 SBAT 항목을 보존하고 추가하세요(대체하지 마세요). 이를 통해 폐기가 간소화됩니다.
모든 바이너리의 항목을 게시하는 것을 잊지 마세요. 부트로더 외에도 펌웨어 업데이트 프로그램 등도 제공할 수 있으며, 이 항목도 포함됩니다.
힌트: objcopy --dump-section .sbat=/dev/stdout YOUR_EFI_BINARY를 실행하여 이러한 항목을 가져오세요. 여기에 붙여넣으세요. 각 항목을 세 개의 백틱(```)으로 감싸는 것이 좋습니다.
[your text here]
GRUB2를 사용하지 않는 경우 이 항목을 건너뛰세요.
힌트: 이는 파일 시스템의 .mod 파일이 아니라 바이너리 자체에 포함된 모듈에 관한 것입니다.
[your text here]
[your text here]
[your text here]
힌트: 가장 일반적인 경우는 fwupd와 같은 펌웨어 업데이트 프로그램입니다.
[your text here]
GRUB2 또는 systemd-boot를 사용하지 않는 경우 이 항목을 건너뛰세요.
[your text here]
보안 부트체인이 상위 수준에서 어떻게 작동하는지 한두 문장으로 요약하세요.
[your text here]
[your text here]
[your text here]
검토 프로세스는 동료 검토 노력으로, 애플리케이션을 더 빨리 검토받는 가장 좋은 방법은 다른 사람을 검토하는 데 도움을 주는 것입니다. 대부분의 경우 저희는 업무 시간 동안 애플리케이션을 검토하기 위해 고용되어 급여를 받는 것이 아니라, 자유 시간에 자발적으로 이 작업을 수행하는 자원봉사자입니다.
검토를 기다리는 합리적인 기간은 2-3개월에 이를 수 있습니다. 도움을 주시는 것이 이 기간을 단축하는 가장 좋은 방법입니다. 더 많은 도움을 받을수록 일이 더 빠르고 원활하게 진행됩니다.
새로운 참여자의 경우, 검토하기 쉬운으로 표시된 애플리케이션부터 시작하는 것이 좋습니다.
[your text here]
[your text here]