测验：引入包与完整性

验证整个包的单个哈希完整性的最大限制是什么？

• 哈希计算需要很长时间，对于大包来说不切实际
• 如果它只告诉您某些内容不同，并且您不知道哪个文件不同，那么就应该查看整个包。
• 如果压缩格式改变，即使内容相同，哈希值也会改变。
• 订单被搞乱了，因为收件人在解压之前无法检查它。

如果接收者在签名验证之前执行逐个文件的哈希匹配，会发生什么情况？

• 文件数量较多时验证时间会增加一倍
• 哈希匹配结果被缓存，因此跳过签名验证
• 排序规则本身失败，因为清单中的相对路径未解析。
• 根据舱单进行比对，其真实性尚未确认，并且对清单所做的所有更改均通过。

为什么将公钥捆绑在一起发送很危险？

• 即使持有捆绑包的人使用他或她自己的密钥对一次性更改有效负载、清单、签名和公钥，验证也会通过。
• 随着捆绑包大小的增加，有可能超出媒体导入限制。
• 如果公钥在捆绑包中，则可以反转私钥。
• 由于接收方未能在信任库中注册公钥，因此验证命令失败。

收到的捆绑包中的所有文件哈希都匹配，但只有签名验证失败。最可能的解释是什么？

• 如果在传输过程中损坏，通常可以通过重新接收来解决。
• 由于清单本身已更改，因此重新获取它并不是一个问题。
• 这是由于接收端openssl版本不同导致签名算法不兼容的情况。
• 这是违反匹配标准的情况，因为manifest中写入的路径是绝对路径。

我不应该使用什么方法来检查导入包中的二进制文件是否已更改？

• 检查格式是否与文件相同
• 将指纹与 sha256sum 进行比较
• 用head或者grep打开首页，直观比较。
• 通过 openssl 签名的清单间接验证

为什么导入封闭网络时“缺少一个依赖”的成本特别高？

• 如果安装脚本中途停止，则无法回滚。
• 如果缺少一个依赖项，整个清单哈希将不同步。
• 在签名验证步骤中不会捕获缺少的依赖项，并且仅在安装后才会显示。
• 里面没办法填，就得出去填完再审核，有的地方审核周期是每周。