Как стать автором
Обновить

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

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

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

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


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


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

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

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

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

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

Точно нет. Аккаунт username@companyname.com не содержит никаких данных про мою личную почту — создавал недавно, ничего такого не вносил.

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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


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

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


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


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

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

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


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

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

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


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

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

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

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


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


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

Вы уже написали фичреквест в поддержку GitHub, GitLab, Bitbucket?

Нет. Хотя согласен, что это было бы логичным продолжением статьи.

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


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

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

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

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


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

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

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


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



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

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

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

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

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


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


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


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


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

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


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

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


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


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


Сам коммит.

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


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

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

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

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

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


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


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

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

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

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


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

А я поставил правило в оболочке gmail, чтобы весь спам направляли во входящие. При этом спам все равно помечается в интерфейсе, когда письмо открываешь))
Сокрытие e-mail вам никак не поможет, так как никто не запрещает использовать users.noreply.github.com.
НЛО прилетело и опубликовало эту надпись здесь
Я правильно понимаю, что нарисовать «всякие свастики и ежиков» в статистике Торвальдсу, создавая от его имени коммиты в моём собственном форке github.com/torvalds/linux, всё равно не получится?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

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

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


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

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


git -c user.name='Bill Gates' -c user.email='bill@microsoft.com' commit -m 'Foo bar'

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


GIT_AUTHOR_NAME 
GIT_AUTHOR_EMAIL 
GIT_AUTHOR_DATE 

GIT_COMMITTER_NAME 
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE 

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


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

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

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


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


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


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

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

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

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

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

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

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

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

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

Ооо, ну это да, это да, это пожалуй имеет смысл, благодарю, стоило того чтобы ждать ответа почти месяц, без сарказма это говорю ;)

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


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

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


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

Зачем?

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

НЛО прилетело и опубликовало эту надпись здесь

Это ещё ничего, я встречал (плюсовый) код, в котором аналогичным образом был сделан условный переход через try-catch и throw. Вот тут реально думаешь «лучше бы здесь был goto».

В соседней ветке ругают, но по-мне так для шелл-скрипта нормальное решение.


Единственная проблема — неочевидное для человека, который впервые такое встречает (как пример — для меня).


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

А что мешает завернуть в функцию и использовать return?

По моему ваш репозиторий выглядит великолепно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории