这是一篇来自知名Core-Lightning开发者ddustin的客座文章，他深入探索了Coldcard固件的提交历史，以揭示发生了什么以及代码失败的原因。我开始调查Coldcard黑客事件，瞬间感到震惊。我需要解释为什么。当我们开发者在编写代码时，我们将代码更改组织成我们称之为“提交”的变更集。这样做的目的是显示清晰的代码变更历史，包括为什么和如何进行变更。在出现比特币用户资金大量被盗时，这种情况显得尤为重要，这样我们才能准确调查和理解它是如何发生的。优秀的开发者编写清晰的提交信息，这些书面说明与代码更改一起，解释特定更改所达到的目的。为了制作清晰的提交信息，您通常希望提交代表较小的代码更改，这样就更少需要评论。作为开发者，一个好的目标是保持高提交信息与更改比例。您更改的代码行越多，解释更改原因的评论就越多。每个提交更多的消息和更少的代码更改一般是个好主意。以下是从我自己的一些工作中随机选择的一个示例。提交信息为235个字符，提交更改了15行代码。比例为235/15 = ~16。在Coldcard中，引入低熵错误的提交在这里。提交信息为5个字符，仅是一个单词“runs”。该提交更改了1534行代码，使比例为5/1534 = ~0.003 这是一个可怕的注释与代码更改比例。有少数少数情况下，低注释比是可以辩解的——但更改代码中最重要的部分不是其中之一！涉及项目安全关键功能的代码需要有更高的注释与更改的比率和更严格的审查。贡献于Coldcard弱熵问题的第二个提交在这里。提交信息为1个字符：只是字符“x”。该提交更改了约1000行代码，使比例为1/1000 = ~0.001 在提交标题为“runs”（比例：~0.003）的情况下，似乎他们正在导入和配置C代码，以使自定义micropython代码在STM32上工作，Coldcard运行的所有板子。STM32是这类小设备最常见的CPU，像这个提交所介绍的配置是常见的。在'runs'提交中，硬件RNG（随机数生成）被以下代码行禁用。 #define MICROPY_HW_ENABLE_RNG (0) 这就是造成错误的原因。将该值设置为零告诉默认的micropython rng代码不使用硬件RNG设备，而应使用Yasmarang RNG代替。开发者添加了一个内联评论，“解释”这一更改 // 我们有自己版本的这段代码。COLDCARD版本的这段代码似乎与rng.h和rng.c中添加的函数相关。 rng.h MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj); MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj); 这些似乎是试图覆盖stm32 rng库的`pyb_rng_getobj`函数。这种做法遇到了麻烦。stm32 rng.c文件已经定义了pyb_rng_et_obj变量，并将值设置为`pyb_mg_get`。您不能有两个同一变量的定义并让其编译。 rng.c MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get); 展开宏并从逻辑上思考，就只是这个伪代码：var pyb_rng_get_obj = pyb_rng_get 提交` 37e4af5`添加了一个自定义的rng.c文件，在那里他复制粘贴了相同的宏定义MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get); 现在没有办法让这段代码编译。开发者似乎天真地试图通过创建该变量的重复版本来覆盖`pyb_rng_get_obj`变量。C并非如此工作。这种错误会给他带来“重复符号pyb_rng_get_obj”的编译器错误，因为现在有两个地方定义了它：stm32库和新添加的rng.c文件。从这里开始，我假设在一阵沮丧中，他把`MICROPY_HW_ENABLE_RNG`设为0，这本可以解决编译器错误。有时候，当开发者感到无助时，他们会尝试随机的东西，看看是否有帮助。将`MICROPY_HW_ENABLE_RNG`设置为0会使编译器错误消失***出于错误的原因***。这将具有两个冲突定义的编译器错误扫到地毯底下。 // 我们有自己版本的这段代码。 #define MICROPY_HW_ENABLE_RNG (0) 将MICROPY_HW_ENABLE_RNG设为零完全删除了使用硬件随机数生成器的代码，或者说是stm32 rng.c文件中的31到80行。这副作用是去除了pyb_rng_get_obj的第二个定义，进而“修复”了编译器错误。编译器错误在乞求程序员重新考虑他的逻辑。最终，发生的却是编译器错误仅仅被压制了。编译器在给开发者发出警告。