git 我应该将 Android 应用程序的发布密钥存储提交到团队存储库吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/33780137/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Should I commit release key store for Android app to team repository?
提问by mao
We are developing android app in team. To create signed release apk you should set key store path, password, key alias and key password. If I want me and any my team member could create signed apk with same signature should I commit key store file to source control?
我们正在团队中开发 android 应用程序。要创建签名发布 apk，您应该设置密钥存储路径、密码、密钥别名和密钥密码。如果我希望我和我的任何团队成员都可以创建具有相同签名的签名 apk，我应该将密钥库文件提交到源代码管理吗？
回答by Justin
You should not.
你不应该。
Release keystoreis the most sensitive data.
Release keystore是最敏感的数据。
In my team, there is only one people can sign the release package. (And may be one for backing up).
在我的团队中，只有一个人可以签署发布包。（并且可能是备份之一）。
All sensitive info MUSTbe ignored and we make a reference to these info.
必须忽略所有敏感信息，我们会参考这些信息。
In my team, we config like that:
在我的团队中，我们是这样配置的：
On Android Studio:
在Android Studio：
/local.propertiesfile:
/local.properties文件：
storeFile=[path/to/keystore/file]
keyAlias=[alias's key]
keyPassword=[alias's password]
storePassword=[key's password]
/app/build.gradle, configscope:
/app/build.gradle，config范围：
signingConfigs {
release {
Properties properties = new Properties()
properties.load(project.rootProject.file('local.properties').newDataInputStream())
storeFile file(properties.getProperty('storeFile'))
keyAlias properties.getProperty('keyAlias')
storePassword properties.getProperty('storePassword')
keyPassword properties.getProperty('keyPassword')
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
.
.
.
}
See my complete demo config:
查看我的完整演示配置：
apply plugin: 'com.android.application'
android {
compileSdkVersion 21
buildToolsVersion "22.0.1"
defaultConfig {
multiDexEnabled = true
applicationId "com.appconus.demoapp"
minSdkVersion 16
targetSdkVersion 21
multiDexEnabled = true
versionCode 18
versionName "1.3"
}
signingConfigs {
release {
Properties properties = new Properties()
properties.load(project.rootProject.file('local.properties').newDataInputStream())
storeFile file(properties.getProperty('storeFile'))
keyAlias properties.getProperty('keyAlias')
storePassword properties.getProperty('storePassword')
keyPassword properties.getProperty('keyPassword')
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
debug {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
applicationVariants.all { variant ->
appendVersionNameVersionCode(variant, defaultConfig)
}
}
}
dependencies {
compile 'com.google.android.gms:play-services:8.1.0'
}
回答by Eric Eskildsen
Go ahead:
前进：
- It's AES-encrypted
- You can keep the credentials outside source control (e.g., KeePass, Beyond Trust)
- No one can access the key without the credentials
- 它是 AES 加密的
- 您可以将凭据保留在源代码控制之外（例如，KeePass、Beyond Trust）
- 没有凭据，任何人都无法访问密钥
However, there are cons: You introduce some risk of it being brute-forced when you check it in. So you should do a cost-benefit analysis and figure out whether that's worth it to you.
但是，也有缺点：您在签入时会引入一些被暴力破解的风险。因此，您应该进行成本效益分析并确定这对您来说是否值得。
Another consideration is what your organization is using for config management already. If you have a system like Azure DevOps (TFS/VSTS) in place, you should try to leverage that. If you have a secret manager, you should integrate with that.
另一个考虑因素是您的组织已经在使用什么进行配置管理。如果你有一个像 Azure DevOps (TFS/VSTS) 这样的系统，你应该尝试利用它。如果你有一个秘密管理器，你应该与它集成。
There are tradeoffs:
有一些权衡：
+---------------------------+-------------------+------+--------+--------+------------------------+ | Approach | Example | Easy | Simple | Secure | Separation of Concerns | +---------------------------+-------------------+------+--------+--------+------------------------+ | Config management system | Azure DevOps | | | X | X | | Private repo: unencrypted | Cleartext secrets | X | X | | | | Private repo: encrypted | git-secret | | X | X | | | Secret manager | Azure Key Vault | | | X | X | +---------------------------+-------------------+------+--------+--------+------------------------+
Personally, if I were setting this up in a large organization, I'd shop around for a secret manager. For a personal project or small team, I'd just commit the keystore and keep the credentials elsewhere. It depends on the scope, the risks, and what infrastructure is available.
就个人而言，如果我在大型组织中设置此功能，我会四处寻找秘密经理。对于个人项目或小团队，我只需提交密钥库并将凭据保存在其他地方。这取决于范围、风险和可用的基础设施。
