Should I commit release key store for Android app to team repository?

Question

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?

Answer 1

You should not.

Release keystore is the most sensitive data.

In my team, there is only one people can sign the release package. (And may be one for backing up).

All sensitive info MUST be ignored and we make a reference to these info.

In my team, we config like that:

On Android Studio:

/local.properties file:

storeFile=[path/to/keystore/file] keyAlias=[alias's key] keyPassword=[alias's password] storePassword=[key's password] 

/app/build.gradle, config scope:

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' } 

Answer 2

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

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.

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.