В Rust-репозитории crates.io выявлены четыре вредоносных пакета

Тут пинки скорее в адрес cargo и сопутствующего стиля разработки, продвигаемого в rust. Не от большого ума языку, продвигаемому под лозунгом безопасности, приделали такую идеологию. После всех-то факапов npm.

Ну хейтеры, конечно, празднуют и пинают всё без разбора.

Ничего не расходится. То что там что-то у кого-то вытеснило - не означает что он лучше подходит. Просто модный тренд.

Это всё в комментах) ОП - сухо и емко, как надо.

На википедии - ужас с точки зрения грамматики и стиля. Но подробно, да. Считайте что придираюсь.

Сарказм неуместен. Даже если у традиционной системы инициализации есть недостатки, то системг очевидно не является вменяемым способом их устранить.

Я для фрибсд например для несистемных сервисов сделал отдельный инициализатор (на Си), который, лично для меня, более удобен чем дефолтные системные скрипты. Но при этом он весьма маленький, никаких дополнительных функций на себя не берёт и остаётся именно системой запуска сервера, а не блоатварью которая хочет следить за всем подряд. И код запуска сервисов всё так же остался скриптами которые можно писать в почти произвольном формате и запустить вручную в виде /path/to/service start без доп. возни.

разработанных двумя педиками ещё в 90-х

Так вот как ты девиантом стал - тяжкое наследие 90х. Долго потом болело?

тебе писали, что для эмбдед это критично

Какая разница что мне, работавшему со встраиваемыми системами, пишут ламеры, которые с ними не работали?

если каждый пакет будет в 10 раз больше весить

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

Указанная новость это из разряда «узбекских вирусов» - скачайте меня, запустите и разошлите друзьям, пожалуйста. Архитектура тут не при чём. Достаточно одного заинтересованного злодея, чтобы написать такой троянский код. И никаких уязвимостей искать не надо, распространение исключительно на социальной инженерии.

Rust тут вообще не при чём. Это можно написать хоть для Java, хоть для Swift, хоть для C++. Создаёшь репозиторий github.com/cpp-sha/cpp-sha, кладёшь туда троянский код и ждёшь, пока какой-нибудь идиот наткнётся и скачает.

Указанная новость это из разряда «узбекских вирусов» - скачайте меня, запустите и разошлите друзьям, пожалуйста. Архитектура тут не при чём. Достаточно одного заинтересованного злодея, чтобы написать такой троянский код. И никаких уязвимостей искать не надо, распространение исключительно на социальной инженерии.

Rust тут вообще не при чём. Это можно написать хоть для Java, хоть для Swift, хоть для C++. Создаёшь репозиторий github.com/cpp-sha/cpp-sha, кладёшь туда троянский код и ждёшь, пока какой-нибудь идиот наткнётся и скачает.

Не согласен абсолютно, т.к. в случае раста - это его «механика» (неотъемлемая часть архитектуры)…

И понятно, что языки с похожей механикой вполне также уязвимы, но в данном случае беда в расте и наличии такой вот «уязвимости», которую нужно принимать во внимание.

Что касается С/С++ - тут сложнее провернуть такой финт, и с этой точки зрения С/С++ более защищен от этой уязвимости, т.к. все более прозрачно и не тянет что-то по зависимостям…

При чём тут архитектура? Какая архитектура? О чём вообще речь?

Rust тут вообще не при чём. Это можно написать хоть для Java, хоть для Swift, хоть для C++. Создаёшь репозиторий github.com/cpp-sha/cpp-sha, кладёшь туда троянский код и ждёшь, пока какой-нибудь идиот наткнётся и скачает.

Не совсем так. Для C++ то же самое реализовать будет довольно проблематично.

Rust как таковой сам по себе здесь действительно ни при чём, проблема в crates.io и cargo, а ещё точнее в централизации. Оно сделано так, что человек создаёт проект, в нём файл Cargo.toml, в котором в секции dependencies просто названия пакетов. И они уже подтягиваются автоматически, то есть оно заточено под то, что юзер даже код не видит до того, как компилировать. Да, это достаточно легко избегается, если работать так же, как и с любым другим языком, то есть прежде чем тянуть что-то по зависимостям, самому скачать, проанализировать и т. д. Но инфраструктура явно способствует тому, чтобы это делалось не глядя. И в этом есть серьёзная проблема.

Конечно, cargo в этом не уникален, до этого мы часто встречали подобные новости об npm, а ещё раньше о чём-то ещё. Но проблема есть. Более того, в широком смысле она характерна не только для репозиториев и кода в них, а много для чего — это давняя проблема централизации обмена безопасности и контроля на (мнимое) удобство. Например, если брать что-то максимально далёкое от программирования: есть люди, которые вместо открытых протоколов для чатиков на любой вкус (IRC, Jabber, Tox, Ring, Matrix…) специально подсаживаются на какое-то централизованное решение от дяди. Корень проблемы здесь один.

При чём тут архитектура? Какая архитектура? О чём вообще речь?

О фразе «подтягиваться по зависимостям»

On December 5th, the crates.io team was notified by Kush Pandya from the Socket Threat Research Team of two malicious crates which were trying to cause confusion with the existing finch crate but adding a dependency on a malicious crate doing data exfiltration.

Раст это язык сойбоев. И карга это одна из любимых фишечек соевой мразоты.

Они же даже в с++ пытаются некие «модули» ввести. это одна из претензий была со стороны ржавой плесени.даже здесь на лоре.

Ну не могут они по другому. Или питон или электрон с нодой, но там тормозит. Или из-за кривизны рук все дико сегфолтится. Вот они и высрали Раст где не надо проектировать боров сам проверит и пакеты родненькие есть

Насчёт его хозяев я сомневаюсь, он не столько раст проталкивает сколько всякие системг с вайландами, которые уже другая история.

Да нет, всё серьёзно. На алиэкспрессах и прочих помойках продаются поддельные ссд в которых внутри как раз мелкая флешка вставлена.

с любым другим языком

Это интересно, с каким же? Все языки без исключения используют ровно такую же модель установки зависимостей. Я по крайней мере других не встречал.

cargo в этом не уникален, до этого мы часто встречали подобные новости об npm, а ещё раньше о чём-то ещё

Да. Жаловаться на то, что я скачал boobs.jpg.exe и оно мне зашифровало файлы, может не очень умный человек, но когда на это жалуется программист, это вызывает удивление. Ты или смотришь, что ты используешь, или просто надеешься на лучшее.

проблема централизации обмена безопасности и контроля на (мнимое) удобство

Я кстати действительно не понимаю, зачем это делают. Вот в go сделано просто - указываешь адрес git репозитория и всё. Никакой централизации. По-мне это правильно. Зачем нужен этот crates.io, куда может слать мусор любой желающий - я не понимаю. Недавно тем же вопросом про арчевский аур задавался, кстати.

Если бы они делали центральный репозиторий, за который кто-то отвечал бы, хотя бы условно - другой вопрос. Вот как fdroid сделал. Они там требуют исходники, собирают всё сами, пытаются даже какие-то аудиты проводить. Это осмысленно. Хотя понятно, что экономически это не взлетит. Проводить полноценный аудит это очень дорого, а за библиотечки никто платить никогда не будет, проще уже самому написать. Может быть LLM-ку если прикрутить, что и получится… Не специалист в этом.

Удобства никакого в этом тоже нет. Любой просто копипастит строчку или команду с официального сайта проекта. Скопипастить короткое имя или чуть более длинный URL - никакой разницы нет.

Зависимости, включая транзитивные, есть в любой системе управления зависимостями. И они в любой системе подтягиваются.

Это интересно, с каким же? Все языки без исключения используют ровно такую же модель установки зависимостей. Я по крайней мере других не встречал.

4.2

Нормальные языки никакую модель установки зависимостей не используют. Это вообще не зона ответственности компилятора, а зона ответственности ОС и её админа.

Пример такого языка?

Си, очевидно.

vcpkg add port fmt

Ещё попытки будут?

Это интересно, с каким же? Все языки без исключения используют ровно такую же модель установки зависимостей. Я по крайней мере других не встречал.

Ну например для C, C++, Pascal нет такой централизации.

Ну или вот сам говоришь:

Вот в go сделано просто - указываешь адрес git репозитория и всё.

Ну например для C, C++, Pascal нет такой централизации.

vcpkg, fppkg

Вот в go сделано просто - указываешь адрес git репозитория и всё.

Ничего не мешает указать git репозиторий с вирусом. Централизация тут не проблема. Я не вижу особого смысла в централизации, но сама по себе она ничего не меняет. На самом деле в ней даже есть некоторый смысл, т.к. можно хотя бы пост-фактум забанить пакет, а если это vasya.org/coolsha.git, то его пост-фактум задолбаешься банить.

Прекращай клоунаду. Твоё vcpkg мало того что чья-то сторонняя поделка, никаким боком частью Си не являющая, так оно ещё и микрософтовское. Ты бы для приличия лучше хотя бы apt привёл в пример - он точно так же не часть Си, но хотя бы не мс.

vcpkg, fppkg

Ни то ни другое не является единственным, стандартным и по умолчанию предполагаемым.

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

Это не важно.

Ну так а я о чём?

Проблема в самом подходе. В первую очередь в том, что программисты сами думать разучились, а в следующую за этим — в том, что им такой подход втюхивается как единственно верный с самого порога.

Для тебя и cmake будет сторонней поделкой. По факту это достаточно популярный инструмент. Наверное даже самый популярный в своём классе.

А apt тут вообще не при чём.

Как раз именно это и важно. Осознанный выбор — это одно, а единственный стандарт, который с порога по умолчанию используется в каждом первом туториале, включая официальную документацию — другое.

Никто думать не разучивался. Просто развитие индустрии пришло к такому варианту. Тебе никто не даст год на написание TLS стека, если ты можешь скачать готовый. И на аудит OpenSSL тебе никто не даст год (даже предполагая, что у тебя есть скилл это сделать, что совсем не обязательно, у меня, к примеру, нет). Есть определённые ожидания и то, что есть некоторая вероятность получить бэкдор в исходниках OpenSSL, этот риск считают оправданным, когда речь идёт о сокращении времени разработки на порядки.

И с этим ничего не сделаешь. Это просто правда жизни. Помнится была какая-то история из ксакепа, как хакеры атаковали столовую и засыпали яд в солонки. Вот примерно так мы живём, всегда под смертельным риском того, что в солонке будет яд, но в столовые всё равно ходим.

IT движется всегда к тому, что выживает 1-2 инструмента. C и C++ это просто умирающие языки, поэтому они тут не очень релевантны, никто на них новые проекты не пишет. А на тех языках, на которых пишут - там везде пакетный менеджер один, максимум два, как, например, у Java. И даже в ней репозитории общие.

До апта ржавым как макакам до человека. Они вообще походу не понимают зачем в дистрах версии по фиксируют. Самую последнюю версию всего что в зависимостях качают с криком уряяяяя

Для тебя и cmake будет сторонней поделкой.

Так и есть.

популярный инструмент

Ну да (к сожалению). Но это не делает его частью Си.

С языком Си связан только компилятор Си. Та штука, которая превращает файлы .c в файлы .o. Ни о каких зависимостях он не знает. Линкер и make связаны с Си весьма условно, ну а всё остальное и подавно не следует с ним аффилировать.

Rust технически тоже мог бы так делать, но, поскольку этот язык, так сказать, изначально приватизирован, у него есть некая группа людей, которая может определять идеологию его работы, и она решила, что для раста мало того что будет своя собственная система сборки, так ещё её частью будет скачивалка мусора из интернета.

А я помню как обжабаные прямо тут c++ хоронили. И чо как успехи?

даемонизирующимися бинарниками, которые могут форкнуться и упасть, например

Если ваш условный MySQL упадёт после того, как запустится и подключится к нему ваш условный 1С, системд не поможет. Если что-то падает при запуске, надо выяснять, почему, а не надеется, что при повторном запуске оно заработает.

Как вам ужо намекнули, если вы запускаете что-то «конвейером», то это надо делать одним скриптом/прогой, прописывая в нём/ней порядок запуска и проверки, а не надеется, что написатели системд и остальных юнитов сделали всё правильно, что вы сделали всё правильно и дерево запуска выстроится верно… при каждом запуске, даже если кто-то, например, вы сами, что-то добавит.

Т.е. правильно написать юнит, верно включить его в дерево зависимостей и т.п. ровно такая же когнитивная задрочка, что и написать инит-скрипт, не обращая внимания на остальные инит-скрипты, которые вас и не касаются, поскольку ваш должен отработать последним.

Вы же понимаете, что системд следит за состоянием системы примерно теми же предоставляемыми ядром и пр. механизмами, что и рукопашные скрипты? Нет никакого libAstral.so, который позволял бы системд узнать, что некий сервис неверно прекратил работу и надо бы перезапустить его юнит.

Компилятор Rust никак не завязан на Cargo. Ничего тебе не мешает не использовать его. Или не скачивать мусор из интернета, используя Cargo. Так что обвинять тут можно только в том, что они сделали скачивание мусора из интернета максимально простым. Но я не думаю, что если его усложнить, это на что-то повлияет.

Хорошая у тебя память, C++ помер ещё лет 20 назад в тех местах, где жава используется.

в солонке будет яд, но в столовые всё равно ходим.

Удачи вам найти в столовках солонки на столах. Сейчас соль выдают в таких запечатанных пакетиках на пару щепоток. Сахар тоже. Или оный в дозаторе, под замком.

А умные люди берут с собою из дому бутеры/жратву в контейнерах, что дешевле и местами вкуснее и сытней.

Они не просто сделали его простым, они продвигают использование раста именно таким способом. Если бы раст, как и Си, был общественным достоянием, а эта компания была бы всего лишь одной из авторов его реализаций - да, это была бы точно так же сторонняя поделка, на которую можно не обращать внимания. Но, поскольку данная компания растом «владеет», её мнение на этот счёт имеет уже другой вес.

В целом да, как уже выше кто-то писал: раст сам по себе ничем особо не выделяется, все проблемы идут от его официальных идеологов, продвигающих неправильные приёмы неприличными способами.

Помнится была какая-то история из ксакепа, как хакеры атаковали столовую и засыпали яд в солонки

Не «какая-то», все знают «хакера в столовой»

https://xakep.ru/2006/12/16/35784/

неправильные приёмы

Неправильный приём: место, из которого можно удобно скачать зависимость со всеми её зависимостями, включая версию с хотфиксом, вышедшую час назад.

Правильный приём: искать подходящий проект хрен знает где и надеяться, что он работает более-менее прилично, что далеко не факт, т.к. язык нафарширован УБ. Следить за обновлениями этого проекта ручками, при CVE в зависимости срочно выпускать новую версию (мы же не заставляем пользователей качать зависимости из десятков разных мест, которые явно надёжней, чем одно централизованное). Гарантий, что с новым релизом тебе не подсунут троян, ровно также никаких, зато много возни.

Интересно, откуда у сишников такая иллюзия, что если они каждую операцию будут делать руками, будь то освобождение памяти, синхронизация потоков или скачивание пакета, то они получат лучший результат, чем если эта вещь будет автоматизирована компилятором, библиотекой или системой сборки?

Удачи вам найти в столовках солонки на столах. Сейчас соль выдают в таких запечатанных пакетиках на пару щепоток. Сахар тоже. Или оный в дозаторе, под замком.

Нет, у меня возле работы узбечка, там обычные солонки и сахарницы. Но интересно, что и такое бывает, значит директор столовой пытается бороться с хакерами (:

А умные люди берут с собою из дому бутеры/жратву в контейнерах, что дешевле и местами вкуснее и сытней.

Чтобы взять из дома жратву, нужно, чтобы она дома как-то появилась. Готовить еду не все любят. А так это, конечно, всё верно.

Но интересно, что и такое бывает, значит директор столовой пытается бороться с хакерами

Скорее, с санпин-проверками. Кстати, я краем уха слышал, что яд действительно подливали в продаваемые в магазинах напитки в бутылках. Дело было в США, очень давно, отравителя не поймали, но ввели «безопасные» крышки, по которым понятно, что бутылку вскрывали.

Facepalm. Эти люди не писали SysV init скрипты, и не знают, как работает systemd. Но учат всех, что ничего лучше SysV не было, а systemd - отстой.

Впрочем, я и так это знал.

Почему сразу SysV? Ещё BSD init есть, он отличается.

Кстати, предлагаю ещё одну тему для спора: sysv/bsd init сервисы vs прописывание автозапуска единой простыней в rc.local.

У меня на ноуте целых 63 строки в последнем. Там и modprobe, и запуск скрипта для настройки iptables, и запуск демонов (пхп, прокси и ещё разные), и создание директорий в tmpfs для упомянутых демонов, и echo XXX > /sys/YYY. Раньше ещё было добавление записей в таблицу роутинга, но потом я заметил что это удобнее в /etc/netwrk/interfaces прописывать т.к. иначе они слетают при ifdown/ifup. Ещё был запуск демона слежения за батареей и яркостью экрана, но в итоге я для него таки написал init скрипт (в rc.local оно занимало 5 строк, отдельный скрипт получился на 68).

Да та же самая история, на самом деле. Контроль над некоторыми ключевыми компонентами системы - компилятор, инициализация, гуйня. В ядро вот лезут, не только и не столько с растом, на самом деле, и уже очень давно, докер этот весьма сомнительный, ну и т.п.

Да нет, всё серьёзно. На алиэкспрессах и прочих помойках продаются поддельные ссд в которых внутри как раз мелкая флешка вставлена.

Я в курсе, но это не тот случай, т.к. проверили на этот предмет ту флешку…

Зависимости, включая транзитивные, есть в любой системе управления зависимостями. И они в любой системе подтягиваются.

Вот только тех зависимостей нет там, где нет системы управления зависимостями… Не так ли…?

отравителя не поймали, но ввели «безопасные» крышки, по которым понятно, что бутылку вскрывали.

Ну вот тут система смогла сделать правильные выводы и исправить ситуацию всем на пользу.

Крышки, по которым понятно, что бутылку вскрывали, в любом случае благо. Отравителей может и немного, но на каждого отравителя найдётся сотня тех, кто захочет просто отлить/отпить, а потом разбавить водопроводной водой, то есть просто мелких воришек на складе, в доставке, в магазине и т. д.

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

Тут проблема в слабой подготовке программиста, т.к. я, например, всегда смотрю что добавляю, а чаще правлю под себя, либо вообще пишу по аналогии, но с учетом архитектуры моего кода, т.к. зачастую в «скачанном» создаются лишние сущности (копии), да и не всегда удобно там все написано или слишком громоздко для моего проекта…