如图，不管是 config task 还是 config export 都是相同的逻辑，都会替换密码。这里可以增加一个 Force 参数，让输出原始的密码么？
收到，产品需求已关注哈，原始密码不修改会有安全风险的，这块咱们是如何考虑的？
7.5 之前通过 config export 出来的配置，是可以用来start-task 的。 我们的一个任务是白名单模式，每新增一个库表，都需要修改 dm-task， 目前是写了一个脚本，使用 config export 的配置来更新 dm-task 配置的。
或者 dm 提供一个 update-task 的子命令，而不用每次都得 stop-task + start-task 的方式来修改任务也可以。
1 个赞
另外现在也只是在 dm-master 返回时做了一下替换，在 etcd 里还是明文存储的，如果有心，还是可以从 etcd 里获取到原始密码的。
最彻底的办法，其实还是开启 TLS 认证，而不仅仅是在导出时候替换下密码。建议还是给个口子让能获取到原始的配置文件。
2 个赞
修改来自于 DM/Openapi: improve password input mechanism source by WizardXiao · Pull Request #5369 · pingcap/tif
这个应该是出于用户安全性的考虑，不是 bug 是符合产品设计预期的哈！
-–
看用户的原始要求，其实只让前端展示时候过滤就行了，没必要在后端运维的 dmctl 也加密。一旦加密了，就是我跟上面提到的需求一样，会导致 dm 的运维需求没办法完全通过 dm 自身来获取到，还得借助其他的配置文件来获取对应的密码。
另外，跟我上面的提的一样，这种做法只是能限制 dm-ctl 的接口自身，限制不了 etcd 上的明文密码，想获取原始密码来是能获取到。 如果真的对安全有要求，完全可以(目前来说也只能)通过 TLS 加密，
其实 DM 提供一个 update-task 命令也可以，现在每次改配置文件都得重建任务，这才要求需要原始的数据库密码。
你能否用编辑器打开 dmctl config export 的结果确认下
我本地用 DM 8.1.1 测试了下，dmctl config export 导出的结果中密码都是正常的（根据是否配置加密 key，可能是加密的），如下：
enable-gtid: true
relay-dir: relay-dir
flavor: mysql
charset: ""
enable-relay: false
relay-binlog-name: ""
relay-binlog-gtid: ""
source-id: mysql-3306
from:
host: mysql3306.host.playground
port: 3306
user: root
password: W/nS2cAnvhFUSxtMNnadFUAQRhdaad8=
max-allowed-packet: null
session: {}
security: null
purge:
dmctl config task xxx 里面的结果是混淆后的 ******，这个行为符合预期
