The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск Rust 1.72. Решение поставлять макрос  serde_derive только в скомпилированном виде, opennews (??), 24-Авг-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


81. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  +1 +/
Сообщение от Аноним (63), 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ообщить модератору

139. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  –1 +/
Сообщение от freecoder (ok), 25-Авг-23, 13:32 
В любом проекте генерируется Cargo.lock файл в котором указаны все зависимости проекта. Обычно этот файл не редактируется вручную, но ничто не мешает залезть туда и поменять версии и репозитории любых зависимостей.
Ответить | Правка | Наверх | Cообщить модератору

142. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  +1 +/
Сообщение от Аноним (142), 25-Авг-23, 13:48 
Я так и делаю, в значительном числе случаев после этого проект перестаёт компилироваться, потому что обратной совместимости в Rust просто не существует, и в языках с таким подходом к связыванию она не может и существовать. Поэтому приходится делать иначе: проходить по всей истории, править уже Cargo.toml, откатывать изменения и сливать конфликты. Это кропотливая ручная работа, которая в отсутствии системы контроля версий, работающей на уровне AST, а не строк, может целый день занять для одного проекта. А теперь представь, что это не 1 проект, а все проекты. Кто это всё будет делать? И, в гипотетических будущих условиях, когда весь софт скомпрометирован и безопасности тебе от вычистки пакетов прибавится пренебрежимо мало, зачем? Проще расслабить булки, что большинство и сделает.
Ответить | Правка | Наверх | Cообщить модератору

143. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  +/
Сообщение от Аноним (143), 25-Авг-23, 13:55 
Понимаешь, всё приятно и легко только у тех, кто сам таким не занимался, а слышал от кого-то, что так можно, и получил короткий рецепт как так делать, без перечисления всех проблем и подводных камней. Это эффектом Даннинга-Крюгера называется.
Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

148. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  –1 +/
Сообщение от freecoder (ok), 25-Авг-23, 14:27 
> Понимаешь, всё приятно и легко только у тех, кто сам таким не
> занимался, а слышал от кого-то, что так можно, и получил короткий
> рецепт как так делать, без перечисления всех проблем и подводных камней.
> Это эффектом Даннинга-Крюгера называется.

Лично я подменой зависимостей занимался, и каких-то серьёзных проблем с этим не имел. В отличии от вас. Так что мне тут больше сказать вам нечего.

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

195. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  –1 +/
Сообщение от Вы забыли заполнить поле Name (?), 26-Авг-23, 21:03 
> Статическое связывание всех библиотек в случае их компрометации приведёт статическому внедрению бэкдора в весь софт, от них зависящий.

В плане безопасности статическое связывание как раз лучше. Один раз собрал и точно знаешь, что обновление другого пакета не добавит уязвимости в конечную программу. Крупные конторы на С++ давно все статически собирают.

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

196. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  +1 +/
Сообщение от Аноним (196), 26-Авг-23, 21:30 
Конторы живущие поддержкой одного большого программного обеспечения.

Если не будешь компилировать статически, кто же будет покупать поддержку с исправлением всех дырок во всех библиотеках?

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

239. "Выпуск Rust 1.72. Поставка пакета serde_derive только в ском..."  +/
Сообщение от Вы забыли заполнить поле Name (?), 29-Авг-23, 00:06 
> Конторы живущие поддержкой одного большого программного обеспечения.
> Если не будешь компилировать статически, кто же будет покупать поддержку с исправлением
> всех дырок во всех библиотеках?

Как предлагается пинать пользователей обновить уязвимые динамические зависимости?

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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