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

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

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

Собственно, если б Паскаль/Дельфи архитектурно похоже выглядели, то и на этих ЯП можно то же самое делать (имеется ввиду, что контроль может быть важнее синтаксиса, т.к. остальное решается в «рабочем порядке»)…

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

Судя по «высокому стилю» вышенаписанного - все, как раз, с точностью - до наоборот :)

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

Нет, не по этому! Старые теории - это полуправда, подкинутая нам спецслужбами. Нужны свои, новые, вот они будут правдой!

Нет, не по этому! Старые теории - это полуправда, подкинутая нам спецслужбами. Нужны свои, новые, вот они будут правдой!

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

А вот среди тех, кто разумно не любит системг, нетупых весьма много.

Да всё давно выродилось в старообрядческое сектантство. Вот на чем можно сделать сервер для продакшна без системд? Так чтобы без дураков в стиле «а у меня вот подкроватный диван». Я только слышал о варианте с Альтом, но и они вроде прекратили поддержку sysv. Возня на десктопе хацкера не очень интересна. Там что угодно сойдет, даже инит из слаки.

Да уж 100500 раз без преувеличения всё жёвано-пережёвано. Ещё раз скажу:

1. В 90-е я по работе писал уйму SysV init скриптов. Врагу не пожелаю. Всё это было крайне непереносимо между дистрибутивами, крайне костыльно и ненадёжно. Любить SysV могут только те, кто пользовался уже готовыми скриптами и никогда не сталкивался с необходимостью писать их для сколько-нибудь сложного софта.
2. Пользуюсь systemd уже где-то 10 лет. Ни разу не имел с ним ни одной проблемы, наоборот, всё стало сильно проще и понятнее.

Нелюбовь к systemd имеет идиосинкратические причины, а не рациональные.

С sysv понятно, но есть же openrc и что-то ещё молодежное. Не вижу, чтобы это хоть где-то применялось кроме контейнеров с Alpine.

ответ ИИ: Да, Microsoft активно поддерживает Rust

Это как раз не удивляет из-за схожести синтаксиса c их порождением F#. Больше удивляет, например, увлечение Gnome этим языком.

Наверное из-за того, что все в расте связывается статически.

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

Для «сервера для продакшна» линуксы вообще не очень подходят, они больше для десктопа. Для серверов надо фрибсд. Если выбирать именно из линуксов то лучше всего дебиан или девуан. Тут жёсткая подстава получилась от авторов дебиана, да: они и до этого были наиболее вменяемым прод-дистром, но всунули себе системг и теперь те, кто изучил дебиан, к сожалению имеют привычку пользоваться системг. Поэтому надо смещать выбор на девуан. Но, повторюсь, это на самом деле нужно всё равно фрибсд и системг-проблема там неактуальна.

В 90-е я по работе писал уйму SysV init скриптов. Врагу не пожелаю. Всё это было крайне непереносимо между дистрибутивами, крайне костыльно и ненадёжно.

Ты кем работал? Тут два варианта: 1) админ серверов, который адаптирует чужой софт для запуска на своих серверах, 2) мейнтейнер софта, который опакечивает его под разные дистры для публикации/продажи.

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

писать их для сколько-нибудь сложного софта

У сложного софта не должно быть сложного init-скрипта. Сложные init-скрипты обычно у недоделанного софта. Хороший софт обычно запускается в одну строчку (путь к демону и аргументы).

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

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

Попробуй написать правильные зависимости для запуска сервисов в определённом порядке (чтобы сервис, который зависит от базы, запустился только после того, как база гарантированно запустилась, и т.п.) в SysV init. С даемонизирующимися бинарниками, которые могут форкнуться и упасть, например. Удачи.

Кто не пробовал, тот не поймёт, от чего нас избавил systemd.

И нет, то что ты говоришь, явно показывает, что ты никогда не писал сам init скрипты.

Писал, конечно.

Попробуй написать правильные зависимости между запуском сервисов в SysV init

Если софт адекватно написан, никаких проблем. Точнее, зависимости вообще актуальны только для системы инициализации ОС, а у тебя, как я понял, какой-то прикладной сервис. Прикладной сервис должен правильно работать если его запустить в самом конце (после того как базовая система ОС уже запустилась) и не важно в каком порядке.

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

Ага, у тебя падают бинарники, а виноват конечно инит. Видел хоть раз упавший на старте nginx (ну кроме битого конфига)?

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

А что за история-то?

Для «сервера для продакшна» линуксы вообще не очень подходят, они больше для десктопа.

Неожиданно. Но в контексте десктопа системд-срач не имеет смысла. Дистр же выбирают не по одному только параметру наличия отсутствия очумелых ручек поттеринга. Это было бы слишком упорото. Тем более, он пролезет все равно вместе с udev и logind. Если последовательно всё это вырезать, то и правда нужно валить на BSD.

А что за история-то?

Вкратце: Мейнтейнер устал от проекта, ему начал помогать некий китаец и втёрся в доверие, ему дали права мейнтейнера и он впихнул бэкдор в библиотеку.

Даже на Википедии есть: Бэкдор_в_XZ

Для «сервера для продакшна» линуксы вообще не очень подходят, они больше для десктопа. Для серверов надо фрибсд.

Ваши слова расходятся с реальностью. Линукс уже давно вытеснил FreeBSD на серверах. Сейчас встретить FreeBSD на сервере – большая редкость.

Кривейше написанная статья, хоть и информативная. Поддерживайте отечественного производителя: В коде xz версий 5.6.0 и 5.6.1 обнаружен бэкдор

да ладна, минимум инфы, а детективная фабула вообще отсутствует

Тут пинки скорее в адрес 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 тут вообще не при чём.

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