Сори за долгий ответ, не хотелось отвечать совсем не подумав.> Есть ли быстрый надёжный способ найти все code-path ведущие к этому execle и доказать, что во всех этих случаях экранизация выполняется верно?
Я такого способа не знаю.
> Где гарантия, что будущие правки кода не создадут кодопути к этому execle, которые нарушат допущения и засунут туда неэкранированные строки?
Гарантий нет.
> Так уж и не мог бы пофиксить? В случае с условной libsh этот инвалидный почтовый адрес ушёл бы бэкэнду, тот бы либо переслал дальше, либо сообщил о несуществующем адресе. Я не к тому, что ошибку с синтаксически кривым адресом будет более правильным обрабатывать в mda_agent, чем в MTA -- хз, на самом деле: бекенду всё равно нужно проверить валидность, почему бы не свалить эту проверку на него и не париться о ней? -- но, как минимум, при таком раскладе класс опасности ошибки был бы существенно ниже.
Всё верно. Но и корректная логика валидации в текущем снизила бы класс опасности ошибки?
> Бороться с каждой ошибкой в отдельности -- это хорошо, но выделять классы ошибок и использовать AoE спеллы против них -- это гораздо эффективнее. Да, AoE -- не серебряная пуля, но они высвобождают ресуры под то, чтобы бороться с ошибками, которые нам ещё не удалось прибить AoE оружием.
> Но здесь "плата" за AoE -- это виртуально однократно вложенные усилия в разработку libsh.
В теории я согласен с тобой. На практике я не уверен, что платой будут однократно вложенные усилия - могу допустить, что чинить ошибки придётся очень долго или бесконечно. Это если речь про условную универсальную libsh.
Но на самом деле, я сегодня с утра задумался о том, почему я вообще завёл про это речь.
Кажется, более адекватно было бы рассматривать не условный libsh, а возможность использовать какой-то dsl или даже условный python.
Но и тут приходится (имхо) выбирать между двумя крайностями:
* Готовый язык (типа python), вероятно, as-is будет слишком мощный и его придётся огораживать, примерно также, как сейчас огораживается shell.
* DSL, который, в теории, можно написать строго под свои задачи, и который может и не содержать лишнего. Если отказаться от универсализации, то могу согласиться, что это может быть и более хорошим вариант, чем текущий.
Универсальный вариант у меня по-прежнему вызывает сомнения, в том плане, что разработка подобного мне кажется долгим и сложным мероприятием, без гарантий достижения желаемых целей.
Может я неправ, да.
