Подтвердить что ты не робот

Должен ли я хранить хранилище ключей релиза для Android-приложения в коллективном репозитории?

Мы разрабатываем приложение для Android в команде. Чтобы создать подписанный выпуск apk, вы должны установить путь хранения ключей, пароль, псевдоним ключа и пароль ключа. Если я хочу, чтобы я, и любой член моей команды мог создать подписанный apk с той же подписью, должен ли я передать файл хранилища ключей в исходный элемент управления?

4b9b3361

Ответ 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                      |
+---------------------------+-------------------+------+--------+--------+------------------------+

Лично, если бы я создавал это в большой организации, я бы присматривал за секретным менеджером. Для личного проекта или небольшой команды я бы просто зафиксировал хранилище ключей и сохранил учетные данные в другом месте. Это зависит от масштабов, рисков и доступной инфраструктуры.