Мы разрабатываем приложение для Android в команде. Чтобы создать подписанный выпуск apk, вы должны установить путь хранения ключей, пароль, псевдоним ключа и пароль ключа. Если я хочу, чтобы я, и любой член моей команды мог создать подписанный apk с той же подписью, должен ли я передать файл хранилища ключей в исходный элемент управления?
Должен ли я хранить хранилище ключей релиза для Android-приложения в коллективном репозитории?
Ответ 1
Вы не должны.
Release keystore
- наиболее чувствительные данные.
В моей команде есть только один человек, который может подписать пакет релиза. (И может быть один для резервного копирования).
Вся конфиденциальная информация MUST будет проигнорирована, и мы сделаем ссылку на эту информацию.
В моей команде мы конфигурируем так:
Вкл Android Studio
:
/local.properties
файл:
storeFile=[path/to/keystore/file]
keyAlias=[alias key]
keyPassword=[alias password]
storePassword=[key password]
/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
}
.
.
.
}
См. мою полную демо-конфигурацию:
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'
}
Ответ 2
Преуспевать:
- Это AES-шифрование
- Вы можете хранить учетные данные вне контроля источника (например, KeePass, Beyond Trust)
- Никто не может получить доступ к ключу без учетных данных
Тем не менее, есть минусы: вы представляете некоторый риск того, что он будет подвергнут грубому принуждению при регистрации. Поэтому вам следует провести анализ затрат и выгод и выяснить, стоит ли это вам.
Еще одним соображением является то, что ваша организация уже использует для управления конфигурациями. Если у вас есть такая система, как Azure DevOps (TFS/VSTS), вы должны попытаться использовать ее. Если у вас есть секретный менеджер, вы должны интегрироваться с ним.
Есть компромиссы:
+---------------------------+-------------------+------+--------+--------+------------------------+ | 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 | +---------------------------+-------------------+------+--------+--------+------------------------+
Лично, если бы я создавал это в большой организации, я бы присматривал за секретным менеджером. Для личного проекта или небольшой команды я бы просто зафиксировал хранилище ключей и сохранил учетные данные в другом месте. Это зависит от масштабов, рисков и доступной инфраструктуры.