Подписание кода как часть процесса сборки

Question

Я хотел бы понять некоторые из лучших практик в отношении подписывания кода. У нас есть приложение на основе Eclipse, и мы считаем целесообразным подписать наши плагины. Это вызвало много вопросов:

• Может / должен ли закрытый ключ быть в контроль источника?

• Должны ли мы подписать код как часть наш ночной процесс сборки или как часть нашего процесса выпуска?

• Если код подписан автоматически, или есть причина почему это должно быть ручным шагом?

Я склонен сказать «Да», «Ночной» и «Автоматически», но я мог видеть аргумент только для подписания продуктов выпуска. Я мог бы даже привести аргумент, что SQA должен подписать код после того, как они его проверит, хотя это действительно испортит наш процесс выпуска.

Как другие люди управляют этим?

Answer 1

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

На моей работе мы делаем следующее:

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

Еженедельно (и для внешних выпусков) мы подписываемся реальным ключом. Это делается с помощью отдельного, несколько ручного процесса. Только несколько человек имеют доступ к ключу для подписи продукта.

Answer 2

Я могу рассказать вам, как я вижу, как это делается в большой корпорации. Отдельные разработчики могли создавать код, но не могли его подписать. Это было бы частной сборкой. Машина интеграции Contiguos будет сбрасывать ночные сборки, подписанные ключом, хранящимся в хранилище ключей машины сборки, который будет тестовым ключом, подписанным корпоративным центром сертификации (т. Е. Ключом, доверенным только внутри корпорации). Официальная сборка может быть подписана только контролируемыми машинами с подписанным официальным глобальным доверенным органом, ключ подписи хранится в аппаратных модулях в комнате контролируемого доступа.

Идея состоит в том, что закрытый ключ должен иметь в мире только одну копию (не более одного дополнительного для условного депонирования). Вся ценность ключа зависит от его конфиденциальности, а не от чего-либо еще. Момент доступен для всей вашей организации, это все равно, что поместить его в пиратский залив.