配置日志里的四个星号：比特币核心 SENSITIVE 参数掩码与它的盲区

一、日志里那行 Config file arg

比特币核心启动时会在 debug.log 里把生效配置逐条打印一遍，形如 Config file arg: section argname=value 与 Command-line arg: argname=value。这是运维取证的第一现场：哪份配置生效、值到底是多少，日志一行见分晓。但密码类参数显然不能这样裸奔，v31.0 源码的参数管理器里为此设了一个 SENSITIVE 标志位，命中的参数在日志里一律以四个星号现身。本文按 v31.0 源码核对这条掩码的覆盖面与它管不到的位置。

二、掩码在源码里的形状

参数注册时每个开关都带一组标志位，src/common/args.h 里定义了 SENSITIVE = 0x400。日志打印函数（src/common/args.cpp 的 logArgsPrefix）逐条取回参数的注册标志，只要 SENSITIVE 位为真，写入日志的值就直接替换成 ****，否则原样输出。v31.0 里带这个标志的注册项集中在四个：-rpcuser、-rpcpassword、-rpcauth 和 -torpassword。也就是说，这四个参数即使直接写在 bitcoin.conf 或命令行里，debug.log 落盘时也只剩星号。

顺带一提，rpcauth 本身就推荐用加盐哈希形态代替明文 rpcpassword，掩码是第二层保险；两者叠加才构成”配置文件加日志都不含可直接复用口令”的完整姿态。

三、掩码管不到的三条泄露面

第一，进程命令行。启动参数是操作系统层面可见的：同一台机器上的任何用户执行一次进程列表，就能看到 rpcpassword 的明文——日志只是被打了码，/proc 没有。因此共享主机上密码不该走命令行传入，配置文件权限加参数掩码，或走 rpcauth 哈希才是常态做法。

第二，settings.json。GUI 修改的设置写入数据目录的 settings.json，这份文件不经过 SENSITIVE 标志体系；被掩码的那四个参数按常规不进 GUI 设置项，但要清楚 settings.json 的明文属性质——它管着的反而是修剪开关、语言这类偏好。

第三，RPC 会话本身。掩码管的是”节点写日志”这个动作；getnetworkinfo 等 RPC 返回里本来就不回显口令，但若你在外部脚本里用 echo 或调试打印输出了命令行参数，那是你的日志在泄密，与节点无关。审计泄露面时要把自己写的包装脚本一并列入。

四、日志审计姿势

节点交给他人排障前，debug.log 是一份值得预检的对外产物。常规流程：先确认启动方式不含明文密码参数，再检查日志内是否出现任何以明文出现的敏感值——正常情况应为四颗星。若日志来自旧版本，注意该机制生效版本较早，但个别发行衍生版可能改动日志管道，跨发行版取证时逐行肉眼看一遍最稳。此外日志轮转与收集管道（容器 stdout、日志代理）都会原样搬运星号，不会二次泄密，但会把星号周围的其他上下文（IP、路径）照搬——隐私清理时重点看这些。

五、小结

SENSITIVE 是”最低成本的一处防呆”：注册参数时多打一个标志位，日志管道就多一道自动掩码。它解决的是”密码在日志里沉睡多年”的被动泄露，解决不了”密码在命令行里裸奔”的主动暴露。完整姿势仍然是三层：配置文件权限收紧、能哈希不存明文、日志外发前人工过目。

六、一份可执行的脱敏检查表

把前面的规则落成清单：其一，配置文件里确认四个敏感参数的写法——能改 rpcauth 哈希就不写 rpcpassword，torpassword 若必需则收紧文件权限到仅属主可读；其二，启动方式确认密码没有以命令行参数形态出现，systemd 单元里同样不要把 rpcpassword 写进 ExecStart，可改用配置文件；其三，外发 debug.log 前搜一遍星号是否出现在预期位置，同时删掉日志中与排障无关的主机名与路径行；其四，容器化部署确认 stdout 收集链路不带配置回显参数。四条做完，日志这条被动泄露面基本收敛，剩下的主动面——脚本打印、工单附件、聊天记录——只能靠流程约束，这是任何自动掩码都替代不了的部分。

风险提示：本文涉及服务器与节点运维安全，请以防御使用为限。本文不构成投资建议。