DuckDB 1.4版本增加了数据库加密功能， 截止目前为止，DuckDB涉及到Secrets的主要包括如下：

• 原生Secret：如S3和兼容存储服务的的AK/SK，http资源访问的token，huggingface和数据库访问的账号密码等
• DuckLake：主要是MySQL/PostgreSQL元信息数据库的账号密码，S3服务的AK/SK等，这个是DuckLake的核心配置
• 加密数据库：是对整个数据库的加密，使用AES 256进行加密，加密密码由用户提供

DuckDB虽然提供了Secret的管理能力，但是并没有达到安全的需求，而且用户使用体验也有一些问题，如：

• Temporary Secrets：临时Secret，保存在内存中，进程退出后就会丢失，所以要每次都要创建，如S3的AK/SK，我都是每次创建，反复copy创建Secret的SQL。
• Persistent Secrets: 持久化Secret，默认以未加密的方式保存在$HOME/.duckdb/stored_secrets目录下

鉴于DuckDB的Secret管理的加密特性缺失，所以也有不少人建议使用KMS来进行加密，而且好像也没有第三方的扩展来支持这一点。

此外如果你稍不留意的话，你创建的Secret的SQL语句就会被记录到$HOME/.duckdb_history文件中，这个文件也是明文保存的。

目前Dotenvx的私钥格式为64位的Hex字符串，如9b2c72f2b94ea2396514e7256f3a68f0cf138fba0cf615a94b520f5， 在产品环境中，你需要为私钥设置对应的环境遍历，如DOTENVX_PRIVATE_KEY，然后dotenvx命令行或者SDK就会读取该值， 然后执行对应的解密操作。

在运维中，由于这一串秘钥并没有其他辅助信息，所以导致运维时要了解该秘钥更多的信息，可能就比较麻烦， 比如，项目的名称信息，管理人员等，最好是能在私钥上添加一些元数据支持，如下：

9b2c72f2b94ea2396514e7256f3a68f0cf138fba0cf61f5d8a25901e{app=demo11;owner=xxxx,env=prod}

通过介入花括号，然后添加一些元信息，这样就可以对私钥有一个大致的了解，也不会造成一些误操作，如copy错私钥信息， 搞错环境等。

在软件开发12要素之开发环境与线上环境等价一篇中， 我们可以得知要尽可能的保持开发，预发布，线上环境相同，但是要做到这一点，困难还不小。

从以往经验来看，开发环境（即开发人员的本地部署）和线上环境（外部用户访问的真实部署）之间存在着很多差异， 其中一个非常重要的差异就是配置。在开发人员的本地部署环境中，我们通常会使用本地的配置文件，如.env或者application.properties， 鉴于开发环境的配置私密性要求不高，如root用户名，123456为密码，这些关系也不大，所以这些文件都是直接提交到git仓库中。

但是线上环境就不一样啦，我们并不能将线上环境的私密信息直接写到文件中，我们需要借助Config Server或者秘钥管理系统， 从远程服务中获取配置，然后转换为本地配置文件或者环境变量，或者注入到应用的框架中，如Spring Cloud等， 这样就可以保证线上环境的一定安全性，同时也能保证应用的正常启动。

上述的情况，就是不同环境割裂的原因，也是为何尽量保持环境相同的难点。要想做到各个环境的差异最小，我们看一下dotenvx如何做到的。

Node.js 20以上版本，你已经不需要使用dotenv npm了，Node.js 20已经内置了env文件支持。 通过--env-file选项，你可以指定一个env文件，然后Node.js会自动加载这个文件，并将其内容加载到process.env中。 命令行为： node --env-file=.env app.js

当然你也可以通过process.loadEnvFile()方法来加载env文件，例如：

(async () => {
  await process.loadEnvFile('.env');
  console.log(`Server is running on port ${process.env.PORT}`);
})();

如果你使用Bun或者Deno的话，也包含同样的命令行参数。

在如何在Spring Boot中集成Dotenvx保护你的配置项？一文中我们介绍了如何在Spring Boot项目中集成Dotenvx，从而保护你的配置项。 这篇文章我们将介绍一下Dotenvx的软连接特性，可以就可以让你快速地访问Spring Boot中配置的服务，如MySQL、Redis等。

数据库(MySQL/PostreSQL)和Redis基本上是Spring Boot应用中的标配，样例配置如下：

spring.datasource.url=jdbc:mysql://localhost:3306/test
spring.datasource.username=root
spring.datasource.password=encrypted:xxxxx

Spring Boot配置完成后，Spring Boot应用就可以访问数据库啦，你也不用担心密码泄露。

接下来你会在IntelliJ IDEA中会配置对应的数据库连接，这样做我们就可以在IDE中直接查看数据， 同时数据库的schema信息，也可以帮助到代码提示、代码审核等。

但是在一些场景中，我们可能还是需要用到mysql命令，如配合一些自动化操作，同时一些同学也非常喜欢命令行操作方式。 但是要每次输入数据库密码，非常麻烦。或者将数据库密码写到命令行中，这样也不安全。

Minisign是一个非常轻量级的数字签名工具，基于Ed25519算法实现，主要用于对文件进行签名和验证，确保文件的完整性和真实性。 完整性是指文件在传输或存储过程中没有被篡改，而真实性则是指文件确实是由声称的作者所创建的。

Minisign在签名前会生成一对公钥和私钥，私钥用于签名文件，而公钥则用于验证签名。这样，任何拥有公钥的人都可以验证文件是否被篡改过，当然也可以确认文件确实是由私钥持有者所签名的。

通过minisign -G -W即可生成一对公钥和私钥，公钥文件为minisign.pub，私钥文件为$HOME/.minisign/minisign.key，请妥善保管好私钥文件。

Tips: 如果你要使用password保护生成的秘钥，请使用minisign -G命令，会提示你输入password。后续签名文件时，也需要输入该password。

如果你检查一下public key文件，你会发现公钥

在之前的一篇文章中，我们介绍了AI编程：配置先行，讨论了配置在AI编程中的重要性，它是编程中不可缺少的一环， 不单是代码和配置的分离，更是AI Agent生成代码时的重要上下文信息来源。

我们希望AI Agent能够读取配置文件中的配置项，从而生成更符合我们需求的代码片段，但是我们也不希望AI Agent读取敏感信息，如数据库密码、API Key等， 造成敏感信息的泄露。那么Dotenvx在这方面能提供什么帮助呢？

目前不少AI工具都会支持.aiignore这些文件，用于告诉AI Agent忽略某些文件或者目录， 如Cursor有自己的.cursorignore，详细可以参考 https://cursor.com/cn/docs/context/ignore-files

dotenvx link <command>命令可以创建命令软连接，这个是对原有命令的封装。当你执行软连接命令式，其实是由Dotenvx命令行来执行的， 然后会加载配置文件，然后再执行原命令，这样就完成了对原命令的.env配置集成。

在日常中，只要涉及到诸如数据库的场景，数据库的链接信息已经在.env或者application.properties中配置好啦，如MySQL， 我通常会执行dotenvx link bin/mysql创建对应的dotenvx软连接，然后执行./bin/mysql， 就可以登录配置项指定的MySQL数据库了，不需要输入任何账户密码，非常方便。 同时也不用担心密码泄露的问题，之前都是保存在某一justfile中，密码也是直接写到文件中的，你当然可以不写， 但是公司内部的防弱密码政策，完全让我记不住这些密码，手动输入非常麻烦。

那有同学会问，使用这种软连接方式会不会增加额外的内存占用呢？效率高吗？这里给大家做一个简单的对比。

Dotenvx采用非对称加密，也就是使用public key加密，使用private key进行解密，加密后的内容使用base64进行文本化， 典型的样例就是encrypted:xxxx这样的加密文本值。

在一个典型的.env文件中，保存有普通文本配置，加密项配置和Public Key，然后根据Public Key查找到对应的private key， 就可以进行解密，这个算法也是公开的。

但是在企业内部，处于较高的安全需求，希望即便拿到了private key，也无法解密配置项。那么如何做到这一点呢？

Dotenvx企业版本提了一个加密值混淆的特性，也就是说加密的值，也就是对应的字节数组，会在进行一次混淆，然后再以文本方式呈现出来， 在界面的时候，你需要知道对应的混淆算法，然后才能进行解密。

最新的Dotenvx 0.4.26版本，增加了新的dotenvx lint命令，可以帮助你检查.env文件中的配置项是否符合规范。 dotenvx lint命令基于dotenv-linter 4.0。

dotenv-linter默认包含的规则如下：

• ✅ Duplicated key
• ✅ Ending blank line
• ✅ Extra blank line
• ✅ Incorrect delimiter
• ✅ Key without value
• ✅ Leading character
• ✅ Lowercase key
• ✅ Quote character
• ✅ Schema violation
• ✅ Space character
• ✅ Substitution key
• ✅ Trailing whitespace
• ✅ Unordered key
• ✅ Value without quotes

考虑到dotenvx的一些特殊性，如DOTENV_PUPLIC_KEY在文件开头位置，所以dotenvx lint命令会自动忽略❌ Unordered key，这个大家注意一下。