Линус Торвальдс, Бьёрн Страуструп и Брендан Грегг контрибьютят в мой хобби-проект. Зачем?

    Смотрите сами: вот проект, вот история коммитов.



    Список контрибьюторов с главной страницы репозитория:



    Ссылки на аватарках ведут на странички профилей реальных людей.


    Всё на месте. Кроме плашечки "Verified" как здесь:





    Знатоки Git и GPG, не торопитесь проматывать ленту: эта статья не про необходимость подписывать свои коммиты. Она про неявные допущения, которые мы делаем, пользуясь "интуитивно-понятными" монстрами GitHub и GitLab и доверяя им контроль доступа к нашим репозиториям.


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


    Напоминаю, что если ты встретил ошибку/опечатку/неточность, которая не влияет на смысл статьи, а лишь на внешний облик:


    1. выдели текст;
    2. жми Ctrl+Enter;

    В комментариях этому не место.


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

    Отправлять сообщения могут только зарегистрированные пользователи. Выделить можно любую часть текста на странице поста, но в цитату войдут только первые 220 символов. А максимальная длина комментария — 500 знаков.
    (с) Правила

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


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




    UPD: Чтобы еще раз подчеркнуть этот момент, цитирую себя же из комментариев:


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

    Я пишу о том, как сложно защитить себя от того, что моё имя будет использовано другим человеком в неизвестном мне репозитории для обмана неизвестных мне людей.
    © https://habr.com/ru/post/515550/#comment_21990276

    Далее в статье я буду говорить о GitHub, однако изначально эту проблему я обнаружил на нашем внутреннем GitLab, а для этой статьи повторил то же самое на GitHub. Так что выводы применимы к обоим сервисам (и, возможно, не только к ним).


    В чем проблема и зачем писать об этом статью?


    Один из проектов в нашей компании прямо сейчас мигрирует из SVN в Git, и за последнюю неделю я несколько раз (и от разных людей) слышал один и тот же вопрос: "Зачем подписывать коммиты, если GitHub и так предоставляет контроль доступа?"


    Короткий ответ: GitHub проверяет, что в репозиторий коммитят только определенные люди, но он не проверяет, что конкретно лежит в ваших коммитах.


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


    Дополнительная проблема в том, что обезопасить себя (как жертву) от таких уловок очень сложно без вмешательства GitHub.


    Механизм подставы


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


    $ git commit
    
    *** Please tell me who you are.
    
    Run
    
      git config --global user.email "[email protected]"
      git config --global user.name "Your Name"
    
    to set your account's default identity.
    Omit --global to set the identity only in this repository.
    
    fatal: unable to auto-detect email address (got 'user@pc.(none)')

    Несмотря на то, что все уже поняли, в чем дело, я продолжу.




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


    $ git log --oneline
    61c133f | Несчастная кошка порезала лапу # <-- будем смотреть на этот коммит
    d825484 | Сидит, и ни шагу не может ступить.
    1d87db4 | Скорей, чтобы вылечить кошкину лапу
    e5e09ae | Воздушные шарики надо купить!
    dfa34b5 |
    db4191f | И сразу столпился народ на дороге —
    2d3468f | Шумит, и кричит, и на кошку глядит.
    5990103 | А кошка отчасти идет по дороге,
    43cc6a9 | Отчасти по воздуху плавно летит!
    
    $ git cat-file -p 61c133f
    tree 93edb4a15b5b20f6d35fee611b70d07d581fc8f4
    parent d825484462dbe091daa6108538807e37ff49a4b2
    author Bjarne Stroustrup <[email protected]> 1597692753 +0300
    committer Bjarne Stroustrup <[email protected]> 1597692753 +0300
    
    | Несчастная кошка порезала лапу —

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


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


    GitHub читает поле email и если такой пользователь зарегистрирован на сайте, он считается контрибьютором репозитория

    Так вот зачем...


    … подписывать коммиты!" — воскликнет внимательный читатель.


    К сожалению, нет.


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


    Как GitHub реагирует на подписанные коммиты?



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


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

    Когда обычный пользователь приходит в репозиторий и видит плашечки "Unverified", он насторожится.


    Насторожится ли он, зайдя в репозиторий и не найдя там ни одной плашечки? Не думаю.


    Если возникли подозрения, можно кое-что проверить


    Судя по всему, активность пользователя (которая показывается на страничке его профиля) заполняется в базу во время пушей/работы с интерфейсом в браузере, а не парсится на лету из всех репозиториев на сайте.


    Поэтому мои фейковые коммиты не отображаются на страничке активности.


    Как пример — страничка Линуса:



    Подводя итог


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


    Не подписывая коммит, я никому ничего не доказываю.


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


    Ничто, кроме отсутствия аккаунта на GitHub. Или факта, что я — неуловимый Джо.


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


    Противоречу сам себе


    Ничто не защитит меня от того, что кто-то создаст на GitHub репозиторий и положит туда код, под которым GitHub будет писать моё имя.

    Вообще-то на GitHub есть потенциальная возможность защитить себя: в настройках профиля можно включить опцию Keep my email address private. Подробности в их доках.


    Скриншот оттуда:



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


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

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



    Еще один итог


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


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


    <шутка>Если только собираешься вставить такой бекдор — ты знаешь, что делать.</шутка> Не делай так, ведь админы твоего репозитория наверняка хранят все логи и записи аудита из GitLab за последние несколько лет.




    Вместо заключения


    Напишу пару слов о том, как я создал этот репозиторий с прекрасным стихотворением Даниила Хармса.


    Всё, что я опишу ниже лежит в репозитории на GitHub: здесь.


    1. Кладем стихотворение в файл ./poem.txt;
    2. Пишем скрипт


      #!/bin/bash
      
      # Скрипт прервется, если встретит непроинициализированную переменную
      # либо какая-то функция/команда вернет код ответа, отличный от нуля
      set -eu
      
      ########## Подготавливаем окружение ############################################
      
      FILE="${1:-./poem.txt}"
      OUT_DIR="${2:-./poetry}"
      OUT_FILE_NAME="README.md"
      OUT_FILE="${OUT_DIR}/${OUT_FILE_NAME}"
      
      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"][email protected]
      AUTHORS["Vitalik Buterin"][email protected]
      AUTHORS["Bjarne Stroustrup"][email protected]
      AUTHORS["Brendan Gregg"][email protected]
      AUTHORS["Guido van Rossum"][email protected]
      AUTHORS["Aleksey Boomburum"][email protected]
      AUTHORS["Ivan Vasilev"][email protected]
      
      # Массив имен разработчиков, чтобы идти по ним в цикле
      # В функции 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 "$OUT_FILE_NAME"
      
        # Добавляем '| ' в начало, 
        # чтобы избежать проблем с пустым сообщением коммита
        git -c user.name="$AUTHOR" \
            -c user.email="$AUTHOR_EMAIL" \
            commit -m "| $LINE"
      }
      
      ########## Основной цикл #######################################################
      
      LINE_IDX=0
      while IFS= read -r LINE; do
        LINE_IDX="$((LINE_IDX + 1))"
        AUTHOR="$(get-next-author-name "$LINE_IDX")"
      
        commit-one-line "$AUTHOR" "$LINE"
      done <<<"$(tac "$FILE")" # Читаем файл от последней строки к первой
      
      ################################################################################

      UPD: Скрипт обновил после комментария capslocky (использую git -c user.name=$name вместо git config ...;
      UPD: Пофиксил read LINE, который немного ломался, когда встречал обратные слеши.


    3. Запускаем скрипт и грустим от того, что лог репозитория на GitHub не очень подходит для чтения стихотворений;
    4. Радуемся, как круто выглядит в tig:

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 58

      +2
      Кажется, что описанный механизм справедлив только для публичных репозиториев, где не используется проверка по паролю/SSH-ключу, и где email в конфиге — единственный способ определить автора?

      Прямо сейчас я коммичу в два проекта двум разным компаниям (правда, это на gitlab, не на github). В одну компанию я имею доступ на свой личный аккаунт, в другую — на фирменный [email protected]. При этом у меня в git config и там и там прописан мой личный email (не менялся с момента установки гита и работает глобально на все проекты, где я работаю). Никаких проблем с отображением себя в репозитории второй компании не наблюдаю — те коммиты, которые имеют мой личный емейл в локальной истории гита, имеют подпись с фирменным email и ссылкой на фирменный аккаунт в истории gitlab.
        0

        Изначально такое поведение обнаружил в корпоративном on-prem GitLab Community. Коммитил и пушил в приватный репозиторий. Когда в коммите прописана почта, на которую регистрировался мой коллега — поведение полностью соответствует описанному в статье.


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


        При этом у меня в git config и там и там прописан мой личный email

        Могу предположить, что эта почта добавлена в список дополнительных почт в профиле GitLab.

          0
          Изначально такое поведение обнаружил в корпоративном on-prem GitLab Community.

          Я правильно понимаю, что речь идет о репозитории, собранном на локальном корпоративном сервере? Не про gitlab.com?

          Могу предположить, что эта почта добавлена в список дополнительных почт в профиле GitLab.

          Точно нет. Аккаунт [email protected] не содержит никаких данных про мою личную почту — создавал недавно, ничего такого не вносил.

          Более того, в настройках гита на моей локальной машине нигде не указывается [email protected]. Единственный фактор, по которому меня может идентифицировать gitlab в момент пуша — это SSH-ключ (его настройки периодически слетают, и я часто теряю доступ к репозиторию из-за этого).
            0
            Я правильно понимаю, что речь идет о репозитории, собранном на локальном корпоративном сервере? Не про gitlab.com?

            Всё верно, on-prem (on-premise) значит, что сервер поднят на наших собственных серверах.


            Единственный фактор, по которому меня может идентифицировать gitlab в момент пуша — это SSH-ключ

            Все свои эксперименты я проводил через HTTPS. Можете проверить по HTTPS на своих серверах?
            Если то, о чем Вы пишете, работает только по SSH, то Вы всё еще не защищены от подлога другими людьми по HTTPS.

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

              Тем не менее, когда-то давно я на github пользовался доступом по https. И хорошо помню, что он требовал ввода пароля пользователя на каждый пуш (по крайней мере, при доступе в приватный репозиторий).
                +1
                Тем не менее, когда-то давно я на github пользовался доступом по https. И хорошо помню, что он требовал ввода пароля пользователя на каждый пуш (по крайней мере, при доступе в приватный репозиторий).

                Об этом я писал в статье:


                Короткий ответ: GitHub проверяет, что в репозиторий коммитят только определенные люди, но он не проверяет, что конкретно лежит в ваших коммитах.

                Каждый раз, когда я пушил свои коммиты, я вводил логин/пароль (или делегировал эту процедуру libsecret). Сайт проверял, что у меня есть право пуша в репозиторий, а потом показывал то, что я использовал как КДПВ.

        +7
        Сначала подумал, что это какой-то флешмоб :) С другой тороны, полезно знать, что такие флешмобы можно делать с одного компа :)
          +4

          Тоже как-то развлекался с гитом и выяснил, что в сообщениях можно подменить почти все что угодно: имя, почту, дату, сообщение (которое может быть пустым), родителей, файлы. Можно вообще делать коммиты без изменений одной командой. Написал статью о том, как строить генеалогическое дерево внутри Git. Дату можно выставить даже будущую, правда прошлая, к сожалению, ограничена 1970 годом.

            +8

            Хорошая статья, спасибо.


            Как я для себя определил, Git создавался для решения одной задачи — контроля версий исходного кода. Безопастность в git — это всегда что-то, стоящее сбоку.

              +2

              Ну так люди и рисуют всякие свастики и ежиков в contribution activity, веселая фигня

              +5

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


              И да, на GitHub можно запретить пушить в репозиторий неподписанные коммиты, если такая возможность для вас нежелательна.

                +7

                Мне кажется, Вы не уловили суть статьи.


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


                Проблема в том, что когда GitHub показывает Вам моё имя в истории репозитория, он не рисует плашку "Unverified" возле моего имени, если коммит не подписан. Такое поведение добавляет еще одну возможность для фишинга и социальной инженерии.

                  0
                  Вы пытаетесь упростить троичное состояние «подписи нет/подпись есть и она верна/подпись есть и она неверна» до бинарного. Проблема только в этом.
                    +6

                    Я хочу разобраться с двоичным состоянием "мы можем определить человека, запушившего этот код/мы не можем его найти"


                    Если подпись есть и она корректа — первый вариант, иначе — второй.

                      +1
                      Абсолютно та же самая ситуация с сайтами. http — нет подписи. https с валидным сертификатом — подпись есть и она верна. https с невалидным сертификатом — подпись есть, но она неверна. Браузеры реагируют по-разному на голый http vs https с невалидным сертификатом.
                        +5

                        Замечу, что сайтам, использующим HTTP, браузеры ставят метку "небезопастно". И движение идет именно в сторону HTTP == HTTPS_с_невалидным_сертификатом.


                        И ситуация та же самая. Когда Вы открываете сайт на HTTP, вы понятия не имеете, кто отдал этот контен: оригинальный сайт или ваш провайдер.

                          +1

                          Возможно, что http — это результат SSL Stripping и проигнорированного HSTS.
                          На отданный по http сайт, у которого есть hsts запись и на тот, у которого hsts нет, браузеры реагируют тоже по разному. Переходя от сайтов к пользователям, коммит без подписи и пользователь с публичным ключом или без.
                          В данном случае как раз это имеется в виду, SlavniyTeo ?

                            0
                            коммит без подписи и пользователь с публичным ключом или без.

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


                            Но не только. Даже если у пользователя нет публичного ключа, его коммиты должны быть помечены плашечкой "Unable to verify".


                            Аналогия с HTTP: . Страничка, открытая по HTTP небезопасна по-умолчанию. Даже если мы еще не ходили на этот сайт по HTTPS и не принимали в ответ хедер HSTS.

                              +1

                              Если у разработчика есть ключ, это ещё не означает что он обещает подписывать им все свои коммиты.


                              Подписан — значит это он сделал коммит. Не подписан — не значит что не он сделал коммит. Нет в гите аналога HSTS.

                                +2
                                Такой аналог мог бы сделать гитхаб. Добавить в профиль галочку «я всегда подписываю мои коммиты», и в алгоритм, описанный в статье, добавить ветку «если подписи нет, а в профиле стоит галочка — показывать not secure».
                                  +1

                                  Ну так об этом надо не на хабр писать, а в саппорт гитхаба.

                            +2
                            Я хочу разобраться с двоичным состоянием «мы можем определить человека, запушившего этот код/мы не можем его найти»


                            Автор коммита != запушивший человек, вне зависимости от наличия подписей. Ещё хочу заметить что в коммите указываются два человека — author и committer.

                            Кто именно из троицы автор-коммитер-пушер вас интересует?
                              +1
                              Автор коммита != запушивший человек, вне зависимости от наличия подписей. Ещё хочу заметить что в коммите указываются два человека — author и committer.

                              Я знаю это, спасибо. И это никак не противоречит фразе, которую Вы цитируете:


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



                              Кто именно из троицы автор-коммитер-пушер вас интересует?

                              Повторю еще раз. Меня интересует человек, который запушил в репозиторий код.

                                +4
                                Меня интересует человек, который запушил в репозиторий код.

                                Тогда к чему все вот эти вот ваши рассказы про плашку verified? Она про то что коммитер действительно создал коммит. Но она ничего не говорит про того кто этот код запушил.
                                  +5

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


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


                                  Я сделал именно это: написал "код", и сейчас GitHub делает вид, что его написал кто-то другой.


                                  В этом месте кто-то может обмануться.


                                  Это мне неприятно.

                          0

                          Кажется слишком масштабное изменение с учётом того, что сейчас по ощущениям не очень большой процент разработчиков свои коммиты подписывают (а ещё в GitHub при запрете неподписанных коммитов остаётся только один метод принятия PR — через merge commit). И вообще, тогда надо и в списке контрибьюторов вешать плашку "Unverified".


                          P.S. Хотя предложенный ниже вариант с настройкой в профиле звучит неплохо.

                            0

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


                            На главной репозитория автор среди контрибьюторов не отображается:


                            Но если нажать на "Contributors" происходит переход в Insights, где уже всё совсем по-другому:


                            Сам коммит.

                              0

                              Интересное наблюдение (поведение сайта выглядит непоследовательным). Хотя в истории репозитория подобные коммиты они отображают вполне неплохо:


                                0

                                Тут крестик — непрохождение CI, плашка Verified там стоит как обычно.

                                  0

                                  Да, спасибо. Я имел в виду следующее:

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

                            На гитхабе в принципе много настроек авторизации в проекте, вполне достаточно что-бы создать приемлимый уровень безопасности.
                              +5

                              Проблема возможности запушить на GitHub коммит с именем/почтой другого человека не нова: выше я приводил ссылку на medium.com, где описывается эта возможность.


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


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

                                +1
                                Я понял, в приципе ничего нового, СМТП протокол еще старше и давно под критикой именно в части регламентации. Я могу почту отпправить от вашего имени и только принимаюшая сторона на свое усмотрение пропустит или нет. Да и еще вокруг есть много архаичных протоколов. Обидно, но с такими ограничениями надо считаться.

                                Тут важно понимать что в сети мы не мы, и уловок ох как много в силу специфики сети и протоколов.
                                  0
                                  Я могу почту отпправить от вашего имени и только принимаюшая сторона на свое усмотрение пропустит или нет

                                  Согласен. Но здесь как раз и утыкаемся в ответственность сервера. Gmail старается определить подлог, и если письмо не проходит проверку, сразу отправляет его в спам. Пример: https://support.google.com/a/answer/2466580


                                  Я ожидаю того же поведения и со стороны GitLab/GitHub.

                              +3
                              Сокрытие e-mail вам никак не поможет, так как никто не запрещает использовать users.noreply.github.com.
                                +1
                                Судя по всему, активность пользователя (которая показывается на страничке его профиля) заполняется в базу во время пушей/работы с интерфейсом в браузере, а не парсится на лету из всех репозиториев на сайте.
                                Это не так. Если вы не форкнули себе репозиторий куда коммитили, то ваши коммиты в истории скорее всего не появятся.
                                Когда я коммитил в какой-то геррит, который миррорил на гитхаб, моих коммитов в моей истории не было. Только я форкнул этот миррор (бессмысленно, конечно, он все равно ридонли), так сразу мои коммиты начали появляться в истории/статистике на главной.
                                  +1
                                  Я правильно понимаю, что нарисовать «всякие свастики и ежиков» в статистике Торвальдсу, создавая от его имени коммиты в моём собственном форке github.com/torvalds/linux, всё равно не получится?
                                    0
                                    Тут скоре нужно, чтобы он форкнул ваш репозиторий. А судя по его гитхабу, он не большой любитель форкать.
                                      0
                                      Да, вряд ли.
                                      0

                                      То есть можно создать гитхаб-организацию с библиотекой репозиториев-картинок, которые импортируются себе в один клик?

                                      0

                                      Люди, вы сошли с ума?
                                      Особо одаренные уже гнобят git за "несекурность" )


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

                                        +4

                                        Кроме конфига, автора можно указать непосредственно в команде


                                        git -c user.name='Bill Gates' -c user.email='[email protected]' commit -m 'Foo bar'

                                        И еще один способ — через переменные


                                        GIT_AUTHOR_NAME 
                                        GIT_AUTHOR_EMAIL 
                                        GIT_AUTHOR_DATE 
                                        
                                        GIT_COMMITTER_NAME 
                                        GIT_COMMITTER_EMAIL
                                        GIT_COMMITTER_DATE 
                                          0

                                          Спасибо, в этом вопросе я знатно схалтурил.


                                          Сначала написал "пока так сойдёт, а перед релизом причешу", а потом этот вариант и ушел в продакшн.

                                            0

                                            Стоит добавить, что committer date можно изменить только через глобальную переменную GIT_COMMITTER_DATE, а вот GIT_AUTHOR_DATE можно и с помощью параметра командной строки: --date "01/01/1970 00:00:00". Вероятно это касается и GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL.

                                            +1

                                            Однажды, когда я экспериментировал с методами пакетирования чужого софта (deb), я решил вместо tar.gz взять и использовать гит с апстрима. Мне показалось, что это клёво — у нас debian/ изменения в одной ветке, апстрим качается с чужой ремоты.


                                            … Какое же было наше удивление, когда на следующий день в Jenkins образовалось примерно 300 пользователей всех мастей. Почему? Потому что jenkins посмотрел на git log и создал пользователеподобные сущности (без права логина) в списке пользователей по числу коммитеров.


                                            Авторы коммитов — это такая суперстранная штука. Они ничего не писали, а от их имени кто-то куда-то что-то пушит.


                                            И да, подписывать коммиты (или, хотя бы, теги) — это круто.

                                              0
                                              Что мешает взять verified коммиты из любого большого репо и на их основе сделать что-угодно?
                                                0

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

                                                  +1
                                                  Я так понимаю, для социальной инженерии в какой-то степени уже достаточно одного факта наличия коммитов от известных людей. Берем репо с такими коммитами, локально клоним, пушим в новый репо — всё — verified коммиты есть. Дальше всё (ну или не всё) стираем и пишем что надо. Как-то так: github.com/jimmytheneutrino/testverified/commits/master
                                                    0

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

                                                0
                                                Я самого главного в статье не увидел, к сожалению:

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

                                                Как коммиты известных людей могут привести к «потере средств»?
                                                  +2
                                                    0
                                                    Понятно, только конечная цель-то какая? Дальнейший шантаж? Если условному Страуступу куда-то напишут что, мол, от его имени был оставлен коммит в репозитории про кошку — любой здравомыслящий человек в этой ситуации скажет «Я… я… я… У меня работы куча, завтра дедлайн, какая кошка, мне даже некогда вчитываться в то что вы там мне написали». Про Касперского в статье читал, как кто-то вынудил его добавить его принять кого-то в друзья чтобы читать чем он делится с друзьями перед похищением. Однако Гитхаб не предполагает каких-либо инструментов коммуникации кроме issues.
                                                  +2

                                                  Кому интересно, вот тут я выложил свой хук для гитлаба https://github.com/seregaizsbera/gitlab-check-commiter


                                                  Скрипт позволяет проверить авторство коммитов через LDAP. Линус Торвальдс не пройдет.

                                                    0

                                                    sergey-b, я весь скрипт не читал, но у меня возник один вопрос по коду.


                                                    for lfwltnqh in nxacyvck; do # цикл из одной итерации
                                                        ...
                                                    done

                                                    Зачем?

                                                      +1

                                                      Чтобы выйти из него командой break

                                                        +2
                                                        Что люди не делают, лишь бы GOTO не использовать!
                                                    0
                                                    del

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

                                                    Самое читаемое