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

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

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

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

  • Должен ли код подписываться автоматически, или есть причина, по которой это нужно делать вручную?

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

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


code-signing process eclipse-plugin
person Chris Arguin    schedule 25.08.2009    source источник

Ответы (2)


arrow_upward
7
arrow_downward

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

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

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

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

person Michael    schedule 25.08.2009

arrow_upward
4
arrow_downward

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

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

person Remus Rusanu    schedule 25.08.2009