dotenvy 因解析 bug 被 fork 为 dotenv-ng
We Are Forking dotenvy into dotenv-ng
我们发布了 dotenv-ng 1.0，这是一个现代化的 Rust 实现，用于加载和渲染 .env 文件。这次 fork 源于 dotenvy 的一个严重缺陷：它在读取包含 bcrypt 哈希值的密钥时，错误地将美元符号片段当作变量替换，导致秘密被篡改。尽管上游社区早在 2024 年就有人提出修复请求，但直到 2026 年仍未得到解决，而维护者长达三年的版本停滞更是让问题雪上加霜。dotenv-ng 在保持兼容性的同时，默认禁用变量替换，支持更广泛的键名语法，并提供了结构化的错误处理。我们深知 .env 不应是秘密的最终归宿，但迁移的第一步是正确读取它。
迁移离开 .env 的第一步，是正确地读取它。
- threecheese
我是不是太奇怪或者太老派了，居然依赖 direnv 而不是 .env？现在我的项目涉及很多不同的技术栈，让它们都去解析 .env 文件并指望一切正常，这感觉真的很怪。尤其是考虑到推理提供商的 token 基本上把我的银行账户直接连到了互联网上。
- hinkley
> 但迁移出 .env 的第一步是正确读取它。
我们曾有一个系统，通过内部库来中介所有对静态配置的访问。因为没人直接触碰环境相关的数据，这里就成了叠加来自 Raft 源的可重载配置、并整合通过旧式 12 要素方案传入的环境特定密钥的便利之处，当然我们也可以集成其他密钥管理方案。
或者，将其作为一个独立的 API。我发现这对那些疲惫且分心的人很有效。让安全相关的内容使用独特的代码模式来访问，确实有助于防止人们像对待其他数据那样随意对待它——即到处乱传，偶尔还写入日志。这相当于导弹发射开关的守卫与机枪扳机之间的区别。其中一种的故障模式要比另一种宽容得多。
这也是基于“能力（capability）”的系统经常遇到的问题——能力最终意味着如果你能看到某物，你就有权使用它。而当你的同事为系统添加新功能时，你最终会意外地看到那些你不该看到的东西。
比如 Java 就经常遇到这种情况。有人会在全局状态中添加一个对象，却没注意到某个同伴已经添加了一个指向该对象的引用（该对象包含专有数据，客户端代码本不该拥有这些数据）。在 […]
- a1o
结尾的 ng 是什么意思？我见过一些产品或项目加了这个后缀，但没人解释其含义。
- drdexebtjl
你不能直接转义美元符号吗？
如果你真的认为 .env 是个错误（它确实是），那就让它消亡吧。是你们现在在让它苟延残喘。
- yoyohello13
也许这是个蠢问题，但 -ng 是什么意思？我看到很多 fork 似乎都遵循 <project>-ng 的命名惯例。