Serde, популярный проект по де-сериализации Rust, решил поставлять свой макрос serde_derive в виде предварительно скомпилированного двоичного файла.
Этот шаг вызвал немалый резонанс среди разработчиков, которые обеспокоены его будущими юридическими и техническими последствиями, а также возможностью атак на цепочки поставок, если учетная запись сопровождающего, публикующего эти двоичные файлы, будет скомпрометирована.
По данным реестра пакетов Rust, crates.io, за время существования проекта serde был загружен более 196 млн. раз, а макрос serde_derive - более 171 млн. загрузок, что свидетельствует о широком распространении проекта.
Макрос Serde становится прекомпилируемым: отказаться от него невозможно
Около трех недель назад программист на языке Rust, использующий проект Serde в своем приложении, заметил нечто странное.
"Я работаю над упаковкой Serde для Fedora Linux и заметил, что последние версии serde_derive теперь поставляются в виде предварительно скомпилированных двоичных файлов", - написал Фабио Валентини, член комитета по упаковке Fedora.
"Для нас это проблематично, поскольку мы ни при каких обстоятельствах (за очень редким исключением, для микропрограмм и т.п.) не можем распространять предварительно скомпилированные двоичные файлы".
Serde - это широко используемый фреймворк сериализации и десериализации для структур данных Rust, который, как утверждается на его сайте, предназначен для выполнения этих операций "эффективно и обобщенно".
"Экосистема Serde состоит из структур данных, которые знают, как сериализовать и десериализовать себя, а также форматов данных, которые знают, как сериализовать и десериализовать другие вещи", - говорится на сайте проекта. При этом "derive" является одним из его макросов.
Далее Валентини поинтересовался у сопровождающих проекта, как "на самом деле производятся эти новые двоичные файлы" и возможно ли ему воссоздать эти двоичные файлы, а не использовать предварительно скомпилированные версии.
Дэвид Толнай, основной сопровождающий Serde, ответил на этот вопрос, предложив возможные пути решения проблемы. Однако это не означает, что все довольны.
После того, как от разработчиков посыпались комментарии о том, почему это решение не является оптимальным для проекта, Толней признал, что отзывы были получены, после чего закрыл проблему на GitHub.
Его обоснование необходимости поставки прекомпилированных двоичных файлов приводится ниже полностью.
"Прекомпилированная реализация является единственным поддерживаемым способом использования макросов, опубликованных в serde_derive .
Если в каких-то инструментах для сборки требуется работа над реализацией, то кто-то должен не стесняться делать эту работу (как я сделал для Buck и Bazel, которые являются инструментами, которые я использую и в которые вношу значительный вклад) или опубликовать свой форк исходного кода под другим именем.
Отдельно хочу сказать, что в связи с приведенным выше комментарием о безопасности, лучшим вариантом будет, если кто-то из тех, кому это небезразлично, вложит деньги в Cargo или crates.io RFC о первоклассных прекомпилированных макросах, чтобы существовал подход, соответствующий вашим предпочтениям; serde_derive примет его, когда он будет доступен."
"Сначала Moq в .NET, а теперь вот это".
Некоторые разработчики Rust просят оставить прекомпилированные двоичные файлы необязательными и отдельными от оригинального крейта "serde_derive", в то время как другие уподобляют этот шаг спорному изменению кода в проекте Moq .NET, вызвавшему негативную реакцию.
"Пожалуйста, рассмотрите возможность переноса прекомпилированной версии serde_derive в другой крейт и перехода по умолчанию на сборку serde_derive из исходных текстов, чтобы пользователи, желающие получить преимущества прекомпилированных двоичных файлов, могли отказаться от их использования", - попросил один из пользователей.
"Или наоборот. Или любое другое решение, позволяющее собирать из исходников без необходимости патчить serde_derive."
"Двоичный файл, поставляемый как часть крейта, хотя я и понимаю преимущества в скорости сборки, по соображениям безопасности не является жизнеспособным решением для некоторых пользователей библиотек".
Пользователи отметили, что это изменение может повлиять на организации, которые "юридически не имеют права распространять предварительно скомпилированные двоичные файлы в соответствии с их собственными лицензиями", в частности, упоминаются государственные структуры.
". Сначала Moq в .NET, а теперь это", - написал Джордан Сингх, разработчик из Австралии, в комментарии, который позже был удален.
"Если это делается для того, чтобы заставить разработчиков грузовых систем поддерживать какую-либо функцию, то это ужасный способ сделать это. По крайней мере, дайте нам воспроизводимые двоичные файлы. Мне надоело, что разработчики популярных ящиков/библиотек берут всех в заложники абсурдными решениями".
Дональд Стаффт из Филадельфии предостерег от рисков, связанных с "поставкой двоичных файлов" в социальных сетях:
Программист Rust Натан Уэст (Nathan West) под ником Lucretiel особо отметил риски, связанные с цепочкой поставок, которые несут в себе предварительно скомпилированные двоичные файлы, если учетная запись сопровождающего будет взломана:
"Разве это не тот самый способ, которым они собираются действовать? Выдать это за полуправдоподобное изменение в работе serde, непримиримо игнорировать всю критику решения", - написал Уэст.
"Именно по этой причине все так рефлекторно противятся подобным шагам".
"Доверие в Интернете не идеально; мы *не* знаем, что это действительно [мейнтейнер], публикующий информацию на GitHub. Вот почему у нас есть уровни и прокси защиты; небрежная хрень отклоняется, потому что она не стоит риска".
Технолог Санкет Канджалкар назвал переход к поставке двоичных файлов без возможности отказаться от них "шагом назад".
Однако специалист по безопасности, работающий под ником Lander, придерживается несколько иной точки зрения:
"Эта драма с Rust по поводу того, что serde_derive поставляет предварительно скомпилированные двоичные файлы, довольно забавна", - пишет Lander.
"С одной стороны, я понимаю беспокойство людей. С другой стороны, какая разница? Все равно никто не будет читать макрокод proc/build.rs для каждого проекта, который они притаскивают. А вот отказ от участия в проекте был бы неплохой идеей".
Независимо от того, согласны ли вы с решением проекта предоставлять свои макросы в прекомпилированном виде или нет, хорошей практикой является регулярная проверка исходных текстов и двоичных файлов программ перед включением их в свои проекты.
По новым правилам Дзена свежие материалы показываются в первую очередь подписчикам, которые реагируют на публикации. Поэтому не забывайте подписаться, поставить лайк и оставить комментарий, так вы будете первым узнавать о всех новых статьях на нашем канале!
