Комментарии 67
Прямо сейчас я коммичу в два проекта двум разным компаниям (правда, это на 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.
Тем не менее, когда-то давно я на github пользовался доступом по https. И хорошо помню, что он требовал ввода пароля пользователя на каждый пуш (по крайней мере, при доступе в приватный репозиторий).
Тем не менее, когда-то давно я на github пользовался доступом по https. И хорошо помню, что он требовал ввода пароля пользователя на каждый пуш (по крайней мере, при доступе в приватный репозиторий).
Об этом я писал в статье:
Короткий ответ: GitHub проверяет, что в репозиторий коммитят только определенные люди, но он не проверяет, что конкретно лежит в ваших коммитах.
Каждый раз, когда я пушил свои коммиты, я вводил логин/пароль (или делегировал эту процедуру libsecret
). Сайт проверял, что у меня есть право пуша в репозиторий, а потом показывал то, что я использовал как КДПВ.
Тоже как-то развлекался с гитом и выяснил, что в сообщениях можно подменить почти все что угодно: имя, почту, дату, сообщение (которое может быть пустым), родителей, файлы. Можно вообще делать коммиты без изменений одной командой. Написал статью о том, как строить генеалогическое дерево внутри Git. Дату можно выставить даже будущую, правда прошлая, к сожалению, ограничена 1970 годом.
На мой взгляд совершенно нормальное и ожидаемое поведение. Ограничения доступа определяют, кому можно пушить, а не кому можно коммитить, и это написано вполне явно.
Вообще, пушить чужие коммиты зачастую вполне нормальная практика (например, забирая часть изменений из чужой ветки / форка).
И да, на GitHub можно запретить пушить в репозиторий неподписанные коммиты, если такая возможность для вас нежелательна.
Мне кажется, Вы не уловили суть статьи.
Я прямым текстом пишу, что пушить чужие коммиты — нормальнаая практика, а также что запрет пуша неподписанных коммитов не решает описанной мной проблемы.
Проблема в том, что когда GitHub показывает Вам моё имя в истории репозитория, он не рисует плашку "Unverified" возле моего имени, если коммит не подписан. Такое поведение добавляет еще одну возможность для фишинга и социальной инженерии.
Я хочу разобраться с двоичным состоянием "мы можем определить человека, запушившего этот код/мы не можем его найти"
Если подпись есть и она корректа — первый вариант, иначе — второй.
Замечу, что сайтам, использующим HTTP, браузеры ставят метку "небезопастно". И движение идет именно в сторону HTTP == HTTPS_с_невалидным_сертификатом.
И ситуация та же самая. Когда Вы открываете сайт на HTTP, вы понятия не имеете, кто отдал этот контен: оригинальный сайт или ваш провайдер.
Возможно, что http — это результат SSL Stripping и проигнорированного HSTS.
На отданный по http сайт, у которого есть hsts запись и на тот, у которого hsts нет, браузеры реагируют тоже по разному. Переходя от сайтов к пользователям, коммит без подписи и пользователь с публичным ключом или без.
В данном случае как раз это имеется в виду, SlavniyTeo ?
коммит без подписи и пользователь с публичным ключом или без.
Этот вариант — конечно, да. Если у пользователя есть публичный ключ в профиле, его неподписанные коммиты (по крайней мере, запушенные после добавления ключа) должны быть помечены красной плашечкой.
Но не только. Даже если у пользователя нет публичного ключа, его коммиты должны быть помечены плашечкой "Unable to verify".
Аналогия с HTTP: . Страничка, открытая по HTTP небезопасна по-умолчанию. Даже если мы еще не ходили на этот сайт по HTTPS и не принимали в ответ хедер HSTS.
Если у разработчика есть ключ, это ещё не означает что он обещает подписывать им все свои коммиты.
Подписан — значит это он сделал коммит. Не подписан — не значит что не он сделал коммит. Нет в гите аналога HSTS.
Я хочу разобраться с двоичным состоянием «мы можем определить человека, запушившего этот код/мы не можем его найти»
Автор коммита != запушивший человек, вне зависимости от наличия подписей. Ещё хочу заметить что в коммите указываются два человека — author и committer.
Кто именно из троицы автор-коммитер-пушер вас интересует?
Автор коммита != запушивший человек, вне зависимости от наличия подписей. Ещё хочу заметить что в коммите указываются два человека — author и committer.
Я знаю это, спасибо. И это никак не противоречит фразе, которую Вы цитируете:
Я хочу разобраться с двоичным состоянием «мы можем определить человека, запушившего этот код/мы не можем егонайтиопределить»
Кто именно из троицы автор-коммитер-пушер вас интересует?
Повторю еще раз. Меня интересует человек, который запушил в репозиторий код.
Меня интересует человек, который запушил в репозиторий код.
Тогда к чему все вот эти вот ваши рассказы про плашку verified? Она про то что коммитер действительно создал коммит. Но она ничего не говорит про того кто этот код запушил.
Вы меня уболтали, а я в свою очередь заговорился.
Последнее, что важно — кто ответит за написанный код. Если Вы пушите код, закоммиченный и подписанный другим разработчиком, меня это устроит. Если вы пушите код, написанный Вами, но с почтой другого разработчика в коммите — меня это не устраивает.
Я сделал именно это: написал "код", и сейчас GitHub делает вид, что его написал кто-то другой.
В этом месте кто-то может обмануться.
Это мне неприятно.
Кажется слишком масштабное изменение с учётом того, что сейчас по ощущениям не очень большой процент разработчиков свои коммиты подписывают (а ещё в GitHub при запрете неподписанных коммитов остаётся только один метод принятия PR — через merge commit). И вообще, тогда надо и в списке контрибьюторов вешать плашку "Unverified".
P.S. Хотя предложенный ниже вариант с настройкой в профиле звучит неплохо.
Кстати, проверил, как будет отображаться информация о проекте, если в качестве автора указать другого человека (напомню, что подпись проверяется для коммитера, а не автора).
На главной репозитория автор среди контрибьюторов не отображается:
Но если нажать на "Contributors" происходит переход в Insights, где уже всё совсем по-другому:
С другой стороны эта логика имплементирована на стороне гитхаба, можете им баг всунуть.
На гитхабе в принципе много настроек авторизации в проекте, вполне достаточно что-бы создать приемлимый уровень безопасности.
Проблема возможности запушить на GitHub коммит с именем/почтой другого человека не нова: выше я приводил ссылку на medium.com, где описывается эта возможность.
Моя статья не о том, как защитить свой репозиторий от чужого вмешательства.
Я пишу о том, как сложно защитить себя от того, что моё имя будет использовано другим человеком в неизвестном мне репозитории для обмана неизвестных мне людей.
Тут важно понимать что в сети мы не мы, и уловок ох как много в силу специфики сети и протоколов.
Я могу почту отпправить от вашего имени и только принимаюшая сторона на свое усмотрение пропустит или нет
Согласен. Но здесь как раз и утыкаемся в ответственность сервера. Gmail старается определить подлог, и если письмо не проходит проверку, сразу отправляет его в спам. Пример: https://support.google.com/a/answer/2466580
Я ожидаю того же поведения и со стороны GitLab/GitHub.
То есть можно создать гитхаб-организацию с библиотекой репозиториев-картинок, которые импортируются себе в один клик?
Люди, вы сошли с ума?
Особо одаренные уже гнобят 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 и создал пользователеподобные сущности (без права логина) в списке пользователей по числу коммитеров.
Авторы коммитов — это такая суперстранная штука. Они ничего не писали, а от их имени кто-то куда-то что-то пушит.
И да, подписывать коммиты (или, хотя бы, теги) — это круто.
Именно то, что и делает верифицированный коммит верифицированным: криптографически надежная подпись содержимого, включая хеш родительских коммитов и все прочие заголовки. Или как, по-вашему, работает криптографическая подпись?
Например, репозиторий на GitHub с участием известных людей может стать еще одним звеном в цепи фишинговой кампании, толкающей жертву к потере средств.
Как коммиты известных людей могут привести к «потере средств»?
Показываешь жертве свою репу, в которую якобы коммитят Страуструп и Торвальдс, чтобы незаслуженно увеличить доверие к ней. Области применения: от устройства на работу до вредоносного софта.
Кому интересно, вот тут я выложил свой хук для гитлаба https://github.com/seregaizsbera/gitlab-check-commiter
Скрипт позволяет проверить авторство коммитов через LDAP. Линус Торвальдс не пройдет.
sergey-b, я весь скрипт не читал, но у меня возник один вопрос по коду.
for lfwltnqh in nxacyvck; do # цикл из одной итерации
...
done
Зачем?
Чтобы выйти из него командой break
В соседней ветке ругают, но по-мне так для шелл-скрипта нормальное решение.
Единственная проблема — неочевидное для человека, который впервые такое встречает (как пример — для меня).
Тем более, остальные части скрипта выглядят понятными (множество сообщений об ошибках добавляют ясности).
А что мешает завернуть в функцию и использовать return
?
Линус Торвальдс, Бьёрн Страуструп и Брендан Грегг контрибьютят в мой хобби-проект. Зачем?