此仓库用于审查签名 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 审查即可免除你的年度安全审计。
提示：请查看本仓库中的 docs 目录，以获取提交和签署 shim 的指导。
以下是模板：
组织名称和网站：
[在此处填写你的文本]
审查人员应能够轻松验证你的组织是合法实体，以防止滥用。请提供能够确切证明真实性的信息。
公司/税务登记条目或等效证明：
（提供你司法管辖区登记机构中组织条目的链接即可）
[在此处填写你的文本]
你的组织以及用于在 Microsoft 硬件开发中心文件签名服务中签署 .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` issue 中发布这些邮件的内容，以证明对电子邮件地址和 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
一旦你确定所使用的 tarball 正确且真实，请在此用一个简单的 yes 确认。
关于验证公钥和签名的简短指南，请参见 docs 目录。
[在此填写你的文本]
提示：如果你将所使用的全部补丁和修改随附到你的申请中，你可以在此指向你应用程序的 URL（https://github.com/YOUR_ORGANIZATION/shim-review）。
你也可以指向托管这些代码的自有 git 服务器。
[在此填写你的URL]
请列出在构建过程中使用的所有外部补丁和构建过程修改，正是这些修改使你的 shim 二进制文件与你在本申请中发布的完全一致。
[在此填写你的文本]
关于为未设置 NX 位的 shim 进行签名的更多详情，请参阅 https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522。
[在此填写你的文本]
如果你不使用 GRUB2，请跳过此项。
[在此填写你的文本]
如果你不使用 GRUB2，请跳过此项；否则请确保这些修复均已存在，并用 yes 确认。
[在此填写你的文本]
如果你不使用 GRUB2，请跳过此项；否则，你的 GRUB2 二进制文件中是否有类似于以下的条目：
grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/？
[在此填写你的文本]
如果你之前没有签署过 shim，请在此说明。否则，一个简单的 yes 即可。
[在此填写你的文本]
提示：上游内核通常应已应用所有这些提交，但如果你随附的是自己深度修改的旧版内核，且该内核与上游分开维护，则情况可能并非如此。 如果你随附的是较旧的内核，请仔细核对你的源码；也许你并非拥有所有补丁，但你随附的配置并不会暴露这些问题。
[在此填写你的文本]
提示：如果不能，我们很可能不会为你的 shim 签名。
[在此填写你的文本]
[在此填写你的文本]
[在此填写你的文本]
[在此填写你的文本]
这将确保你的新 shim+GRUB2 无法再链式加载那些存在问题的旧 GRUB2 二进制文件。
如果这是你的首次申请，或者你使用的是新的 CA 证书，请在此说明。
[在此填写你的文本]
审查者应当始终能够通过运行 docker build . 获得你在申请中附带的完全相同的二进制文件。
提示：建议为你的工具链使用*冻结（frozen）*软件包，因为 GCC、binutils、gnu-efi 的更新可能会导致构建出校验和不同的 shim 二进制文件。
如果你的 shim 二进制文件无法使用所提供的 Dockerfile 复现，请解释原因、会存在哪些差异，以及用于复现此构建的构建环境（操作系统和工具链）是什么？在这种情况下，请编写一份详细指南，说明如何从头搭建此构建环境。
[在此填写你的文本]
这应包括创建 buildroot、应用补丁、执行构建、创建归档文件等的日志。
[在此填写你的文本]
例如，签署新的内核变体、UKI、systemd-boot、新证书、新 CA 等。
如果这是你首次申请签署 shim，请跳过此项。
[在此填写你的文本]
[在此填写你的文本]
请描述用于密钥保护的安全策略。这可以包括使用硬件令牌（如 HSM 或智能卡）、气隙隔离的保险库、物理保险箱，以及其他良好实践。
[在此填写你的文本]
一个 yes 或 no 即可。选择后者不会有任何不利影响。
[在此填写你的文本]
一个 yes 或 no 即可。选择后者不会有任何不利影响。但是，如果为 yes：该证书是否包含表明其为 CA 的 X509v3 基本约束（Basic Constraints）？有关此问题的更多指导，请参阅 docs。
[在此填写你的文本]
提示：SBAT 的历史及其工作原理的更多信息可以在此处找到。该文档篇幅较大，因此如果只想看一些示例，请查看 SBAT.example.md。
如果你使用的是 GRUB2 的下游实现（例如来自 Fedora 或 Debian），请确保保留他们的 SBAT 条目，并追加你自己的条目（不要替换他们的），以简化撤销操作。
请记得发布所有二进制文件的条目。除了你的引导程序之外，你可能还会随附例如固件更新程序，它同样会有这些条目。
提示：运行 objcopy --dump-section .sbat=/dev/stdout YOUR_EFI_BINARY 可获取这些条目。请将它们粘贴到此处。最好用三个反引号（```）将每个条目括起来，以便良好呈现。
[在此填写你的文本]
如果你不使用 GRUB2，请跳过此项。
提示：这里指的是二进制文件本身中的模块，而不是文件系统中的 .mod 文件。
[在此填写你的文本]
[在此填写你的文本]
[在此填写你的文本]
提示：这里最常见的情况是像 fwupd 这样的固件更新程序。
[在此填写你的文本]
如果你不使用 GRUB2 或 systemd-boot，请跳过此项。
[在此填写你的文本]
请用一两句话概括你的安全启动链在更高层面上是如何工作的。
[在此填写你的文本]
[在此填写你的文本]
[在此填写你的文本]
审查过程本应是一项同行评审工作，让你的申请更快获得审查的最佳方式就是帮助审查他人的申请。在大多数情况下，我们是利用空闲时间在此志愿工作，而不是受雇于人在工作时间内领取报酬来审查这些申请。
等待审查的合理时间可能长达 2-3 个月。帮助我们就是缩短这一时间的最佳方式。我们得到的帮助越多，事情就会进展得越快、越顺利。
对于新手，建议从标记为 easy to review 的申请开始参与贡献流程。
[在此填写你的文本]
[在此填写你的文本]