开源项目如何做到不泄露配置文件中的密码信息？

[NipGeihou]

最近因为 JetBrains 的教育许可快过期了，加上 copilot 也开始收费了，但这两个都有一个政策，开源免费，同时因为在用的一个某柚经期记录 app 广告太多，于是我（后端）打算和女友（前端）一起开发并开源一个经期小程序。

那就有一个问题，我怎么才能即上传示例配置文件，又不上传配置文件中自己的一些配置信息，如数据库密码。

类似于若依这个开源项目中 https://github.com/yangzongzhuan/RuoYi-Vue/blob/master/ruoyi-admin/src/main/resources/application-druid.yml 数据库密码写的是password，难道他的开发环境数据库密码就是password吗？

[zjb861107]

https://12factor.net/zh_cn/config

[undownding]

示例配置文件我们这边用的是 .env.defaults ，
线上读取的是 .env ，
.env 加入到 .gitignore 里不进版本控制。

[Zerek]

.env 文件

[msg7086]

开发和生产环境密码不是环境变量传入的吗？

还有，你知道 JetBrains 开源许可是只可用于开发开源软件的是吧？如果你在开源项目之外还有别的项目，它们是不能用开源许可证的。

[hccsoul]

类似这样 只提交 git 版本的,里面配置为空或者默认的,dev 版本填实际,开发时候切一下就行

[xiaxiaokang]

环境变量才是王道

[SimonOne]

环境变量，github 还可以把环境变量加到 Repository secrets 里

[jorneyr]

Jasypt 加密。

[licoycn]

springboot： 在 resources 下创建 application-local.yml ，然后启动加上参数：spring.profiles.active=local
还需要在.gitignore 文件中添加：*-local.yml

[NipGeihou]

@zjb861107 学习了，有一个疑问就是这个环境变量指的是什么呢？是配置系统的环境变量，然后在 spring boot 的配置文件获取系统环境变量吗？

[lokamir]

配置启动参数就可以了

[CrazyRundong]

密码用随机生成的 key 对称加密得到密文，之后把密文存进 repo 里，用 GitHub secret 存 key 。部署时在 workflow 里通过 secret 得到 key ，再解密密文得到密码。

[qq316107934]

提醒下，Copilot 是流行的开源项目的主要维护者免费。
就算起了一个开源项目，如果不够流行的话也是不免费的。

[SenLief]

环境变量吧
dotenv

[NipGeihou]

@undownding 我之前的做法类似，不过我配置复制一份去掉敏感信息，然后命名加上.bak ，把真实的配置文件加入.gitignore ，这样别人拉下开的时候，就需要把.bak 那个文件后缀去掉，然后填写配置使用

[NipGeihou]

@msg7086 看了楼上的回答学习了，当然是用于开源项目

[NipGeihou]

@licoycn 学习了

[libook]

注意 commit 历史也不能包含敏感配置信息，否则可以被 checkout 出来。

[adoal]

只写过业务代码，没在生产环境玩过服务器运维的小盆友（也不排除有很多老手甚至所谓架构师）可能潜意识里默认认为配置文件“只能”或者“应该”从项目路径结构（当前目录或者下面的子目录）读取，所以在这个问题上会犯难。其实哪有这么愁呢？
方法一，程序里指定从 /etc/<my_project>/<some_item>.conf 这样的 site-wide global path 里读取配置，开发机和生产环境各写各的配置，互不影响，提交的代码里根本不包含配置文件，而且做部署的时候也不会覆盖现有的配置文件。缺点是如果配置文件语法、语义有版本变化，需要生产环境的运维人员配合做升级。
方法二，做两个不同的 profile ，但都是从项目内部路径读取配置。开发机用开发的 profile ，部署到生产环境用生产的 profile 构建打包。两个 profile 的配置文件加入.gitignore 确保不会提交。缺点是每次在新的开发机上 clone 出来需要自己准备配置文件。
方法三，做两个不同的 profile 。开发机用开发的 profile ，从项目内部路径读取配置。部署到生产环境用生产的 profile 构建打包，不打入配置文件，而是从 site-wide global path 里读取配置。开发 profile 的配置文件加入.gitignore 确保不会提交（其实提交了也无所谓）。集一和二的部分优缺点。
当然，做不同 profile 也有多种实现方式。一般 Java 项目是在构建时区分，某些脚本语言的项目往往在运行时通过读取环境变量或者命令行参数来区分。只要能分开，都不是大问题。

[adoal]

只写过业务代码没在生产环境玩过服务器运维但是对这个问题又困惑并且愿意较真的小盆友们还是认真玩玩服务器。比如用 Linux 的，至少了解文件系统的各部分，知道发行版打包好的基础软件是怎么使用文件系统里不同目录结构的，File-system Hierarchy Standard 是什么。虽然发行版打包好的基础软件的惯例通常不太适合 100%照搬到业务系统上，但有很大的借鉴价值，会让你们的系统部署跟运维老司机的对接更流畅。