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

"Уязвимость в 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.dev/opennews/art.shtml?num=52734
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

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

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

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

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

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

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

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

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

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

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

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

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

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

19. Сообщение от Сэр Аноним (?), 15-Апр-20, 07:30	+6 +/–
— Что такое экранирование, Бэрримор? — Это то, что умеют делать хакеры, но не умеют погромисты, сэр.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #36

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

22. Сообщение от Аноним (22), 15-Апр-20, 09:02	+/–
А с каких пор git только для github? При обращении по такому url должны передаваться параметры авторизации к сайту evil com, а не к гитхабу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33

23. Сообщение от Аноним (3), 15-Апр-20, 09:58	+3 +/–
Файл с писком. (:
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27

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

25. Сообщение от Нонон (?), 15-Апр-20, 11:17	+/–
git update-git-for-windows -y Не благодарите)
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от Аноним (26), 15-Апр-20, 11:31	–5 +/–
зачем вообще в гите нужны эти субмодули? Никогда не видел от них ничего кроме проблем. Да и не только я, никто ими не пользуется.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28, #32

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

28. Сообщение от Ag (ok), 15-Апр-20, 12:17	+/–
Тю, а дырки в заборе шоб лазить мимо проходной тогда як делать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

29. Сообщение от Бум (?), 15-Апр-20, 14:33	+/–
>погромисты =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

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

32. Сообщение от нитрол (?), 15-Апр-20, 17:37	+/–
шикарная аналитика и статистика, OLAP запрос за 1 сек - отчет по всей планете :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

33. Сообщение от КО (?), 15-Апр-20, 17:52	+/–
Наверное, можно было и от gitlab попросить. Ожидать, что разработчик доверил гиту пароль от банка несколько наивно, хотя кто их знает ... :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

34. Сообщение от КО (?), 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ообщить модератору

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

36. Сообщение от Аноним (36), 16-Апр-20, 02:07	+/–
- получается тяга к свободе информации приводит к ее экранированию. Это весьма странно, Бэрримор. - Диалектика, Сэр
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

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

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

39. Сообщение от 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ообщить модератору
Родитель: #35 Ответы: #40

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

41. Сообщение от 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ообщить модератору
Родитель: #40 Ответы: #42

42. Сообщение от 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ообщить модератору
Родитель: #41 Ответы: #43

43. Сообщение от 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ообщить модератору
Родитель: #42 Ответы: #44

44. Сообщение от 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ообщить модератору
Родитель: #43 Ответы: #46

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

46. Сообщение от 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 стал стандартом ещё до рождения Торвальдса. И управляющие символы стали стандартом тогда же. А про "совместимость с другими платформами" я ещё раз скажу: это не совместимость с платформами, а совместимость с твоей фантазией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

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

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

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