Опубликованы корректирующие выпуски распределённой системы управления исходными текстами Git 2.26.1, 2.25.3, 2.24.2, 2.23.2, 2.22.3, 2.21.2, 2.20.3, 2.19.4, 2.18.3 и 2.17.4, в которых устранена уязвимость (CVE-2020-5260) в обработчике gitcredentials (credential helper), приводящая к отправке учётных данных не на тот хост при обращении git-клиента к репозиторию по специально оформленному URL, содержащему символ новой строки. Уязвимость можно использовать для организации отправки на сервер, подконтрольный атакующему, учётных данных от другого хоста...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52734
>Для полного отключения обработчика gitcredentials, который выполняет сохранение и извлечение паролей их кэша, защищённого хранилища или файла с паролямиЭто типа хотели как лучше, а получилось как всегда?
это бонус к бесплатным репозиториям
>содержащему символ новой строкиУжасно, ужасно. Самая частая ошибка в софте. Создайте файл с таким символом и скормите его разному софту. 100% скриптов посыпется (если они конечно не написаны мной) и больше половины самого разного софта (кстати, респект gnu tar -- он не подвержен в отличие от некоторых конкурентов).
> 100% скриптов посыпется (если они конечно не написаны мной)И как сделать, чтобы не посыпались?
Использовать \0 для разделения строк. Praise GNU.
С \0 свои приколы, когда "паскалевские" строки (длина + char*, могут содержать \0) обрабатываются функциями из стандартной библиотеки C.Например, когда-то был то ли в апаче, то ли в каком еще вебсервере баг, когда URL вида image.jpg%00.php приводил к интерпретации содержимого картинки как PHP-кода (а по принципу rarjpeg-а засунуть в картинку php-код не проблема).
Не использовать Си в критически важных местах. Элементарно Ватсон.
От проблем с неспособностью программиста/протокола экранировать специальные символы это не спасёт. Со специальными символами ведь какая штука: они иногда специальные, иногда нет, это контекстно зависимо. И поэтому они имеют тенденцию выскакивать в самых неподходящих местах. Можно запретить использовать спецсимволы на дальних подходах, но в unix это не принято: если имя файла, то оно должно позволять использовать любой символ, кроме \0 и /. Зачем это нужно, непонятно, я не уверен что кто-нибудь хоть раз за всю историю unix'а пользовался бы осмысленно символами с номерами 1..31 в именах файлов. Осмысленно -- это в смысле не для эксплуатации бага, и не для того, чтобы посмотреть что получится, а реально использовал бы для какого-то технического решения, которое без этих символов было бы сложнее реализовать. Никто не использовал скорее всего, но при этом всю историю unix'а кто-нибудь наступает на грабли этих самых символов. Сложно сказать в чём смысл выбирать сложный путь, но это видимо одна из этих необъяснимых культурных штук.Вполне можно было бы запретить внутри git использовать в урлах всё кроме a-z, 0-9, и десятка символов пунктуации. 99% пользователей бы не заметили ограничения, а 99% оставшихся бы приспособились к нему. На остальных можно было бы забить. Но культурно-обусловленные bias'ы не позволили разработчикам даже рассмотреть такую возможность. Впрочем, на фоне увлечения юникодом в урлах, ситуация осложняется, но тем не менее нет никаких причин не фильтровать символы 0..31 из урлов. Они же "исправили" ситуацию отфильтровав \n. Потом, допустим, выяснится, что где-нибудь \x03 или \x04 что-нибудь там ломает в некоторых реализациях helper'ов, им это надоест они скажут notabug, чините сами. Но _зачем_ раскладывать эти грабли notabug'ов неясно.
Файл с писком. (:
> Файл с писком. (:Да, можно положить такой файл в директорию, в которую лучше не заглядывать, и каждый раз когда туда заглянешь, она тебе пикнет, предупредит о том, что ты делаешь что-то не то. Хорошая идея. В том смысле, что хотя бы похоже на практическое применение.
В именах файлов нельзя использовать \0 и / ровно по двум причинам:
1. / разделитель пути.
2. \0 конец строки.
С чего ты решил что символы 1..31 вообще имеют какой-то особый смысл в именах файлов?
> С чего ты решил что символы 1..31 вообще имеют какой-то особый смысл
> в именах файлов?Это легко можно проверить:
$ touch `echo -en '\a'`
$ ls
?
$ ls <TAB><TAB>
^G
$Чуешь? И ls, и readline (возможно по наущению bash) обрабатывают символы 1..31 как специальные, потому что если они не будут обрабатывать их как специальные, то я буду слышать бибикание, просматривая содержимое директории. При выводе этих символов они будут специальными в любом случае -- либо на уровне программ типа ls и bash, либо на уровне терминала, который будет обрабатывать эти специальные символы, либо на уровне библиотеки рендеринга текста, которая будет как-то их обрабатывать.
До тех пока мы не выводим имя файла никуда, как правило всё проходит гладко, имена файлов действительно можно рассматривать как эдакие кукисы, совершенно не парясь об их содержимом. А как только мы начинаем выводить имена файлов куда бы то ни было, нам внезапно становится очень важно, что там внутри этого имени.
Ты сначала разберись, а потом пытайся в деталях описывать то, что не понимаешь.
Видимо не видишь разницы между терминалом и файловой системой.
Еще раз по-другому объясню.
В файловой системе особый смысл имеют только символы \0 и /.
Какие символы имеют особый смысл для терминала на который идет выдача bash (ls и так далее), это уж от тебя зависит, ничего не мешает использовать такой терминал, где такие символы особого смысла не имеют.
Когда-то очень давно были разные терминалы и разумным предположением было не ограничивать используемые символы в ФС. Это потом эти вещи стали стандартизировать, да было уже поздно что-то менять (и по большому счету незачем)
> Ты сначала разберись, а потом пытайся в деталях описывать то, что не
> понимаешь.Ты сначала научись читать, о чём тебе пишут, а потом советы другим давай. Если бы файловая система рассматривала бы символы 1..31 как особые символы, то мне не было бы смысла начинать этот тред, с обвинениями файловой системы в том, что она не рассматривает их как особые символы.
> Еще раз по-другому объясню.
Выискался умник. Или мамке своей объясняй.
> Какие символы имеют особый смысл для терминала на который идет выдача bash
> (ls и так далее), это уж от тебя зависит, ничего не
> мешает использовать такой терминал, где такие символы особого смысла не имеют.Покажи мне пальцем на такой терминал. Или покажи хоть на одну систему которая рисует символы на экране, для которой символы 1..31 не имеют принципиально иного значения. Я могу вспомнить про одну такую систему -- это вывод символов через прерывания bios в DOS'е, или если непосредственно в текстовую видеопамять писать символы, там можно было получить всякие интересные символы, типа карточных мастей. Но это не ASCII, умник ты наш. И не UTF8.
> Когда-то очень давно были разные терминалыХаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 1..31 для того чтобы передавать между приложением и терминалом всякие интересности типа Ctrl-C?
> Это потом эти вещи стали стандартизировать,
О да, стандартизовывать их стали потом. Но когда Торвальдс запиливал vfs в linux, они уже были стандартизованы. Не было никаких разумных причин позволять 1..31 в именах файлов, и единственная реальная причина была в том, что Торвальдс не дал себе труда подумать об этом хотя бы пять секунд.
...Хамство твоё поскипано, отвечать на это дерьмо не буду...
По существу:
> Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 1..31 для того чтобы передавать между приложением и терминалом всякие интересности типа Ctrl-C?Вот тебе первый попавшийся терминал - в графическом режиме VT52, у которого не только ASCII и оно не одно такое, их много было в 80-ые разных, но ты же только DOS в состоянии помянуть. Всему виной зоопарк железа и *nix ОС в США, это нам в бывшем СССР малознакомо.
И да, не на всех из них есть Ctrl например. Маппинги между клавиатурой твоего терминала и всякой фигней типа SIGINT еще надо было сделать. Тот еще дурдом был.
> О да, стандартизовывать их стали потом. Но когда Торвальдс запиливал vfs в linux, они уже были стандартизованы. Не было никаких разумных причин позволять 1..31 в именах файлов, и единственная реальная причина была в том, что Торвальдс не дал себе труда подумать об этом хотя бы пять секунд.Ты прямо напрочь игнорируешь то, что тебе непонятно и. Уже был разный софт, неведомо подо что написанный и необходимость иметь совместимость с зоопарком прочих nix.
Каждая приличная софтина держала в списке поддерживаемых(обычно благодяря autotools) HPUX, AIX, Solaris, Irix, Linux, всякие BSD. Нельзя было такую несовместимость вводить как ограничение на символы 1..31.
Хер его знает, что там у юзера на его машине, может это университетская машина какая, где файлы с черти каких времен с расчетами и в именах символы математические из дапазона 15-30 от VT52? Можешь ты это понять?
> ...Хамство твоё поскипано, отвечать на это дерьмо не буду...
> По существу:
>> Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 1..31 для того чтобы передавать между приложением и терминалом всякие интересности типа Ctrl-C?
> Вот тебе первый попавшийся терминал - в графическом режиме VT52, у которого
> не только ASCIIЗаглядываем в википедию и читаем внимательно:
> The VT52 and VT55 included two characters sets, ASCII and "graphics mode" which switched out the lower case characters and some punctuation with new characters useful for the display of math.
Этот графический нестандартный режим для всякой математики.
> И да, не на всех из них есть Ctrl например. Маппинги между
> клавиатурой твоего терминала и всякой фигней типа SIGINT еще надо было
> сделать. Тот еще дурдом был.ASCII был стандартом задолго до появления *nix, и control чары в нём, в частности. Какая именно там комбинация клавиш мапится в ^C неважно, поскольку этот ^C в любом случае уже зарезервирован.
> Ты прямо напрочь игнорируешь то, что тебе непонятно и. Уже был разный
> софт, неведомо подо что написанный и необходимость иметь совместимость с зоопарком
> прочих nix.Приведи мне пример софта, который для осмысленных целей использовал в именах файлов управляющие символы. Для того чтобы их использовать в именах файлов надо было дебилом, даже если это происходило в 1970 году, даже если при этом терминал поддерживал какой-то нестандартный режим для вывода математики.
> Каждая приличная софтина держала в списке поддерживаемых(обычно благодяря autotools)
> HPUX, AIX, Solaris, Irix, Linux, всякие BSD. Нельзя было такую несовместимость
> вводить как ограничение на символы 1..31.Враньё. Ни одна приличная или неприличная софтина не использовала символы 1..31 в именах файлов.
> Хер его знает, что там у юзера на его машине, может это
> университетская машина какая, где файлы с черти каких времен с расчетами
> и в именах символы математические из дапазона 15-30 от VT52? Можешь
> ты это понять?Нет, не могу. Обратная совместимость с гипотетическими случаями -- это даже хуже той обратной совместимости, которую IBM PC тянул, до появления всяких там amd64 и UEFI. Реально хуже: когда в биосе держали недокументированные переменные в сегментах биоса, потому что кто-то там десять лет назад их использовал, то это делалось потому, что были известны факты использования именно этого адреса. Когда же мы начинаем тянуть обратную совместимость с нашей фантазией, которую мы сильно-сильно напрягаем, измышляя случаи, которые могли бы быть -- это уже не инженерное дело, это шизофрения.
Размышляя таким образом, надо было ещё все имена файлов в верхний регистр переводить, потому что у кого-нибудь обязательно был софт под DOS, который не различает регистры, и этот кто-то тоже может захотеть перелезть на linux.
> Этот графический нестандартный режим для всякой математики.И что он отображал по-твоему? В том числе консольные приложения тоже. Пойми ты, эти самые спецсимволы это исключительно свойство терминала, никак не файловой системы.
> ASCII был стандартом задолго до появления *nix, и control чары в нём, в частности. Какая именно там комбинация клавиш мапится в ^C неважно, поскольку этот ^C в любом случае уже зарезервирован.И все равно плодились терминалы с альтернативными режимами, вот подиж ты, зачем казалось бы?
> Приведи мне пример софта, который для осмысленных целей использовал в именах файлов управляющие символы. Для того чтобы их использовать в именах файлов надо было дебилом, даже если это происходило в 1970 году, даже если при этом терминал поддерживал какой-то нестандартный режим для вывода математики.Вот ты упорно не хочешь понять, что как раз таки в именах файлов и не использовали, потому что их там нет! Символы имеют смысл только для терминала, конечного устройства отображения, в именах файлов это только лишь байты с определенными численными значениями. Потому софт, работающий с файлами _ограничений_ на байты и не накладывал. Незачем.
> Для того чтобы их использовать в именах файлов надо было дебилом, даже если это происходило в 1970 году, даже если при этом терминал поддерживал какой-то нестандартный режим для вывода математики.Ты полегче людей в дебилы записывай, когда-то знаешь ли ls раскрашивать вывод не умел, а без спецсимволов в имени файла ты сам этого не сделаешь иначе как ls патчить (хрен на каком-нибудь aix ты это сделаешь).
> Враньё. Ни одна приличная или неприличная софтина не использовала символы 1..31 в именах файлов.Ты мне приписываешь то, чего я не говорил.
Речь о кросплатформенности софта того периода и только, если ты на своей ОС вводишь ограничение на байты в именах файлов, неизвестно что ты сломаешь у стороннего софта, который такого ограничения не знает.
> Нет, не могу. Обратная совместимость с гипотетическими случаями -- это даже хуже той обратной совместимости, которую IBM PC тянул, до появления всяких там amd64 и UEFI.Да в принципе и не надо, от твоего понимания суть проблемы не изменится.
Я тебе другой пример приведу опять таки про терминалы, вот был такой telnet, в нем код 255 был специальным управляющим символом, а FTP работал совместимо с telnet и если в имени файла был байт с кодом 255, он чаще всего просто выпадал.
Вот теперь ты такой как юзер попробовал сохранить файл в кодировке cp1251 на FTP сервер, было у файла имя "семья.txt", а стало "семь.txt". И всего лишь потому, что 255 код в cp1251 это буква "я".
---
Ты в текущих реалиях это все примерить пытаешься, а тогда Торвальдс писал мало кому известную хренотень и иметь совместимость с другими платформами было необходимо.
> И все равно плодились терминалы с альтернативными режимами, вот подиж ты, зачем
> казалось бы?Не для того, чтобы этот альтернативный режим использовать для файлов. Ты сам головой подумай: что ты будешь делать с файлом? Твой шелл будет отрисовывать эти имена не в графическом режиме, а в самом что ни на есть обычном.
>> Приведи мне пример софта, который для осмысленных целей использовал в именах файлов управляющие символы. Для того чтобы их использовать в именах файлов надо было дебилом, даже если это происходило в 1970 году, даже если при этом терминал поддерживал какой-то нестандартный режим для вывода математики.
> Вот ты упорно не хочешь понять, что как раз таки в именах
> файлов и не использовали, потому что их там нет!Не, это ты не въезжаешь. У тебя в голове редукционизм победил всё остальное: если символы кодируются байтами, значит символы не существуют. Но это не так. Человек использует _символы_ в именах файлов, как они потом кодируются -- это отдельный разговор, в процессе которого выясняется, что символы, которые использует человек в именах файлов, не кодируются байтами 1..31.
> Символы имеют
> смысл только для терминала, конечного устройства отображения, в именах файлов это
> только лишь байты с определенными численными значениями.Нет. Для конечного устройства отображения символы тоже не имеют никакого смысла. Смысл существует только в голове у человека, все остальные вещи во вселенной бессмысленны, в том смысле, что они не являются носителями смысла.
>> Для того чтобы их использовать в именах файлов надо было дебилом, даже если это происходило в 1970 году, даже если при этом терминал поддерживал какой-то нестандартный режим для вывода математики.
> Ты полегче людей в дебилы записывай, когда-то знаешь ли ls раскрашивать вывод
> не умел, а без спецсимволов в имени файла ты сам этого
> не сделаешь иначе как ls патчить (хрен на каком-нибудь aix ты
> это сделаешь).Эмм... Вот мы и нашли второе применение для управляющих символов в имени. Но это давным-давно не работает, потому как весь софт выводящий в терминал, давно фильтрует управляющие символы при выводе на экран. Точнее нет, не весь, некоторые продолжают выводить при помощи printf, и иногда убивают терминал так, что приходится ресетить.
>> Враньё. Ни одна приличная или неприличная софтина не использовала символы 1..31 в именах файлов.
> Речь о кросплатформенности софта того периода и только, если ты на своей
> ОС вводишь ограничение на байты в именах файлов, неизвестно что ты
> сломаешь у стороннего софта, который такого ограничения не знает.Какого софта? У гипотетического софта, который ты выдавил из своей фантазии?
> Я тебе другой пример приведу опять таки про терминалы, вот был такой
> telnet, в нем код 255 был специальным управляющим символом, а FTP
> работал совместимо с telnet и если в имени файла был байт
> с кодом 255, он чаще всего просто выпадал.
> Вот теперь ты такой как юзер попробовал сохранить файл в кодировке cp1251
> на FTP сервер, было у файла имя "семья.txt", а стало "семь.txt".
> И всего лишь потому, что 255 код в cp1251 это буква
> "я".И чё? Если ты используешь с telnet/ftp кодировку, которая была разработана без оглядки на telnet/ftp, то кто виноват в том, что не все символы тебе доступны?
> Ты в текущих реалиях это все примерить пытаешься, а тогда Торвальдс писал
> мало кому известную хренотень и иметь совместимость с другими платформами было
> необходимо.ASCII стал стандартом ещё до рождения Торвальдса. И управляющие символы стали стандартом тогда же. А про "совместимость с другими платформами" я ещё раз скажу: это не совместимость с платформами, а совместимость с твоей фантазией.
Вот, сами юникод упомянули жк. Разрабы юникса просто не стали сразу вводить ограничения, мешающие дальнейшему развитию системы.
> Вот, сами юникод упомянули жк. Разрабы юникса просто не стали сразу вводить
> ограничения, мешающие дальнейшему развитию системы.utf8 не использует байты 0x0..0x31. Точнее, эти байты, я думаю, могут встречаться в валидном utf8, но только в том смысле, в котором они появляются в ASCII. То есть в том самом смысле, в котором они не нужны совершенно в именах файлов. Однобайтовые кодопоинты -- это ASCII (то есть значения 0..127), а в многобайтовых все байты имеют старший бит 1.
Это сейчас фактически только utf-8, а раньше очень даже в ходу был utf-16. Как врочем и куча кодировок иного толка.
> Это сейчас фактически только utf-8, а раньше очень даже в ходу был
> utf-16. Как врочем и куча кодировок иного толка.utf-16, я подозреваю, не удастся использовать в именах файлов никак, даже если не запрещать символы 1..31.
>Не использовать Си в критически важных местах. Элементарно Ватсон.Каким боком тут C ? Речь шла о скриптах.
>> 100% скриптов посыпется (если они конечно не написаны мной)...а ещё я скромный очень и объективный? ;-)
> И как сделать, чтобы не посыпались?
Как-то так, например: http://altlinux.org/Secure_Packaging_Policy
Всё. Мелкомягкие пришли, теперь это место проклято.
Это место такое.
Хорошо, что Вы как и многие знаете разницу между Git и Github
А всё уже. Пошло заражение дальше.
Следи за копытами.
1) MS является платиновым этим самым в Linux Founation
2) git используется для разработки Linux ядра
Всё, попались! Следственно-причинная связь от ведущих аналитиков-комментаторов Opennet.
Всё гадят и гадят линуксоидам в штаны 👖
Да что же это творится...
— Что такое экранирование, Бэрримор?
— Это то, что умеют делать хакеры, но не умеют погромисты, сэр.
>погромисты=)
- получается тяга к свободе информации приводит к ее экранированию. Это весьма странно, Бэрримор.
- Диалектика, Сэр
А с каких пор git только для github? При обращении по такому url должны передаваться параметры авторизации к сайту evil com, а не к гитхабу.
Наверное, можно было и от gitlab попросить.
Ожидать, что разработчик доверил гиту пароль от банка несколько наивно, хотя кто их знает ... :)
git update-git-for-windows -yНе благодарите)
зачем вообще в гите нужны эти субмодули? Никогда не видел от них ничего кроме проблем. Да и не только я, никто ими не пользуется.
Тю, а дырки в заборе шоб лазить мимо проходной тогда як делать?
шикарная аналитика и статистика, OLAP запрос за 1 сек - отчет по всей планете :D
>+ if (strchr(value, '\n'))
>+ die("credential value for %s contains newline", key);А если передать "https://evil.com?%08%08%08%08%08�...