Devuan machine-id 补丁 - 解决问题还是冒烟？

Question

由于在Slashdot报道，Devuan最近推出了具有以下补丁说明：

几天前，Devuan ASCII 2.1 发布了，但大多数媒体都忽略了一个更新：我们的 dbus 补丁可以在每次启动时重新生成机器 ID。

这个补丁对每个人的隐私都很重要，我希望更多的发行版能效仿我们的例子，更不用说 Debian。我们正在处理重要的隐私问题：未经同意的用户跟踪在许多国家/地区都是非法的，到目前为止，机器 ID 文档中甚至都没有提到。

因此，补丁的作用是将机器跟踪限制在重新启动之间的时间段内，而不是重新安装操作系统之间的时间段。

我不太明白这如何解决它打算解决的问题。最多，它减轻了它。但是，如果 D-Bus 在网络上使用机器 ID 的整个想法始终如一地自我识别您的机器，那么隐私问题似乎与 D-Bus 本身有关，而这个“操纵”补丁解决这个问题似乎是一种奇怪的方式。

有人可以解释这里的理由吗？

Answer 1

据我了解，理由是

• machine-id 是世界可读的（对于“world”的某些值意味着计算机上的任何进程，默认情况下它不会公开）；
• 有些人报告说它正在被潜在的恶意程序（包括 Chromium）读取；
• 任何重要的东西似乎都不需要它（或者至少，它不需要包含一个稳定的值）；
• 至少在 Devuan 中，在每次启动时生成它似乎不会破坏任何东西，并且它减少了机器的可识别表面，因此不妨这样做。

讨论从邮件列表和IRC 开始。

我不确定所有声明都是准确的，或者至少，它们都适用于所有发行版；但正如亚当·博罗夫斯基所说，

对此事的任何想法都表示赞赏，但我想对来龙去脉的具体见解更有用（阅读：请让我们避免无用的无知的火焰：P）。

现实一点......避免不知情的火焰将违反我们的规则:)

Chromium 使用机器标识符进行令牌存储，据我所知它不会将它暴露在外面（至少，不是没有按照machine-id文档中的建议屏蔽它）。我不知道机器 id 的更改对 Chromium 有什么影响，如果有的话。Debian 档案库允许搜索所有源代码："machine-id"并且sd_id128没有显示任何其他看起来特别危险的东西（这并不意味着在未来的某个时候不会有）。

在基于 systemd 的系统上，更改机器标识符确实会产生一个结果：journald依赖它来存储其日志（请参阅 参考资料/var/log/journal）。具有讽刺意味的是，基于 systemd 的发行版可以设置为非常轻松地更改其机器标识符：如果/var/lib/dbus/machine-id和/etc/machine-id为空或在启动时丢失，则重新生成机器标识符。

请注意，D-Bus 仅真正用于计算机本地通信（尽管理论上支持远程通信）。机器标识符对于远程集中式日志很有用，但同样，这主要与运行 systemd 的系统有关，或者在管理员专门使用机器 ID 作为标识符的设置中 - 在后一种情况下，管理员还可以覆盖任何选择分销使。

D-Bus 文档明确允许在 Devuan 中实现不同的机器标识符：

至少在该系统下次重新启动之前，该 UUID 对于单个系统上的所有进程必须相同。如果可能的话，它在重新启动时应该是相同的，但这并不总是可以实现并且不能保证。

（“此 UUID”是机器 ID。）

JdeBP 有一个关于该主题的页面，其中包含更多信息。