forum.opennet.ru - "Уязвимость в Git, приводящая к утечке учётных данных" (40)

"Уязвимость в Git, приводящая к утечке учётных данных"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в Git, приводящая к утечке учётных данных"	+/–
Сообщение от opennews (??), 14-Апр-20, 23:22
Опубликованы корректирующие выпуски распределённой системы управления исходными текстами 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.ru/opennews/art.shtml?num=52734
Ответить \| Правка \| Cообщить модератору

Оглавление

Это типа хотели как лучше, а получилось как всегда , Аноним (1), 23:22 , 14-Апр-20, (1)
это бонус к бесплатным репозиториям, Аноним (2), 23:31 , 14-Апр-20, (2) +2
Ужасно, ужасно Самая частая ошибка в софте Создайте файл с таким символом и ск, Аноним (3), 23:50 , 14-Апр-20, (3)

И как сделать, чтобы не посыпались , Аноним (4), 00:02 , 15-Апр-20, (4)

Использовать 0 для разделения строк Praise GNU , Аноним (3), 00:04 , 15-Апр-20, (5) +2

С 0 свои приколы, когда паскалевские строки длина char , могут содержать , Аноним (8), 00:36 , 15-Апр-20, (8) –2

Не использовать Си в критически важных местах Элементарно Ватсон , Онаним (?), 03:24 , 15-Апр-20, (14) –7

От проблем с неспособностью программиста протокола экранировать специальные симв, Ordu (ok), 08:03 , 15-Апр-20, (21) +6

Файл с писком , Аноним (3), 09:58 , 15-Апр-20, (23) +3

Да, можно положить такой файл в директорию, в которую лучше не заглядывать, и ка, Ordu (ok), 11:36 , 15-Апр-20, (27) +3

В именах файлов нельзя использовать 0 и ровно по двум причинам 1 разделит, Forth (ok), 21:25 , 15-Апр-20, (35) +1

Это легко можно проверить touch echo -en a ls ls TAB TAB G Чуешь И, Ordu (ok), 16:08 , 19-Апр-20, (39)

Ты сначала разберись, а потом пытайся в деталях описывать то, что не понимаешь В, Forth (ok), 09:48 , 20-Апр-20, (40)

Ты сначала научись читать, о чём тебе пишут, а потом советы другим давай Если б, Ordu (ok), 10:33 , 20-Апр-20, (41)

Хамство твоё поскипано, отвечать на это дерьмо не буду По существу Вот тебе, Forth (ok), 11:06 , 20-Апр-20, (42)

Заглядываем в википедию и читаем внимательно Этот графический нестандартный режи, Ordu (ok), 13:07 , 20-Апр-20, (43)
И что он отображал по-твоему В том числе консольные приложения тоже Пойми ты, , Forth (ok), 14:32 , 20-Апр-20, (44)
Не для того, чтобы этот альтернативный режим использовать для файлов Ты сам гол, Ordu (ok), 16:12 , 20-Апр-20, (46)

Вот, сами юникод упомянули жк Разрабы юникса просто не стали сразу вводить огра, Аноним (37), 15:01 , 19-Апр-20, (37)

utf8 не использует байты 0x0 0x31 Точнее, эти байты, я думаю, могут встречатьс, Ordu (ok), 15:52 , 19-Апр-20, (38)

Это сейчас фактически только utf-8, а раньше очень даже в ходу был utf-16 Как в, Forth (ok), 14:35 , 20-Апр-20, (45)

utf-16, я подозреваю, не удастся использовать в именах файлов никак, даже если н, Ordu (ok), 16:13 , 20-Апр-20, (47)

Каким боком тут C Речь шла о скриптах , Аноним (31), 17:11 , 15-Апр-20, (31)

а ещё я скромный очень и объективный - Как-то так, например http altlinu, Michael Shigorin (ok), 10:17 , 15-Апр-20, (24) –1

Скрыто модератором, th3m3 (ok), 00:34 , 15-Апр-20, (6) –7

Скрыто модератором, Аноним (9), 00:36 , 15-Апр-20, (9)
Скрыто модератором, Punk_Joker (ok), 01:41 , 15-Апр-20, (11) +5

Скрыто модератором, th3m3 (ok), 02:22 , 15-Апр-20, (12)
Скрыто модератором, iPony129412 (?), 07:07 , 15-Апр-20, (18) +1

Скрыто модератором, iPony129412 (?), 03:50 , 15-Апр-20, (15) –1

8212 Что такое экранирование, Бэрримор 8212 Это то, что умеют делать хакер, Сэр Аноним (?), 07:30 , 15-Апр-20, (19) +6

, Бум (?), 14:33 , 15-Апр-20, (29)
- получается тяга к свободе информации приводит к ее экранированию Это весьма с, Аноним (36), 02:07 , 16-Апр-20, (36)

А с каких пор git только для github При обращении по такому url должны передава, Аноним (22), 09:02 , 15-Апр-20, (22)

Наверное, можно было и от gitlab попросить Ожидать, что разработчик доверил гиту, КО (?), 17:52 , 15-Апр-20, (33)

git update-git-for-windows -yНе благодарите , Нонон (?), 11:17 , 15-Апр-20, (25)
зачем вообще в гите нужны эти субмодули Никогда не видел от них ничего кроме пр, Аноним (26), 11:31 , 15-Апр-20, (26) –5

Тю, а дырки в заборе шоб лазить мимо проходной тогда як делать , Ag (ok), 12:17 , 15-Апр-20, (28)
шикарная аналитика и статистика, OLAP запрос за 1 сек - отчет по всей планете D, нитрол (?), 17:37 , 15-Апр-20, (32)

А если передать https evil com 08 08 08 08 08 08 08 08 08host github com , КО (?), 17:57 , 15-Апр-20, (34)

Сообщения [Сортировка по времени | RSS]

1. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Аноним (1), 14-Апр-20, 23:22

>Для полного отключения обработчика gitcredentials, который выполняет сохранение и извлечение паролей их кэша, защищённого хранилища или файла с паролями
Это типа хотели как лучше, а получилось как всегда?

Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимость в Git, приводящая к утечке учётных данных" +2 +/–

Сообщение от Аноним (2), 14-Апр-20, 23:31

это бонус к бесплатным репозиториям

Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Аноним (3), 14-Апр-20, 23:50

>содержащему символ новой строки
Ужасно, ужасно. Самая частая ошибка в софте. Создайте файл с таким символом и скормите его разному софту. 100% скриптов посыпется (если они конечно не написаны мной) и больше половины самого разного софта (кстати, респект gnu tar -- он не подвержен в отличие от некоторых конкурентов).

Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Аноним (4), 15-Апр-20, 00:02

> 100% скриптов посыпется (если они конечно не написаны мной)
И как сделать, чтобы не посыпались?

Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в Git, приводящая к утечке учётных данных" +2 +/–

Сообщение от Аноним (3), 15-Апр-20, 00:04

Использовать \0 для разделения строк. Praise GNU.

Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в Git, приводящая к утечке учётных данных" –2 +/–

Сообщение от Аноним (8), 15-Апр-20, 00:36

С \0 свои приколы, когда "паскалевские" строки (длина + char*, могут содержать \0) обрабатываются функциями из стандартной библиотеки C.
Например, когда-то был то ли в апаче, то ли в каком еще вебсервере баг, когда URL вида image.jpg%00.php приводил к интерпретации содержимого картинки как PHP-кода (а по принципу rarjpeg-а засунуть в картинку php-код не проблема).

Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в Git, приводящая к утечке учётных данных" –7 +/–

Сообщение от Онаним (?), 15-Апр-20, 03:24

Не использовать Си в критически важных местах. Элементарно Ватсон.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. "Уязвимость в Git, приводящая к утечке учётных данных" +6 +/–

Сообщение от Ordu (ok), 15-Апр-20, 08:03

От проблем с неспособностью программиста/протокола экранировать специальные символы это не спасёт. Со специальными символами ведь какая штука: они иногда специальные, иногда нет, это контекстно зависимо. И поэтому они имеют тенденцию выскакивать в самых неподходящих местах. Можно запретить использовать спецсимволы на дальних подходах, но в unix это не принято: если имя файла, то оно должно позволять использовать любой символ, кроме \0 и /. Зачем это нужно, непонятно, я не уверен что кто-нибудь хоть раз за всю историю unix'а пользовался бы осмысленно символами с номерами 1..31 в именах файлов. Осмысленно -- это в смысле не для эксплуатации бага, и не для того, чтобы посмотреть что получится, а реально использовал бы для какого-то технического решения, которое без этих символов было бы сложнее реализовать. Никто не использовал скорее всего, но при этом всю историю unix'а кто-нибудь наступает на грабли этих самых символов. Сложно сказать в чём смысл выбирать сложный путь, но это видимо одна из этих необъяснимых культурных штук.
Вполне можно было бы запретить внутри git использовать в урлах всё кроме a-z, 0-9, и десятка символов пунктуации. 99% пользователей бы не заметили ограничения, а 99% оставшихся бы приспособились к нему. На остальных можно было бы забить. Но культурно-обусловленные bias'ы не позволили разработчикам даже рассмотреть такую возможность. Впрочем, на фоне увлечения юникодом в урлах, ситуация осложняется, но тем не менее нет никаких причин не фильтровать символы 0..31 из урлов. Они же "исправили" ситуацию отфильтровав \n. Потом, допустим, выяснится, что где-нибудь \x03 или \x04 что-нибудь там ломает в некоторых реализациях helper'ов, им это надоест они скажут notabug, чините сами. Но _зачем_ раскладывать эти грабли notabug'ов неясно.

Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в Git, приводящая к утечке учётных данных" +3 +/–

Сообщение от Аноним (3), 15-Апр-20, 09:58

Файл с писком. (:

Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в Git, приводящая к утечке учётных данных" +3 +/–

Сообщение от Ordu (ok), 15-Апр-20, 11:36

> Файл с писком. (:
Да, можно положить такой файл в директорию, в которую лучше не заглядывать, и каждый раз когда туда заглянешь, она тебе пикнет, предупредит о том, что ты делаешь что-то не то. Хорошая идея. В том смысле, что хотя бы похоже на практическое применение.

Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в Git, приводящая к утечке учётных данных" +1 +/–

Сообщение от Forth (ok), 15-Апр-20, 21:25

В именах файлов нельзя использовать  \0 и / ровно по двум причинам:
1. / разделитель пути.
2. \0 конец строки.
С чего ты решил что символы 1..31 вообще имеют какой-то особый смысл в именах файлов?

Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Ordu (ok), 19-Апр-20, 16:08

> С чего ты решил что символы 1..31 вообще имеют какой-то особый смысл
> в именах файлов?
Это легко можно проверить:
$ touch `echo -en '\a'`
$ ls
?
$ ls <TAB><TAB>
^G
$
Чуешь? И ls, и readline (возможно по наущению bash) обрабатывают символы 1..31 как специальные, потому что если они не будут обрабатывать их как специальные, то я буду слышать бибикание, просматривая содержимое директории. При выводе этих символов они будут специальными в любом случае -- либо на уровне программ типа ls и bash, либо на уровне терминала, который будет обрабатывать эти специальные символы, либо на уровне библиотеки рендеринга текста, которая будет как-то их обрабатывать.
До тех пока мы не выводим имя файла никуда, как правило всё проходит гладко, имена файлов действительно можно рассматривать как эдакие кукисы, совершенно не парясь об их содержимом. А как только мы начинаем выводить имена файлов куда бы то ни было, нам внезапно становится очень важно, что там внутри этого имени.

Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Forth (ok), 20-Апр-20, 09:48

Ты сначала разберись, а потом пытайся в деталях описывать то, что не понимаешь.
Видимо не видишь разницы между терминалом и файловой системой.
Еще раз по-другому объясню.
В файловой системе особый смысл имеют только символы \0 и /.
Какие символы имеют особый смысл для терминала на который идет выдача bash (ls и так далее), это уж от тебя зависит, ничего не мешает использовать такой терминал, где такие символы особого смысла не имеют.
Когда-то очень давно были разные терминалы и разумным предположением было не ограничивать используемые символы в ФС. Это потом эти вещи стали стандартизировать, да было уже поздно что-то менять (и по большому счету незачем)

Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Ordu (ok), 20-Апр-20, 10:33

> Ты сначала разберись, а потом пытайся в деталях описывать то, что не
> понимаешь.
Ты сначала научись читать, о чём тебе пишут, а потом советы другим давай. Если бы файловая система рассматривала бы символы 1..31 как особые символы, то мне не было бы смысла начинать этот тред, с обвинениями файловой системы в том, что она не рассматривает их как особые символы.
> Еще раз по-другому объясню.
Выискался умник. Или мамке своей объясняй.
> Какие символы имеют особый смысл для терминала на который идет выдача bash
> (ls и так далее), это уж от тебя зависит, ничего не
> мешает использовать такой терминал, где такие символы особого смысла не имеют.
Покажи мне пальцем на такой терминал. Или покажи хоть на одну систему которая рисует символы на экране, для которой символы 1..31 не имеют принципиально иного значения. Я могу вспомнить про одну такую систему -- это вывод символов через прерывания bios в DOS'е, или если непосредственно в текстовую видеопамять писать символы, там можно было получить всякие интересные символы, типа карточных мастей. Но это не ASCII, умник ты наш. И не UTF8.

> Когда-то очень давно были разные терминалы
Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 1..31 для того чтобы передавать между приложением и терминалом всякие интересности типа Ctrl-C?
> Это потом эти вещи стали стандартизировать,
О да, стандартизовывать их стали потом. Но когда Торвальдс запиливал vfs в linux, они уже были стандартизованы. Не было никаких разумных причин позволять 1..31 в именах файлов, и единственная реальная причина была в том, что Торвальдс не дал себе труда подумать об этом хотя бы пять секунд.

Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Forth (ok), 20-Апр-20, 11:06

...Хамство твоё поскипано, отвечать на это дерьмо не буду...
По существу:
> Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 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? Можешь ты это понять?

Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Ordu (ok), 20-Апр-20, 13:07

> ...Хамство твоё поскипано, отвечать на это дерьмо не буду...
> По существу:
>> Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 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.

Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Forth (ok), 20-Апр-20, 14:32

> Этот графический нестандартный режим для всякой математики.
И что он отображал по-твоему? В том числе консольные приложения тоже. Пойми ты, эти самые спецсимволы это исключительно свойство терминала, никак не файловой системы.
> 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 это буква "я".
---
Ты в текущих реалиях это все примерить пытаешься, а тогда Торвальдс писал мало кому известную хренотень и иметь совместимость с другими платформами было необходимо.

Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Ordu (ok), 20-Апр-20, 16:12

> И все равно плодились терминалы с альтернативными режимами, вот подиж ты, зачем
> казалось бы?
Не для того, чтобы этот альтернативный режим использовать для файлов. Ты сам головой подумай: что ты будешь делать с файлом? Твой шелл будет отрисовывать эти имена не в графическом режиме, а в самом что ни на есть обычном.
>> Приведи мне пример софта, который для осмысленных целей использовал в именах файлов управляющие символы. Для того чтобы их использовать в именах файлов надо было дебилом, даже если это происходило в 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 стал стандартом ещё до рождения Торвальдса. И управляющие символы стали стандартом тогда же. А про "совместимость с другими платформами" я ещё раз скажу: это не совместимость с платформами, а совместимость с твоей фантазией.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

37. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Аноним (37), 19-Апр-20, 15:01

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

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

38. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Ordu (ok), 19-Апр-20, 15:52

> Вот, сами юникод упомянули жк. Разрабы юникса просто не стали сразу вводить
> ограничения, мешающие дальнейшему развитию системы.
utf8 не использует байты 0x0..0x31. Точнее, эти байты, я думаю, могут встречаться в валидном utf8, но только в том смысле, в котором они появляются в ASCII. То есть в том самом смысле, в котором они не нужны совершенно в именах файлов. Однобайтовые кодопоинты -- это ASCII (то есть значения 0..127), а в многобайтовых все байты имеют старший бит 1.

Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Forth (ok), 20-Апр-20, 14:35

Это сейчас фактически только utf-8, а раньше очень даже в ходу был utf-16. Как врочем и куча кодировок иного толка.

Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Ordu (ok), 20-Апр-20, 16:13

> Это сейчас фактически только utf-8, а раньше очень даже в ходу был
> utf-16. Как врочем и куча кодировок иного толка.
utf-16, я подозреваю, не удастся использовать в именах файлов никак, даже если не запрещать символы 1..31.

Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Аноним (31), 15-Апр-20, 17:11

>Не использовать Си в критически важных местах. Элементарно Ватсон.
Каким боком тут C ? Речь шла о скриптах.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

24. "Уязвимость в Git, приводящая к утечке учётных данных" –1 +/–

Сообщение от Michael Shigorin (ok), 15-Апр-20, 10:17

>> 100% скриптов посыпется (если они конечно не написаны мной)
...а ещё я скромный очень и объективный? ;-)
> И как сделать, чтобы не посыпались?
Как-то так, например: http://altlinux.org/Secure_Packaging_Policy

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. Скрыто модератором –7 +/–

Сообщение от th3m3 (ok), 15-Апр-20, 00:34

Всё. Мелкомягкие пришли, теперь это место проклято.

Ответить | Правка | Наверх | Cообщить модератору

9. Скрыто модератором +/–

Сообщение от Аноним (9), 15-Апр-20, 00:36

Это место такое.

Ответить | Правка | Наверх | Cообщить модератору

11. Скрыто модератором +5 +/–

Сообщение от Punk_Joker (ok), 15-Апр-20, 01:41

Хорошо, что Вы как и многие знаете разницу между Git и Github

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

12. Скрыто модератором +/–

Сообщение от th3m3 (ok), 15-Апр-20, 02:22

А всё уже. Пошло заражение дальше.

Ответить | Правка | Наверх | Cообщить модератору

18. Скрыто модератором +1 +/–

Сообщение от iPony129412 (?), 15-Апр-20, 07:07

Следи за копытами.
1) MS является платиновым этим самым в Linux Founation
2) git используется для разработки Linux ядра
Всё, попались! Следственно-причинная связь от ведущих аналитиков-комментаторов Opennet.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

15. Скрыто модератором –1 +/–

Сообщение от iPony129412 (?), 15-Апр-20, 03:50

Всё гадят и гадят линуксоидам в штаны 👖
Да что же это творится...

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

19. "Уязвимость в Git, приводящая к утечке учётных данных" +6 +/–

Сообщение от Сэр Аноним (?), 15-Апр-20, 07:30

— Что такое экранирование, Бэрримор?
— Это то, что умеют делать хакеры, но не умеют погромисты, сэр.

Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Бум (?), 15-Апр-20, 14:33

>погромисты
=)

Ответить | Правка | Наверх | Cообщить модератору

36. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Аноним (36), 16-Апр-20, 02:07

- получается тяга к свободе информации приводит к ее экранированию. Это весьма странно, Бэрримор.
- Диалектика, Сэр

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

22. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Аноним (22), 15-Апр-20, 09:02

А с каких пор git только для github? При обращении по такому url должны передаваться параметры авторизации к сайту evil com, а не к гитхабу.

Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от КО (?), 15-Апр-20, 17:52

Наверное, можно было и от gitlab попросить.
Ожидать, что разработчик доверил гиту пароль от банка несколько наивно, хотя кто их знает ... :)

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Нонон (?), 15-Апр-20, 11:17

git update-git-for-windows -y
Не благодарите)

Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимость в Git, приводящая к утечке учётных данных" –5 +/–

Сообщение от Аноним (26), 15-Апр-20, 11:31

зачем вообще в гите нужны эти субмодули? Никогда не видел от них ничего кроме проблем. Да и не только я, никто ими не пользуется.

Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от Ag (ok), 15-Апр-20, 12:17

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

Ответить | Правка | Наверх | Cообщить модератору

32. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от нитрол (?), 15-Апр-20, 17:37

шикарная аналитика и статистика, OLAP запрос за 1 сек - отчет по всей планете :D

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

34. "Уязвимость в Git, приводящая к утечке учётных данных" +/–

Сообщение от КО (?), 15-Апр-20, 17:57

>+    if (strchr(value, '\n'))
>+        die("credential value for %s contains newline", key);
А если передать "https://evil.com?%08%08%08%08%08�...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
Сообщение от Аноним (1), 14-Апр-20, 23:22
>Для полного отключения обработчика gitcredentials, который выполняет сохранение и извлечение паролей их кэша, защищённого хранилища или файла с паролями Это типа хотели как лучше, а получилось как всегда?
Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Уязвимость в Git, приводящая к утечке учётных данных"	+2 +/–
Сообщение от Аноним (2), 14-Апр-20, 23:31
это бонус к бесплатным репозиториям
Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
Сообщение от Аноним (3), 14-Апр-20, 23:50
>содержащему символ новой строки Ужасно, ужасно. Самая частая ошибка в софте. Создайте файл с таким символом и скормите его разному софту. 100% скриптов посыпется (если они конечно не написаны мной) и больше половины самого разного софта (кстати, респект gnu tar -- он не подвержен в отличие от некоторых конкурентов).
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Аноним (4), 15-Апр-20, 00:02
	> 100% скриптов посыпется (если они конечно не написаны мной) И как сделать, чтобы не посыпались?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Уязвимость в Git, приводящая к утечке учётных данных"	+2 +/–
	Сообщение от Аноним (3), 15-Апр-20, 00:04
	Использовать \0 для разделения строк. Praise GNU.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Уязвимость в Git, приводящая к утечке учётных данных"	–2 +/–
	Сообщение от Аноним (8), 15-Апр-20, 00:36
	С \0 свои приколы, когда "паскалевские" строки (длина + char*, могут содержать \0) обрабатываются функциями из стандартной библиотеки C. Например, когда-то был то ли в апаче, то ли в каком еще вебсервере баг, когда URL вида image.jpg%00.php приводил к интерпретации содержимого картинки как PHP-кода (а по принципу rarjpeg-а засунуть в картинку php-код не проблема).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Уязвимость в Git, приводящая к утечке учётных данных"	–7 +/–
	Сообщение от Онаним (?), 15-Апр-20, 03:24
	Не использовать Си в критически важных местах. Элементарно Ватсон.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	21. "Уязвимость в Git, приводящая к утечке учётных данных"	+6 +/–
	Сообщение от Ordu (ok), 15-Апр-20, 08:03
	От проблем с неспособностью программиста/протокола экранировать специальные символы это не спасёт. Со специальными символами ведь какая штука: они иногда специальные, иногда нет, это контекстно зависимо. И поэтому они имеют тенденцию выскакивать в самых неподходящих местах. Можно запретить использовать спецсимволы на дальних подходах, но в unix это не принято: если имя файла, то оно должно позволять использовать любой символ, кроме \0 и /. Зачем это нужно, непонятно, я не уверен что кто-нибудь хоть раз за всю историю unix'а пользовался бы осмысленно символами с номерами 1..31 в именах файлов. Осмысленно -- это в смысле не для эксплуатации бага, и не для того, чтобы посмотреть что получится, а реально использовал бы для какого-то технического решения, которое без этих символов было бы сложнее реализовать. Никто не использовал скорее всего, но при этом всю историю unix'а кто-нибудь наступает на грабли этих самых символов. Сложно сказать в чём смысл выбирать сложный путь, но это видимо одна из этих необъяснимых культурных штук. Вполне можно было бы запретить внутри git использовать в урлах всё кроме a-z, 0-9, и десятка символов пунктуации. 99% пользователей бы не заметили ограничения, а 99% оставшихся бы приспособились к нему. На остальных можно было бы забить. Но культурно-обусловленные bias'ы не позволили разработчикам даже рассмотреть такую возможность. Впрочем, на фоне увлечения юникодом в урлах, ситуация осложняется, но тем не менее нет никаких причин не фильтровать символы 0..31 из урлов. Они же "исправили" ситуацию отфильтровав \n. Потом, допустим, выяснится, что где-нибудь \x03 или \x04 что-нибудь там ломает в некоторых реализациях helper'ов, им это надоест они скажут notabug, чините сами. Но _зачем_ раскладывать эти грабли notabug'ов неясно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Уязвимость в Git, приводящая к утечке учётных данных"	+3 +/–
	Сообщение от Аноним (3), 15-Апр-20, 09:58
	Файл с писком. (:
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Уязвимость в Git, приводящая к утечке учётных данных"	+3 +/–
	Сообщение от Ordu (ok), 15-Апр-20, 11:36
	> Файл с писком. (: Да, можно положить такой файл в директорию, в которую лучше не заглядывать, и каждый раз когда туда заглянешь, она тебе пикнет, предупредит о том, что ты делаешь что-то не то. Хорошая идея. В том смысле, что хотя бы похоже на практическое применение.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Уязвимость в Git, приводящая к утечке учётных данных"	+1 +/–
	Сообщение от Forth (ok), 15-Апр-20, 21:25
	В именах файлов нельзя использовать \0 и / ровно по двум причинам: 1. / разделитель пути. 2. \0 конец строки. С чего ты решил что символы 1..31 вообще имеют какой-то особый смысл в именах файлов?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Ordu (ok), 19-Апр-20, 16:08
	> С чего ты решил что символы 1..31 вообще имеют какой-то особый смысл > в именах файлов? Это легко можно проверить: $ touch `echo -en '\a'` $ ls ? $ ls <TAB><TAB> ^G $ Чуешь? И ls, и readline (возможно по наущению bash) обрабатывают символы 1..31 как специальные, потому что если они не будут обрабатывать их как специальные, то я буду слышать бибикание, просматривая содержимое директории. При выводе этих символов они будут специальными в любом случае -- либо на уровне программ типа ls и bash, либо на уровне терминала, который будет обрабатывать эти специальные символы, либо на уровне библиотеки рендеринга текста, которая будет как-то их обрабатывать. До тех пока мы не выводим имя файла никуда, как правило всё проходит гладко, имена файлов действительно можно рассматривать как эдакие кукисы, совершенно не парясь об их содержимом. А как только мы начинаем выводить имена файлов куда бы то ни было, нам внезапно становится очень важно, что там внутри этого имени.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Forth (ok), 20-Апр-20, 09:48
	Ты сначала разберись, а потом пытайся в деталях описывать то, что не понимаешь. Видимо не видишь разницы между терминалом и файловой системой. Еще раз по-другому объясню. В файловой системе особый смысл имеют только символы \0 и /. Какие символы имеют особый смысл для терминала на который идет выдача bash (ls и так далее), это уж от тебя зависит, ничего не мешает использовать такой терминал, где такие символы особого смысла не имеют. Когда-то очень давно были разные терминалы и разумным предположением было не ограничивать используемые символы в ФС. Это потом эти вещи стали стандартизировать, да было уже поздно что-то менять (и по большому счету незачем)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Ordu (ok), 20-Апр-20, 10:33
	> Ты сначала разберись, а потом пытайся в деталях описывать то, что не > понимаешь. Ты сначала научись читать, о чём тебе пишут, а потом советы другим давай. Если бы файловая система рассматривала бы символы 1..31 как особые символы, то мне не было бы смысла начинать этот тред, с обвинениями файловой системы в том, что она не рассматривает их как особые символы. > Еще раз по-другому объясню. Выискался умник. Или мамке своей объясняй. > Какие символы имеют особый смысл для терминала на который идет выдача bash > (ls и так далее), это уж от тебя зависит, ничего не > мешает использовать такой терминал, где такие символы особого смысла не имеют. Покажи мне пальцем на такой терминал. Или покажи хоть на одну систему которая рисует символы на экране, для которой символы 1..31 не имеют принципиально иного значения. Я могу вспомнить про одну такую систему -- это вывод символов через прерывания bios в DOS'е, или если непосредственно в текстовую видеопамять писать символы, там можно было получить всякие интересные символы, типа карточных мастей. Но это не ASCII, умник ты наш. И не UTF8. > Когда-то очень давно были разные терминалы Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 1..31 для того чтобы передавать между приложением и терминалом всякие интересности типа Ctrl-C? > Это потом эти вещи стали стандартизировать, О да, стандартизовывать их стали потом. Но когда Торвальдс запиливал vfs в linux, они уже были стандартизованы. Не было никаких разумных причин позволять 1..31 в именах файлов, и единственная реальная причина была в том, что Торвальдс не дал себе труда подумать об этом хотя бы пять секунд.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Forth (ok), 20-Апр-20, 11:06
	...Хамство твоё поскипано, отвечать на это дерьмо не буду... По существу: > Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 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? Можешь ты это понять?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Ordu (ok), 20-Апр-20, 13:07
	> ...Хамство твоё поскипано, отвечать на это дерьмо не буду... > По существу: >> Хаха, лол. Найдёшь мне хоть один пример терминала из истории, который не обрабатывал специальным образом символы 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.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Forth (ok), 20-Апр-20, 14:32
	> Этот графический нестандартный режим для всякой математики. И что он отображал по-твоему? В том числе консольные приложения тоже. Пойми ты, эти самые спецсимволы это исключительно свойство терминала, никак не файловой системы. > 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 это буква "я". --- Ты в текущих реалиях это все примерить пытаешься, а тогда Торвальдс писал мало кому известную хренотень и иметь совместимость с другими платформами было необходимо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Ordu (ok), 20-Апр-20, 16:12
	> И все равно плодились терминалы с альтернативными режимами, вот подиж ты, зачем > казалось бы? Не для того, чтобы этот альтернативный режим использовать для файлов. Ты сам головой подумай: что ты будешь делать с файлом? Твой шелл будет отрисовывать эти имена не в графическом режиме, а в самом что ни на есть обычном. >> Приведи мне пример софта, который для осмысленных целей использовал в именах файлов управляющие символы. Для того чтобы их использовать в именах файлов надо было дебилом, даже если это происходило в 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 стал стандартом ещё до рождения Торвальдса. И управляющие символы стали стандартом тогда же. А про "совместимость с другими платформами" я ещё раз скажу: это не совместимость с платформами, а совместимость с твоей фантазией.
	Ответить \| Правка \| К родителю #44 \| Наверх \| Cообщить модератору


	37. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Аноним (37), 19-Апр-20, 15:01
	Вот, сами юникод упомянули жк. Разрабы юникса просто не стали сразу вводить ограничения, мешающие дальнейшему развитию системы.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	38. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Ordu (ok), 19-Апр-20, 15:52
	> Вот, сами юникод упомянули жк. Разрабы юникса просто не стали сразу вводить > ограничения, мешающие дальнейшему развитию системы. utf8 не использует байты 0x0..0x31. Точнее, эти байты, я думаю, могут встречаться в валидном utf8, но только в том смысле, в котором они появляются в ASCII. То есть в том самом смысле, в котором они не нужны совершенно в именах файлов. Однобайтовые кодопоинты -- это ASCII (то есть значения 0..127), а в многобайтовых все байты имеют старший бит 1.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Forth (ok), 20-Апр-20, 14:35
	Это сейчас фактически только utf-8, а раньше очень даже в ходу был utf-16. Как врочем и куча кодировок иного толка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Ordu (ok), 20-Апр-20, 16:13
	> Это сейчас фактически только utf-8, а раньше очень даже в ходу был > utf-16. Как врочем и куча кодировок иного толка. utf-16, я подозреваю, не удастся использовать в именах файлов никак, даже если не запрещать символы 1..31.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Уязвимость в Git, приводящая к утечке учётных данных"	+/–
	Сообщение от Аноним (31), 15-Апр-20, 17:11
	>Не использовать Си в критически важных местах. Элементарно Ватсон. Каким боком тут C ? Речь шла о скриптах.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	24. "Уязвимость в Git, приводящая к утечке учётных данных"	–1 +/–
	Сообщение от Michael Shigorin (ok), 15-Апр-20, 10:17
	>> 100% скриптов посыпется (если они конечно не написаны мной) ...а ещё я скромный очень и объективный? ;-) > И как сделать, чтобы не посыпались? Как-то так, например: http://altlinux.org/Secure_Packaging_Policy
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору

6. Скрыто модератором	–7 +/–
Сообщение от th3m3 (ok), 15-Апр-20, 00:34
Всё. Мелкомягкие пришли, теперь это место проклято.
Ответить \| Правка \| Наверх \| Cообщить модератору


	9. Скрыто модератором	+/–
	Сообщение от Аноним (9), 15-Апр-20, 00:36
	Это место такое.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. Скрыто модератором	+5 +/–
	Сообщение от Punk_Joker (ok), 15-Апр-20, 01:41
	Хорошо, что Вы как и многие знаете разницу между Git и Github
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	12. Скрыто модератором	+/–
	Сообщение от th3m3 (ok), 15-Апр-20, 02:22
	А всё уже. Пошло заражение дальше.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. Скрыто модератором	+1 +/–
	Сообщение от iPony129412 (?), 15-Апр-20, 07:07
	Следи за копытами. 1) MS является платиновым этим самым в Linux Founation 2) git используется для разработки Linux ядра Всё, попались! Следственно-причинная связь от ведущих аналитиков-комментаторов Opennet.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	15. Скрыто модератором	–1 +/–
	Сообщение от iPony129412 (?), 15-Апр-20, 03:50
	Всё гадят и гадят линуксоидам в штаны 👖 Да что же это творится...
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору