Исходное сообщение
"Уязвимость в Git, приводящая к утечке учётных данных" Отправлено Ordu, 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'ов неясно.