开源项目:如何处理私有/秘密配置数据?

发布于 2024-11-03 07:46:30 字数 195 浏览 0 评论 0原文

我正在考虑在 Github 上开源我的实时网站的代码。到目前为止,我一直将代码存储在私有存储库中,我唯一担心的是,有一些与我的生产环境相关的配置文件(数据库密码、API 密钥等)我不想被删除公开可见。

在不暴露私人数据的情况下开源此类项目的典型方法是什么?您是否只维护两个存储库,一个公共存储库和一个相同的私有存储库(添加了私有数据),偶尔在两者之间进行合并?

I'm considering open sourcing the code for a live website of mine on Github. Up to this point, I've been storing the code in a private repo and my only concern is that there are a few configuration files related to my production environment (DB passwords, API keys, etc) that I don't want to be publicly visible.

What is the typical approach for open sourcing such projects without exposing private data? Do you just maintain two repo's, a public one and an identical private one with the added private data, occasionally merging between the two?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

濫情▎り 2024-11-10 07:46:30

对于 Git,我建议您向 .gitignore 添加规则,以忽略包含敏感信息的文件(对于 Mercurial,为 .hgignore)。尝试将敏感信息尽可能保留在一个地方(例如设置文件)。如果您使用 Web 框架,则此信息通常位于一个文件中(例如,在 Django 中,有一个包含数据库信息、密钥等的 settings.py 文件)。如果您的应用程序的各个部分都包含敏感信息,将该信息分解到某种配置文件或对象中。

如果您希望人们仍然知道数据来自哪里,请包含一个示例或虚拟文件,其中包含虚假数据,并在某处(在文件中或自述文件中)注明该文件必须更改。然后,您可以将该文件命名为 settings.py.example 并忽略真正的 settings.py

保留多个存储库是一个坏主意。只需忽略敏感数据,并确保明显地表明它丢失了以及丢失了什么,以便人们仍然可以重用您的工作。

In the case of Git, I'd recommend you add rules to your .gitignore to ignore files that contain sensitive info (.hgignore for Mercurial). Try to keep the sensitive info in one place as much as possible (e.g. a settings file). If you worked with a web framework, this info is usually in one file (for example, in Django, there's a settings.py file with DB info, secret key, etc.) If you have sensitive info ingrained in various parts of your application, factor that info out into some kind of configuration file or object.

If you want people to still know where the data is coming from, include an example or dummy file with fake data with a notation somewhere (either in the file or in the README) that the file will have to be changed. You could then name the file, for example, settings.py.example and ignore the real settings.py.

Keeping multiple repos is a bad idea. Just leave out sensitive data and make sure you make it obvious that it is missing and what is missing, so that people can still reuse your work.

听,心雨的声音 2024-11-10 07:46:30

从逻辑上讲,在不泄露敏感信息的情况下,您实际上只能做两件事:

  1. 根本不将信息放入公共 VCS。
  2. 以加密安全的方式将信息放入 VCS。

我个人不想重复存储库,如果您需要直接从 VCS 部署,那么您几乎只剩下选项 2。显然,这将取决于您的框架,但例如在 .NET 中,我会确保您的连接字符串和 API 密钥存储在 web.config 中,然后它会被正确加密(我在 面向 .NET 开发人员的 OWASP Top 10 第 6 部分:安全配置错误)。

通过这种方法,您可以将所需的信息放入配置文件中,以便它可以在发生加密的计算机上成功执行,但不能在其他地方成功执行。尝试在另一台机器上运行该应用程序,由于密钥的不同,将会引发异常。

Logically, there's really only two things you can do without disclosing your sensitive info:

  1. Not put the info into public VCS at all.
  2. Put the info into VCS in a cryptographically secure fashion.

I personally wouldn't want to duplicate repositories and if you need to deploy directly from VCS then you're pretty much left with option 2. Obviously it will depend on your framework, but in .NET, for example, I'd be ensuring your connection strings and API keys are stored in the web.config then it's properly encrypted (I talk about this in the "Encrypt sensitive configuration data" section of OWASP Top 10 for .NET developers part 6: Security Misconfiguration).

With this approach, you're putting the required info into the config file such that it can execute successfully on the machine where the encryption occurred but not elsewhere. Try running the app on another machine and an exception will be thrown due to the difference in keys.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文