git ни разу не спросил у вас пароль — и в этом виноват скандал 2005 года

Признайтесь: вы не знаете, кто у вас сейчас просит пароль.

Вы делаете git push. Иногда выскакивает окошко. Иногда терминал молча ждёт ввода, и буквы не печатаются. Иногда всё проходит без единого вопроса, будто git вас узнал. А иногда — Support for password authentication was removed on August 13, 2021, и вы сидите и гадаете, какой из семи токенов протух на этот раз.

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

git за эти двадцать лет ни разу не спросил у вас пароль. Ни одного раза.

То, что вы принимаете за «git просит пароль», — это всегда кто-то другой, стоящий у него за спиной и машущий руками. Разберёмся, кто именно. А потом — кто всю эту конструкцию собрал.

У git нет пароля. И никогда не было

В сердце git — контентно-адресуемое хранилище: кидаешь блоб, получаешь SHA, и всё. Коммиты, деревья, теги — объекты в .git/objects. Локально git не знает слов «логин» и «пароль», потому что ему не у кого и незачем спрашивать.

Аутентификация включается ровно в одну секунду вашей жизни с git — когда данные надо протолкнуть через сеть на другую машину. И тут начинается главное: сам git этого делать не умеет. Он перекладывает работу на транспорт. Кто транспорт — тот и хозяин пароля.

Вот вся правда в одной таблице — сохраните в закладки и доставайте каждый раз, когда git «просит пароль»:

Хотите понять, кто стоит у двери, — посмотрите на схему URL ремоута. Она скажет всё сразу.

Парад тех, кто спрашивает вместо git

Те самые четыре поведения, что вас бесят:

Терминал молча ждёт, буквы не печатаются. Это SSH-клиент вызвал getpass() и выключил эхо терминала, чтобы пароль от ключа не отсвечивал в истории и в плече коллеги. git в этот момент просто ждёт, пока ssh договорится с сервером.

Выскочило графическое окошко. Сработал GIT_ASKPASS или SSH_ASKPASS — механизм, через который git говорит «мне нужен пароль, но я в графической среде, спросите вы». Диалог рисует внешняя программа. git его даже не видел — только заказал.

Не спросил вообще ничего. Сработал credential helper. Подсистема git credential сходила в хранилище секретов — macOS Keychain, Windows Credential Manager, libsecret на линуксе или (не делайте так) plaintext в ~/.git-credentials — достала токен и открыла дверь молча.

Support for password authentication was removed. А это уже не локальная история. Это GitHub на том конце: 13 августа 2021 года, в 09:00 PST, он перестал принимать пароли от аккаунта при git-операциях. О переходе на токены предупреждали ещё с 2020-го. Теперь поверх HTTPS летит не пароль, а Personal Access Token — в том же самом поле Basic Auth, где раньше летел пароль. Снаружи ничего не поменялось. Поменялось то, что сервер согласен считать валидным.

Заметили закономерность? На каждое «почему git так делает» ответ начинается со слов «вообще-то это не git, это…». Четыре разные программы, четыре философии, склеенные тем, что все умеют разговаривать с одним git.

Теперь — кто это устроил.

Апрель 2005: десять дней, которые мы расхлёбываем

До 2002 года ядро Linux жило вообще без VCS в современном смысле: разработчики слали патчи в рассылку, Линус руками вмерживал их в дерево. Когда контрибьюторов стали тысячи, это перестало масштабироваться, и ядро переехало на BitKeeper — проприетарную распределённую VCS компании Ларри Маквоя.

BitKeeper дал ядру бесплатную лицензию, но с условием в духе «пользуйся, но не ковыряй, как устроено, и не пиши конкурентов». Несколько лет держалось на тонком доверии. А потом кернел-разработчик Эндрю Тридгелл — да-да, автор Samba и соавтор rsync — написал инструмент SourcePuller, умевший разговаривать с репозиториями BitKeeper. С точки зрения Маквоя, это был реверс-инжиниринг протокола.

Реакция была максимально драматичной: в начале 2005-го Маквой отозвал у ядра бесплатную лицензию. Тысячи разработчиков в одну ночь остались без инструмента, на котором держался весь рабочий процесс.

И тут происходит то, ради чего стоит знать эту историю. В апреле 2005-го Торвальдс садится писать свою VCS. За десять дней доводит её до состояния, в котором ей уже можно вести разработку ядра. 8 апреля 2005-го делает первый коммит — сделанный, по-хорошему исторически, уже самим git. В течение нескольких дней git стал самохостящимся, в течение недель — готовым тащить ядро.

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

Решение, которое объясняет всю вашу боль

Торвальдс проектировал git под одну навязчивую идею — скорость. Его собственная формулировка тех лет: всё, что делаешь ежедневно, должно занимать меньше секунды. Отсюда в основе — быстрое контентно-адресуемое хранилище и хеши, а не сетевой клиент-сервер.

А когда у тебя десять дней и горит ядро — что ты делаешь с аутентификацией, шифрованием, управлением пользователями? Ты их не пишешь. Ты говоришь: «это проблема транспортного уровня». Шифрование? К SSH. Аутентификация? Туда же — у SSH уже есть ключи, агенты, всё отлажено годами. Своей сетевой криптографии у git нет и не будет: он просто запускает ssh подпроцессом и пихает байты в трубу.

Это, между прочим, прекрасное инженерное решение. Не переизобретать то, что уже работает, — золотое правило, но у каждого такого решения есть цена, и платите её вы, двадцать лет спустя, когда git push ведёт себя четырьмя разными способами в зависимости от выбранной трубы.

«Кто сломал это 20 лет назад» — вопрос с подвохом, потому что никто ничего не ломал. Это не баг. Это фундаментальное проектное решение: у git нет единого способа спросить пароль, ибо у git нет самой идеи «пароль». Есть делегирование. Фрагментация, которая вас раздражает, — прямое и неизбежное следствие того, что в апреле 2005-го человеку было некогда, и он мудро спихнул аутентификацию на тех, кто уже умеет.

git:// — первородный грех, который стоит знать

Раз уж про дизайн на скорость — нельзя не вспомнить родной протокол git:// на порту 9418. Написан для одной задачи: отдавать данные максимально быстро и без церемоний.

Насколько без церемоний? У него нет аутентификации вообще и нет шифрования вообще. Кто достучался до порта — тот клонирует. На запись его обычно не пускают именно поэтому. Это был чистый способ раздавать публичные репозитории в эпоху, когда HTTPS-клонирование тормозило. Сегодня git:// тихо вымер — GitHub его отключил, и почти везде он считается дурным тоном. Однако, это идеальный памятник философии 2005-го: «безопасность? на следующей неделе, сейчас надо, чтобы было быстро».

Спорный тезис: и хорошо, что так

А теперь то, с чем половина комментариев не согласится. Делегировать аутентификацию транспорту было правильным решением — и попытки засунуть auth внутрь git были бы ошибкой.

Представьте альтернативу: git со своей системой пользователей, своим протоколом аутентификации, своей криптографией. Через двадцать лет это был бы второй OpenSSL — с собственными CVE, своим зоопарком конфигов и необходимостью обновлять клиент git каждый раз, когда ломается алгоритм. Вместо этого git пережил смену целых эпох аутентификации — пароли, ключи, токены, OAuth, аппаратные ключи — не поменяв в себе вообще ничего. Когда GitHub в 2021-м убил пароли, git не выпускал экстренный патч. Ему было всё равно: пароли — не его забота.

То, что выглядит как бардак на стороне пользователя, на стороне архитектуры — редкая дисциплина: делать одну вещь и не лезть в чужую. Боль четырёх разных промптов — это цена того, что git ни разу за двадцать лет не пришлось переписывать из-за смены правил безопасности.

Очная ставка

Соберём всех виноватых. Вы делаете git push, получаете странный вопрос про пароль:

git кивает на транспорт. SSH кивает на ваш ключ и агент. HTTPS кивает на Basic Auth, тот — на credential helper, helper — на кейчейн ОС. GitHub на том конце кивает на свою политику от 13 августа 2021-го и требует токен. А вся эта схема делегирования существует потому, что в апреле 2005-го Ларри Маквой отозвал лицензию у ядра Linux, Эндрю Тридгелл написал слишком любопытный клиент, а Линус Торвальдс за десять дней сделал инструмент, в котором сознательно решил аутентификацию не писать.

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

В следующий раз, когда терминал молча ждёт пароль и не печатает звёздочки, это не git вас мучает. Это эхо одного licensing dispute двадцатилетней давности, докатившееся до вашего ноутбука. git просто стоит рядом и держит дверь.

---

А теперь вопрос к вам. За все годы с git вы хоть раз с первого взгляда понимали, кто именно у вас сейчас просит пароль — ssh, helper или сервер? И если бы Линус в 2005-м всё-таки встроил аутентификацию внутрь git — было бы сегодня лучше или мы получили бы второй OpenSSL?