The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск Rust 1.72. Решение поставлять макрос  serde_derive только в скомпилированном виде"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Второй уровень иерархии тем в форуме реализован через вкладку "Показ ключевых тем".
. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..." +1 +/
Сообщение от Аноним (81), 25-Авг-23, 09:58 
>решив отложить переход на поставку в бинарном виде до принятия в пакетный менеджер crate изменений для полноценной поддержки верификации предкомпилированных макросов. Разработчиками Serde подготовлен RFC с предложением реализовать в Crate верификацию предкомпилированных пакетов, проводимую на сервере репозитория crates.io через сверку бинарного файла с повторяемой сборкой из исходных текстов

Это лишь косметическая мера для того, чтобы успокоить псевдопараноиков-конформистов.

За Rust взялись серьёзно в качестве элемента кибервойны. Статическое связывание всех библиотек в случае их компрометации приведёт статическому внедрению бэкдора в весь софт, от них зависящий. Вычистить его оттуда будет на практике невозможно - это надо будет пересобрать весь софт с чистыми библиотеками. Но Rust устроен так, что это невозможно - библиотеки требуют конкретных версий зависимостей и Cargo их удовлетворяет, а есщи их поменять - то компиляция ломается чаще, чем необходимо, ибо "разработчиков" (в кавычках) на Rust приучили, что ломать API можно без последствий, нужно лишь заплатить налог в виде держания последнего nightly-компилятора, установленного из `curl | sudo`, и гигантских бинарников и долгой компиляции. Тепень фарш нельзя провернуть назад - это придётся переделать пакетный менеджер и все либы, это будет язык, не совместимый с Rust, то есть будет уже не Rust, а другой ЯП с тем же именем. Поэтому его просто не будет.

Но проблема усугубляется тем, что написано уже куча софта и либ на Rust, которые интегрированы в кучу другого софта. Где-то просто потому, что Rust обещал безопасность и производительность. Где-то потому, что кто-то написал реализацию на Rust, а других реализаций под пермессивной лицензией никто не написал. В результате придётся переписать весь такой софт. Кто это делать будет?

Далее предположим на секундочку, что ОК, ну раз необходимо - значит перепишут. Но если весь софт забэкдорен, то что мешает в бэкдор засунуть функциональность вируса, встраивающую в компилирующиеся программы этот самый бэкдор-вирус? Если у нас весь софт инфицирован, где-то потому, что написан на Rust и зависит от вредоносных зависимостей, где-то потому, что на компьютере, где происходит сборку, был установлен забэкдоренный софт, который инфицировал софт во время сборки (т.н. Ken Thompson compiler hack), то как нам получить чистую систему, на которой можно собрать чистые версии софта? Как - понятно - взять старый комп с холодного хранения, там система будет чистая. Но новый софт полностью из исходников такая система не соберёт. И даже если соберёт - в старой системе будут уязвимости, которые можно будет проъксплуатировать и залить новый бэкдор-вирус, поэтому её нельзя вообще к инету подключать.

Эту инициативу нужно давить в зародыше.

1. выкинуть разраба из Rust Software Foundation
2. отжать имя пакета на crates.io и повесить туда форк
3. начать переделывать cargo для ликвидации безответственного и развратного подхода к управлению зависимостями.

3.1 каждая зависимость (имя ящика) на всё дерево зависимостей должна быть в одном экземпляре. Вводить постепенно - через дельту в номере версии, которые считаются "одной версией", захардкоженную в cargo. То есть если в одном месте требуется 1.3.1, 1.3.2 и 1.3.5, то чтобы считалось, что при Δ=1 нужно только 1.3.2 и 1.3.5, а при Δ=3 - только 1.3.5. Дэльту увеличивать так, чтобы на каждое изменение сломался определённый малый процент библиотек на crates.io. Разрабам сломанных библиотек придётся прогнуться и изменить свои привычки. Им не впервой, прогнутся, конформаисты же.

3.2 построить workflow вокруг возможности использования предкомпилированных shared библиотек, при этом какой тип библиотек используется, shared, static или source - должно контролироваться лицом, производящим сборку.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Выпуск Rust 1.72. Решение поставлять макрос  serde_derive только в скомпилированном виде, opennews, 24-Авг-23, 21:52  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру