对于一个宠物项目，我开发了一个桌面应用程序，它需要来自多个不同网络服务的 API 密钥。
我一直在研究并准备将此应用程序开源，并遇到如何处理这些密钥的问题。
问题是这样的：我的理解是，使用应用程序或查看/修改源代码的任何人都不应该看到这些 API 密钥。在 Web 服务端，这些 API 密钥用于识别访问其 API 的应用程序，并根据需要允许/阻止使用。在大多数接收这些密钥的服务条款中，实际上明确指出不得与世界共享这些密钥。
目前我所有的密钥都是硬编码的，但对于如何处理开源应用程序中私钥的情况我陷入了僵局：
-如果密钥保持硬编码，一旦我的源代码发布，它们就会公开可见。
-从那时起，我真的无法省略带有代码分发中的密钥的源文件 它不会编译。这在技术上解决了问题，但引入了新的、不可接受的 一个。
-如果我将按键推到 .ini 或其他配置文件，并且只是不包含该文件 在我的公共代码存储库中，它仍然必须与我的应用程序的二进制文件一起分发才能使应用程序运行，因此我的密钥将在应用程序分发而不是源分发中可见。不是进步。我尝试在此 INI 文件上使用的任何加密操作都会增加任何试图修改我的代码的人的复杂性。
那么，对于我的代码库（目前在 Mercurial 下进行版本控制），管理一切的最佳方法是什么，以便代码可以公开，但我的密钥保持私有？
不知道您使用的是什么语言，但例如在 C/C++ 中，您可以添加一个包含 API 密钥的包含文件，然后将其置于源代码控制之外，而是添加一个带有 显式伪造 API 的伪造文件键。大多数语言都有一种或另一种包含文件的方式。
您的应用程序应该使用配置文件。该配置文件在运行时加载，不应影响编译。允许用户下载二进制文件并仍然使用自己的 api 密钥。
正如 Kornel 所说，您可以在源代码管理中包含一个带有假 API 密钥的示例配置文件。
另一种选择，您可以与运行网络服务的人员交谈并要求两件事之一。
临时密钥，仅适用于有限的功能。这将使用户看到您应用程序的基本功能，但有些人永远不会更新密钥，而只使用基本功能。
与网络服务联系，看看他们是否会为您的应用程序提供一个特殊的 API 密钥。开源版本将要求用户输入自己的版本。但您的二进制文件可以使用标准二进制文件。
使用 api 密钥配置的想法并不新鲜或闻所未闻。 Bit.ly 服务可以做到这一点。我看到的所有提供与 Bit.ly 一起使用的开源应用程序都要求您提供用户名和 api 密钥，然后才能使用它。
这没有什么不同吗？