开源Flutter应用中Crashlytics API密钥管理方案咨询

1. 调试密钥的代码库管理：通用做法与替代方案 #

• 限制权限提交是通用安全做法：把调试用的Firebase配置（比如google-services.json/GoogleService-Info.plist）提交到代码库完全可行，核心是在Firebase控制台给这个调试密钥加严格限制：
  • 绑定调试应用的包名/ Bundle ID；
  • 添加调试签名的SHA-1/SHA-256指纹；
  • 在Google Cloud控制台限制该API密钥仅能调用Firebase相关的调试API（比如Firebase Authentication、Crashlytics调试模式等）。
    这样即使密钥公开，也只有符合条件的调试应用能使用，不会被滥用。
• 替代方案：让贡献者自行配置：
  • 在代码库中提交配置示例文件（比如google-services.json.example），保留结构但替换敏感内容；
  • 文档中说明贡献者可以自己创建免费的Firebase测试项目，生成自己的配置文件替换示例，或者联系项目维护者获取专用的调试密钥；
  • 用环境变量注入密钥，比如在Flutter中通过--dart-define传递，贡献者本地配置环境变量后运行，代码库不存真实密钥。

2. 隔离Crashlytics崩溃报告的通用处理方式 #

Firebase支持通过配置隔离和权限限制来避免收到第三方修改后的崩溃报告，具体做法：

• 为贡献者分配独立测试项目：创建一个专门的Firebase测试项目，只给贡献者提供这个项目的配置文件。他们的调试/修改后的应用会把崩溃报告发到测试项目，主项目的Crashlytics只会收到正式版本或维护者测试的报告。
• 限制正式密钥的权限与使用范围：
  • 主项目的正式配置文件不要提交到代码库，仅在发布流程中通过CI/CD的环境变量注入，或者加密存储后解密使用；
  • 在Google Cloud控制台给正式API密钥设置严格限制：仅允许正式包名、发布签名指纹，且仅授权Crashlytics等必要的生产API调用；
  • 如果你只想用受限密钥处理Crashlytics，可以在Google Cloud控制台创建单独的API密钥，仅启用Crashlytics相关API，同时绑定正式应用的标识，这个密钥只在发布构建时使用，不对外公开。

内容的提问来源于stack exchange，提问作者splaytreez