Перед началом чтения

SPL
Далее в статье я буду говорить о GitHub, однако изначально эту проблему я обнаружил на нашем внутреннем GitLab, а для этой статьи повторил то же самое на GitHub. Так что выводы применимы к обоим сервисам (и, возможно, не только к ним).
В чем проблема и зачем писать об этом статью?
Один из проектов в нашей компании прямо сейчас мигрирует из SVN в Git, и за последнюю неделю я несколько раз (и от разных людей) слышал один и тот же вопрос: "Зачем подписывать коммиты, если GitHub и так предоставляет контроль доступа?"
Короткий ответ: GitHub проверяет, что в репозиторий коммитят только определенные люди, но он не проверяет, что конкретно лежит в ваших коммитах.
Однако подобное доверие может сыграть с нами злую шутку. Например, репозиторий на GitHub с участием известных людей может стать еще одним звеном в цепи фишинговой кампании, толкающей жертву к потере средств.
Дополнительная проблема в том, что обезопасить себя (как жертву) от таких уловок очень сложно без вмешательства GitHub.
Механизм подставы
Многие из нас, когда впервые коммитили в Git-репозиторий, сталкивались со следующим сообщением:

Несмотря на то, что все уже поняли, в чем дело, я продолжу.
Git для коммита требует два поля: моё имя и почту. При этом, писать туда можно всё, что угодно: Git не проводит верификацию почты, это поле появилось по историческим причинам и нужно для связи с разработчиком.

GitHub, в свою очередь, во время пуша удостоверяется, что у пользователя есть право пушить в этот репозиторий и в эту ветку. Причина здесь проста: GitHub реализует свои функции поверх такого же гита, которым пользуемся и мы с тобой на своем десктопе.
В этом и заключается тонкий момент. Принимая от пользователя коммиты, GitHub читает поле email и если такой пользователь зарегистрирован на сайте, он считается контрибьютором репозитория. Для гита ведь вполне естественной является ситуация, когда я пишу код, коммичу, собираю свои коммиты в патч и посылаю другому пользователю. А он их проверит и запушит в основной репозиторий.

Так вот зачем...
… подписывать коммиты!" — воскликнет внимательный читатель.
К сожалению, нет.
Прямо сейчас я сходил в гугл и поискал статьи по теме. Вот одна из них: Spoofing Git Commits. Автор описывает тот же механизм (если я путанно объяснил, можно почитать там) и приходит к выводу, что единственный способ защиты — подписывать свои коммиты. Но это неверно.
Как GitHub реагирует на подписанные коммиты?

В общем, лучше объясню словами:

• GitHub получает коммит с email = lala@mail.com, подписанный GPG;
  
• он находит пользователя с почтой lala@mail.com;
  
• он берет из профиля пользователя публичный ключ;
  
  • если подпись коммита подходит к публичному ключу -> рисуем "Verified";
    
  • если подпись не подходит к публичному ключу -> рисуем "Не Verified";
    
  • если у пользователя нет ключа и нет подписи коммита -> ничего не рисуем;
    
  • если у пользователя есть ключ и нет подписи коммита -> НИЧЕГО НЕ РИСУЕМ;
    
  • если у пользователя нет ключа и есть подпись -> не знаю, что будет, но самое важное тут — строчка выше.

Когда обычный пользователь приходит в репозиторий и видит плашечки "Unverified", он насторожится.
Насторожится ли он, зайдя в репозиторий и не найдя там ни одной плашечки? Не думаю.
Если возникли подозрения, можно кое-что проверить
Судя по всему, активность пользователя (которая показывается на страничке его профиля) заполняется в базу во время пушей/работы с интерфейсом в браузере, а не парсится на лету из всех репозиториев на сайте.
Поэтому мои фейковые коммиты не отображаются на страничке активности.
Как пример — страничка Линуса:

оригинал
Подводя итог
Подписывая коммит, я доказываю репозиторию и окружающим, что человек, выполнивший git commit — это я, и никто другой.
Не подписывая коммит, я никому ничего не доказываю.
Когда ты видишь мой неподписанный коммит, у тебя не возникает причин думать, что этот код закоммичен не мной. Поэтому компульсивное подписывание каждого своего коммита не защищает меня от ситуации, когда кто-то другой пишет в коммитах мою почту и уверяет инвесторов, что я пишу код в его проект.
Ничто, кроме отсутствия аккаунта на GitHub. Или факта, что я — неуловимый Джо.
В любом случае, я знаю по именам шестерых людей, с которыми подобная ситуация уже произошла: их имена и почтовые адреса вписали в репозиторий на GitHub, чтобы завлечь читателей под кат.
Противоречу сам себе
Вообще-то на GitHub есть потенциальная возможность защитить себя: в настройках профиля можно включить опцию Keep my email address private. Подробности в их доках.
Скриншот оттуда:

Чтобы почувствовать относительную безопасность, нужно:

• зарегистрировать аккаунт на никому не известную почту;
  
• включить оба чекбокса на скриншоте.

Зачем первый пункт? Специально для этого в список контрибьюторов на КДПВ я включил boomburum. Как можно удостовериться на странице его профиля на GitHub, он не засветил свою почту ни в одном коммите. Я эту почту просто угадал.

Еще один итог
Ты на работе пишешь в ваш внутренний GitLab, но на сервере нет хуков, которые отвергали бы любые пуши с коммитами, которые не были бы подписаны заранее известными ключами?
Будь готов к тому, что однажды к тебе придут и спросят, зачем ты вставил в процессинг платежей бекдор, через который утекла пара миллионов.
<шутка>Если только собираешься вставить такой бекдор — ты знаешь, что делать.</шутка> Не делай так, ведь админы твоего репозитория наверняка хранят все логи и записи аудита из GitLab за последние несколько лет.
Вместо заключения
Напишу пару слов о том, как я создал этот репозиторий с прекрасным стихотворением Даниила Хармса.
Всё, что я опишу ниже лежит в репозитории на GitHub: здесь.

• Кладем стихотворение в файл ./poem.txt;
  
• Пишем скрипт
  
  #!/bin/bash
  # Скрипт прервется, если встретит непроинициализированную переменную
  # либо какая-то функция/команда вернет код ответа, отличный от нуля
  set -eu
  ########## Подготавливаем окружение ############################################
  FILE="${1:-./poem.txt}"
  OUT_DIR="${2:-./poetry}"
  OUT_FILE="${OUT_DIR}/README.md"
  export GIT_DIR="${OUT_DIR}/.git"
  export GIT_WORK_TREE="$OUT_DIR"
  if [[ -d "$OUT_DIR" ]]; then
    echo "Directory ${OUT_DIR} exists already" >&2
    exit 1
  fi
  if [[ ! -s "$FILE" ]]; then
    echo "File ${FILE} doesn't exist or empty" >&2
    exit 2
  fi
  mkdir -p "$OUT_DIR"
  touch "$OUT_FILE"
  git init
  # Убеждаемся, что гит не будет подписывать коммиты
  git config --local commit.gpgsign no
  ########## Список будущих контрибьюторов #######################################
  declare -A AUTHORS=( )
  AUTHORS["Linus Torvalds"]=torvalds@linux-foundation.org
  AUTHORS["Vitalik Buterin"]=v@buterin.com
  AUTHORS["Bjarne Stroustrup"]=bjarne@stroustrup.com
  AUTHORS["Brendan Gregg"]=brendan.d.gregg@gmail.com
  AUTHORS["Guido van Rossum"]=guido@python.org
  AUTHORS["Aleksey Boomburum"]=boomburum@gmail.com
  AUTHORS["Ivan Vasilev"]=slavniyteo@gmail.com
  # Массив имен разработчиков, чтобы идти по ним в цикле
  # В функции get-next-author-name
  declare -a AUTHOR_NAMES=( "${!AUTHORS[@]}" )
  ########## Функции #############################################################
  get-next-author-name() {
    local GLOBAL_AUTHOR_INDEX="$1"
    local AUTHOR_INDEX="$(($GLOBAL_AUTHOR_INDEX % "${#AUTHOR_NAMES[@]}"))"
    echo "${AUTHOR_NAMES["$AUTHOR_INDEX"]}"
  }
  commit-one-line() {
    local AUTHOR="$1"
    local LINE="$2"
    local AUTHOR_EMAIL="${AUTHORS["$AUTHOR"]}"
    # Вставляем строку в начало файла
    echo "$LINE" | cat - "$OUT_FILE" > temp
    mv temp "$OUT_FILE"
    git add -A
    git config --local user.name "$AUTHOR"
    git config --local user.email "$AUTHOR_EMAIL"
    # Добавляем '| ' в начало,
    # чтобы избежать проблем с пустым сообщением коммита
    git commit -m "| $LINE"
    # Избавляемся от сайд-эффектов функции
    git config --local --unset user.name
    git config --local --unset user.email
  }
  ########## Основной цикл #######################################################
  LINE_IDX=0
  while IFS= read LINE; do
    LINE_IDX="$((LINE_IDX + 1))"
    AUTHOR="$(get-next-author-name "$LINE_IDX")"
    commit-one-line "$AUTHOR" "$LINE"
  done <<<"$(tac "$FILE")" # Читаем файл от последней строки к первой
  ################################################################################
  
  
• Запускаем скрипт и грустим от того, что лог репозитория на GitHub не очень подходит для чтения стихотворений;
  
• Радуемся, как круто выглядит в tig:

оригинал
===========
Источник:
habr.com
===========
Похожие новости:

• [Информационная безопасность] ФБР предупредило об угрозе голосового фишинга — вишинга
  
• [*nix, Информационная безопасность, Облачные сервисы, Серверное администрирование, Сетевые технологии] Как мы выбирали VPN-протокол и сервер настраивали
  
• Выпуск системы совместной разработки Gogs 0.12
  
• [GitHub, LaTeX] GitHub Actions и LaTeX: поднимаем, заливаем
  
• [Информационная безопасность, История IT, Изучение языков] Аутенти(фи?)кация
  
• [Open source, Программирование, GitHub] Китай поставил задачу превратить Gitee в местный аналог GitHub
  
• [Информационная безопасность, Open source, Социальные сети и сообщества] Maltego Часть 6. «Дорогой, где ты был? Бегал!» (с)
  
• [Информационная безопасность, Реверс-инжиниринг] Уязвимость Use-After-Free (перевод)
  
• [Информационная безопасность] Новая версия ЧАВО для выбора паролей и правил создания систем аутентификации от NIST
  
• [Информационная безопасность, Исследования и прогнозы в IT] Битва за роутеры: как ботнеты делят сферы влияния

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_git, #_github, #_git, #_github, #_gitlab, #_gpg, #_social_engineering, #_phishing, #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_git, #_github