> Я не понимаю, чем валидация данных в отдельной библиотеке лучше, чем в коде самого OpenSMTPD.Во-первых, там не нужна валидация. Нельзя сказать, чтобы совсем не нужна, но сравни:
execle("/usr/libexec/mail.local", "mail.local", "-f", from, to);
и
execle("/bin/sh", "sh", "-c", "/usr/libexec/mail.local", "-f", from, to)
Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`). Чтобы этого избежать во втором варианте, мы включаем экранирование, чтобы после shell expansion'а, mail.local получил бы именно то, что исходно лежало в переменных from и to, а не что-то иное. Или иными словами: мы знаем, что на from и to будет вызвана функция expand и в mail.local будут переданы аргументы expand(from) и expand(to), но нам надо передать from и to, поэтому мы создаём функцию unexpand, такую что \forall x expand(unexpand(x)) == x, и после этого мы передаём в mail.local значения expand(unexpand(from)) и expand(unexpand(to)).
В первом варианте мы непросредственно прокидываем содержимое from и to в mail.local через егойный argv, нам не нужен unexpand, потому что нет никакого expand. Но мы лишаемся шелловского job control'а, что становится особенно болезненным, если нам надо через пайпы что-то прокидывать в вызываемую команду, или через пайпы же вычитывать вывод вызываемой команды.
Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход. Как она это делает -- мы не знаем, и это нас не касается. Может быть программа складывает значения в sql базу данных, и поэтому значения from и to надо экранировать по sql-правилам экранирования. Может быть она создаёт файл с именем from, и поэтому ей надо что-то сделать с from, преобразовать в строку которая может быть именем файла. Но это уже проблемы вызываемой программы. (точнее в идеале именно она должна этим заниматься, иногда это невозможно или слишком сложно, но не в том случае, о котором новость).
То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход.
Во-вторых, даже если бы валидация от шелла и нужна была бы, то она была бы нужна в библиотеке, которой пользуются многие. В этой библиотеке были бы баги, но одни на всех. Устранение бага в библиотеке устраняет баги у всех. Ресурсы вложенные в аудит кода, в тестирование кода разными методами будут возвращаться всем проектам. Если мы представим на секундочку модель разработки софта, в которой многие проекты вызывают шелл, и каждый проект вкладывает какое-то количество ресурсов в то, чтобы обезбажить этот вызов шелла, и сравним её с моделью, в которой есть единая библиотека, чей API гарантирует отсутствие багов, баги могут скрываться лишь в реализации, и в обезбаживание этой реализации вкладывается суммарное количество ресурсов, которое в первой модели вкладывалось в обезбаживание частных реализаций, то какой вариант будет безбажнее?
Да, тут есть свои подводные камни: баг, найденный в библиотеке, сделает уязвимыми многие программы. Но system и exec("sh", ...) -- это весьма распространённые штуки в *nix, то есть существует множество людей заинтересованных в том, чтобы делать это максимально надёжно и безопасно, а значит можно вбухать реально много ресурсов в то, чтобы продумать API и вылизать реализацию. Плюс не обязательно внедрять эту библиотеку сразу везде и в продакшн. Можно форкнуть заинтересованные проекты и тащить пару лет форки, крича на всех углах о том, какие у нас безопасные форки, провоцируя других на то, чтобы они доказывали бы нам, насколько глубоко мы ошибаемся. Некоторые доказательства будут сопровождаться эксплоитами, что будет очень полезно нам. Через несколько несовместимых переписываний API мы доберёмся до v1.0, и тогда... Но для этого нужно, чтобы за проектом стояла организация типа OpenBSD, которая давала бы маркетинга и оплачивала бы хотя бы одного квалифицированного программиста на полную занятость.
> Насколько я могу понимать, никто не написал универсальную библиотеку, решающую проблемы экранирования спецсимволов на все случаи жизни.
Я говорю не об универсальной библиотеке, экранирующая спецсимволы, я говорю о /bin/sh в виде подгружаемой библиотеки. В некотором смысле, семантически это sh, но с другим синтаксисом. Этот синтаксис более многословный и неудобный для использования в командной строке, и вообще без компиляции с ним не поработаешь. Зато он оптимизирован на избегание _распространённых_ проблем вызванных ошибками экранирования.
