Включите Gitsign сегодня и начните подписывать свои коммиты

Я уже давно собирался написать этот пост, но дополнительная мотивация появилась после недавних новостей о фишинговых атаках на PyPI, которые скомпрометировали нескольких сопровождающих библиотек Python и их пакеты.

Проблема происхождения кода — это, в конечном счете, угроза для всей индустрии, которую необходимо решить как можно скорее. В этой статье я расскажу о довольно простой вещи, которую вы можете сделать уже сегодня, если вы являетесь сопровождающим и/или соавтором открытого кода, и которая поможет вам подтвердить, что код, размещенный в репозитории, действительно пришел оттуда, откуда должен был прийти: от вас.

Угроза

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

На следующем снимке экрана показан пример двух коммитов, отправленных в принадлежащий мне репозиторий из совершенно другого окружения, которое я создал с помощью старой пары ключей, все еще зарегистрированной в моем профиле:

Единственное различие между этими коммитами заключается в том, что в верхнем коммите я установил в конфигурации git тот же email, который я зарегистрировал на GitHub. Оба «импровизированных» коммита основаны на временной установке старой, но все еще действующей пары ключей, но даже без действующей пары ключей кто-то, заинтересованный в создании пакета для опечаток, может притвориться вами, настроить Git с вашей информацией, затем сделать коммит в поддельный репозиторий и обмануть людей, поверив, что он известный сопровождающий пакета.

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

Зачем нужна подпись коммитов

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

Если я вернусь к своей импровизированной «взломанной» среде и вместо обычной фиксации изменений добавлю -s к своему коммиту, вот что появится в интерфейсе GitHub:

Вот что я имею в виду, когда просто добавляю сообщение «signed by usernaname» к коммиту. Это никому не помогает, ничего не доказывает, так как любой может добавить «Подписано Эрикой Хайди» к своим коммитам. Вы можете попробовать это прямо сейчас с любым хранилищем, на которое у вас есть права для отправки коммитов.

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

Использование ключей GPG — один из способов сделать это, как объясняется в документации GitHub. Проблема здесь заключается в том, что мы сталкиваемся с той же проблемой, которая привела к тому, что недобросовестный агент смог сделать push в ваш репозиторий в первую очередь: мы зависим от пары ключей, которая может потеряться или попасть в руки неавторизованных пользователей.

Применение бесключевой подписи

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

Gitsign предлагает реализацию бесключевого подписания обязательств на основе OIDC, которая представляет собой уровень идентификации, построенный на базе OAuth 2.0. Gitsign поддерживает проверку вашей личности через GitHub, Microsoft или учетную запись Google.

Установка и включение Gitsign

Настройка Gitsign для начала подписания ваших коммитов состоит из двух этапов: сначала вам нужно установить Gitsign на систему, которую вы используете для фиксации кода. Затем нужно сообщить Git’у, что вы будете подписывать все свои коммиты с помощью Gitsign по умолчанию.

Установка Gitsign с помощью Homebrew

На системах macOS и Linux, поддерживающих Homebrew, вы можете установить Gitsign с помощью:

brew tap sigstore/tap
brew install gitsign
Войти в полноэкранный режим Выйти из полноэкранного режима

Установка Gitsign в Linux с помощью пакетов .deb или .rpm

Страница релизов Gitsign содержит пакеты .deb и .rpm для загрузки. Загрузите последнюю версию и установите с помощью одного из следующих способов:

#.deb (Ubuntu, Debian etc)
sudo dpkg -i gitsign_0.2.0_linux_amd64.deb
Войти в полноэкранный режим Выйти из полноэкранного режима
#.rpm (Fedora)
rpm -ivh gitsign_0.2.0_linux_amd64.rpm
Войти в полноэкранный режим Выйти из полноэкранного режима

После установки проверьте, что вы можете запустить Gitsign с помощью:

gitsign --version
Войти в полноэкранный режим Выйти из полноэкранного режима

Для получения дополнительной информации о вариантах установки, пожалуйста, ознакомьтесь с официальной документацией.

Настройка Gitsign в Git

Существует два основных способа настройки проектов Git на использование Gitsign по умолчанию: для каждого проекта и для всей системы.

Чтобы настроить Gitsign для проекта, зайдите в каталог вашего проекта и выполните команду:

git config --local commit.gpgsign true  # Sign all commits
git config --local tag.gpgsign true  # Sign all tags
git config --local gpg.x509.program gitsign  # Use Gitsign for signing
git config --local gpg.format x509  # Gitsign expects x509 args
Вход в полноэкранный режим Выход из полноэкранного режима

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

Если вы предпочитаете настроить Gitsign глобально и включить его для всех ваших проектов, выполните следующее:

git config --global commit.gpgsign true  # Sign all commits
git config --global tag.gpgsign true  # Sign all tags
git config --global gpg.x509.program gitsign  # Use Gitsign for signing
git config --global gpg.format x509  # Gitsign expects x509 args
Войти в полноэкранный режим Выйдите из полноэкранного режима

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

Если установка и настройка прошли как ожидалось, при создании коммита вы будете перенаправлены в окно браузера, где вы сможете выбрать поддерживаемого OIDC-провайдера для подтверждения вашей личности:

Как только вы подтвердите свою личность, коммит будет выполнен. После отправки в ваш удалённый репозиторий на GitHub вы увидите справа от фиксации заметку, сигнализирующую о том, что фиксация была подписана, но с пометкой «непроверенная». На данный момент это нормально, потому что GitHub все еще не подтверждает центр сертификации, используемый экосистемой Gitsign (Sigstore), хотя это, вероятно, изменится, когда больше пользователей начнут активно подписывать свои коммиты с помощью Gitsign.

Проверка подписей

Проверка подписи включает в себя два этапа: проверка соответствия указанной подписи коммиту, а также наличие коммита в журнале прозрачности Rekor. Я вижу в этом процессе очень интересную возможность для менеджеров пакетов в будущем создать некоторую автоматизацию для обеспечения встроенной проверки. Будем надеяться на это!

На странице документации Gitsign о проверке подписей приведена эта команда для проверки последнего коммита в журнале прозрачности, используя rekor-cli:

uuid=$(rekor-cli search --artifact <(git rev-parse HEAD | tr -d 'n') | tail -n 1)
rekor-cli get --uuid=$uuid --format=json | jq .
Войти в полноэкранный режим Выйти из полноэкранного режима

Если вы получите outut от этой команды, это означает, что последний коммит действительно был подписан и его подпись записана в журнале прозрачности Rekor.

Если вы хотите, вы можете проверить подпись коммита и сверить эту информацию с информацией, полученной из журнала прозрачности.

Заключение

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

Оцените статью
devanswers.ru
Добавить комментарий