Эта статья написана разработчиком для разъяснения базовых принципов обеспечения аутентичности и целостности разрабатываемых информационных систем и может быть полезна как разработчикам, так и менеджерам. В статье не рассматриваются вопросы качества кода и безопасности конкретных реализаций OpenPGP.

Зачем разработчику подписывать то что он делает?

Разработка – это всегда ответственность. Информационная система должна выполнять полезную работу. Функциональное состояние системы можно изменить внеся в нее новый код. Условно разделим новый код на:

  • Внешний. Код созданный третьими лицами. Это может быть новая библиотека которую мы добавили в зависимости, или же инструмент, который мы устанавливаем в ОС в виде пакета и используем в рантайме.
  • Внутренний. Код, который, собственно, создает наша команда для решения бизнес-задач.

В обоих случая критически важно быть уверенными в источнике внесенного кода.

Внешние зависимости

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

В мире открытого ПО для решения этой проблемы используются механизмы, позволяющие подписывать файлы и коммиты. Основным инструментом является PGP.

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

На платформах с закрытым исходным кодом используются сертификаты разработчиков и источников, но базовые идеи совпадают с механизмами, используемыми в проектах с открытым исходным кодом.

Внутренний код

Право вносить изменения, порождает ответственность за работоспособность всей системы после применения правок. Следовательно, команде важно быть уверенными в происхождение кода, а разработчику – иметь возможность сказать, что это именно его работа.

Обычно проблему авторства кода рассматривают на примере открытых сообществ, где возможны различные межличностные сценарии и фейковые коммиты. Стандартные механизмы git не позволяют быть уверенным в авторстве кода. Можно указать абсолютно любые данные при настройке git:

$ git config user.name 'You Name'
$ git config user.email 'your@email.com'

и отправить правки в репозиторий в который у вас есть доступ.

Но и в распределенных командах подобное возможно. Подпись 100% решает эти вопросы.

Настройка PGP в Linux окружении

Для работы нам понадобится GnuPG версии >=2.2. Проверить версию можно с помощью команды

$ gpg --version | head -n1

Для того чтобы посмотреть список ключей на машине, используем

$ gpg --list-keys

Итак, приступим. Создадим новый ключ, не забывая указать для него пароль:

$ gpg --gen-key

Чтобы не потерять доступ к ключу, экспортируем его и отправим на хранение в надежное место:

$ gpg --export-secret-keys 64F222F157991AA2B5E21375FD02082A69A0ED61 > ~/key.gpg.asc

64F222F157991AA2B5E21375FD02082A69A0ED61 – взят просто для примера.

После этого необходимо настроить git:

  1. Указываем, что все коммиты необходимо подписывать:
    $ git config --global commit.gpgsign true
  2. Настраиваем ключ для подписи:
    $ git config --global user.signingkey 64F222F157991AA2B5E21375FD02082A69A0ED61

С настройкой машины разработчика мы закончили. Теперь необходимо настроить git-хостинг, на котором размещен репозиторий. PGP поддерживается большинством git-хостингов, например, Github добавил поддержку в апреле 2016 года. Self-hosted решения, такие как Gitlab или gitea, тоже поддерживают его.

Экспортируем публичный ключ с помощью команды:

$ gpg --armor --export 64F222F157991AA2B5E21375FD02082A69A0ED61

Копируем полностью публичный ключ и привязываем его к своему аккаунту. В Github это можно сделать на странице https://github.com/settings/keys

После включения подписей, коммиты будут выглядеть следующим образом:

Аналогично и для gitea:

Согласование и принятие административного решения об использовании OpenPGP для решения проблем целостности проекта может занять какое-то время. Настройка PGP для GIT занимает не более пары минут. Потраченное время окупится повышением надежности процесса разработки.

А вы практикуете подписывание результатов своей работы?