我正在构建一个网络应用程序。它目前不是开源的，但我正在考虑将其开源，以便其他人可以修复错误，改进它，以便其他人不会怀疑我的动机（有趣的代码和为他人创建有用的工具 - 不钱）等等。它建立在 PHP 和 MySQL 之上。
我也在尝试在创建它时遵循最佳实践。例如，登录将受到 SSL 保护，密码使用 bcrypt 算法通过 PHP 的 password_hash 函数进行哈希处理，并且我在任何地方都使用准备好的语句。
但是我不确定如何进行，因为我还听说您不想将您的数据库结构暴露给其他人。我的页面上到处都是 SQL，因此其他人可以通过查看此代码来很好地了解存储的内容。我唯一确定的是，带有连接用户名/密码的脚本不应托管在我选择的源存储库中。
我如何/应该如何继续使我的代码开源？
这是一个很好的问题，答案很简单：
最佳实践不能适用于所有情况。
“不要告诉世界你使用什么安全算法”和“不要暴露你的数据库结构”的最佳实践作为一种可能的后备存在 - 以防你的代码存在安全漏洞，这要困难得多如果他们不知道它在幕后是如何工作的，有人可以利用它。显然，这两种最佳实践都与开源直接冲突，因此您应该首先关注不存在安全漏洞。幸运的是，打开您的源代码将对此有所帮助。
依靠对架构保密来保护您的系统并不是一个好的起点。这不是 Kerchoff 的原则，但如果您的系统的安全性依赖于模式的模糊性，那么即使您将其保持为封闭源代码并且不将其提供给其他任何人，您也会遇到问题。
具有连接用户名/密码的脚本不应托管在源存储库中
不。
您当然不想将数据库凭据放在公共存储库中，但您应该将用于管理和应用它们的代码放在报告中。您可以在 repo 中使用虚拟值，从平面文件或环境中读取它们，使用 PHP.ini 中的默认值，使用存储在会话中的用户提供的凭据，限制对 localhost' 的访问并且不需要密码...... .可能有很多解决方案。
但是我不确定如何进行，因为我还听说您不想将您的数据库结构暴露给其他人。
您不想公开它们，因为如果存在 SQL 注入，它们就知道要定位哪些表。但是，如果存在 SQL 注入来实现这一点，那么它是一种没有实际意义的保护，因为您的安全性已经被破坏。特别是因为大多数 PHP/SQL 应用程序很少设置适当的 SQL 用户权限。因此，大多数情况下，攻击者可以转储您的结构而无需猜测它。
我唯一确定的是，带有连接用户名/密码的脚本不应托管在我选择的源存储库中。
许多项目通过提供示例配置来解决这个问题，然后通过他们的版本控制软件创建一个规则，防止他们的配置被推送到版本控制存储库。例如，他们可能有一个名为 config-EXAMPLE.php 的示例配置，一旦信息可用，他们的设置脚本就会将其重命名为 config.php（或从头开始创建）。如果他们使用 Github，例如包含一个.gitignore规则来阻止 config.php，这将确保他们不会意外暴露自己的配置。
它目前不是开源的，但我正在考虑将其开源，以便其他人可以修复错误，改进它......
发表此声明时不要忘记安全性。开源最好的一点是其他人可以发现你没有发现并修复或改进它。这包括安全性。开源您的项目可能会解决比它暴露的更多的安全问题。