作为SlashDot 报道，Devuan 最近推出了一个补丁，内容如下描述：
几天前，Devuan ASCII 2.1 发布了，但大多数媒体都忽略了一项更新：我们的 dbus 补丁，用于在每次启动时重新生成机器 ID。
这个补丁关系到每个人的隐私，我希望更多的发行版能够效仿我们的例子，更不用说 Debian 了。我们正在处理重要的隐私问题：未经同意的用户跟踪在许多国家/地区都是非法的，到目前为止甚至在机器 ID 文档中都没有提及。
因此，该补丁的作用是将机器跟踪限制在重新启动之间的时间段内，而不是重新安装操作系统之间的时间段内。
我不太明白这如何解决它想要解决的问题。顶多是缓解一下。但是，如果在网络上使用 D-Bus 时使用机器 ID 的整个想法始终是自我识别您的机器，那么隐私问题似乎与 D-Bus 本身有关，并且这个“偷工减料”补丁似乎是一种奇怪的解决方法。
有人可以在这里解释一下原理吗？
答案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 总线文档明确允许使用 Devuan 中实现的不同机器标识符：
对于单个系统上的所有进程，该 UUID 必须相同，至少在该系统下次重新启动之前是如此。如果可能的话，重新启动后应该是相同的，但这并不总是可以实现并且不能保证。
（“此 UUID”是机器 ID。）
JdeBP有有关该主题的页面有更多信息。