В Linux-сборках эмулятора Cemu обнаружено вредоносное ПО

Так вот, первое требование: а теперь обеспечьте сборку всего этого ВАшего рантайма дотнета и джаваскрипта без доступа в интернет.

Меня всегда интересовало и продолжает интересовать, как такие вопросы решаются при разработке на Rust.

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

Rust - это буквально голубая мечта гентушника.

Если ты делаешь все сам, то найти можно. Или самому таким стать. Примерно за год. А когда ты собираешь вот сейчас вот конкретный дотнет и у тебя в солюшене написано «пойди в Nuget вот туда и вынь оттуда вот это», то тебе остается только переделывать солюшен и менять в нем URLи. А сдавать на сертификацию продукт надо завтра. И переделка солюшенов с тетированием и раскладываеем всего Нугета по локальным полочкам займет месяца три.

Поэтому надо не урлы переделывать, а создать локальный кэш.

P.S. Это, вообще, дичь, конечно, в 2К26 рассказывать людям азы пользования пакетными менеджерами на техническом форуме.

получается проблема в «колокольне» ?

и надо ограждать рута от юзера

Никто обратного не говорил. Но получив доступ к юзеру, уже не составит труда получить рута(кейлогер, fprint-перехват, etc)

Это уже зависит от того насколько безопасным способом используется система. Если у тебя sudo или ты систематически делаешь su из юзерской сессии, смешивая эксплуатацию и администрирование системы, то да. Если же администрирование делается строго из отдельной логин-сессии на отдельном терминале - то перехватить уже затруднительно.

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

А откуда? У тебя в проекте нет внешних зависимостей?

Это к чему вопрос? По третьему кругу пойдем?

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

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

Вопрос к тому, что зависимости нужно скачивать и потом обновлять. Сами собой они не появятся в замкнутом контуре. Кеширование может помочь в решении временных проблем, а может, наоборот, заморозить проблему, если внешние зависимости были скачаны как раз во время сбоя. Это вопрос скорее санкций, но не безопасности.

Разговор со мной начался с проблемы сертификации. Поэтому никаких обновлений.

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

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

Ок. Для узенькой задачи сертификации в текущих условиях можно (и нужно) все скачать и не трогать.

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

и go

Гарантий нет, конечно. Поэтому вообще тянуть зависимости — дело рискованное. Ну, как минимум, можно загнать сборку в контролируемое окружение, есть шанс оценить зловреда по проявлениям, вдруг полезет куда не туда. Ну и аудит кода никто не отменял.

И уж точно со временем в нем будут обнаруживаться дыры. И оставаться под сертификатом уже навсегда…

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

Ну и сам будешь отслеживать CVEшки, которые твой продукт аффектят.

Сертификация теоретически как раз должна среди прочего проверить, что вирусов и прочего там нет. И проверять она должна раз и навсегда фиксированные версии, а не «последнее оттуда-то».

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

Поставка апдейтов от поставщика софта (и они же тоже должны сертифицироваться?), а не поставка апдейтов каких-то сторонних библиотек от третьих лиц.

Апдейты конечно, только от поставщика. Если у него сертифицировано производство, то апдейты можно не сертифицировать. Но у поставщика есть какие-то обязанности перед регулятором, типа CVE фиксить, Ну и там разработка должна следовать процедуре. Как это проверяется я толком не знаю.

Android-style системы для десктопов

Это ещё в 2005 году на Symbian завезли, обратную совместимость при этом поломали. Хочешь в системных папках на телефоне что нибудь сделать - купи сертификат по паспорту, для персонального развлечения есть сертификат разработчика на 1 IMEI.

Вирус заразил exe на карте памяти - контрольные суммы не совпадут и все, запуск вирусни заблокирован. Хочешь втихую встроить gps tracking - не пройдешь проверку или вообще не стартует без явного указания capability.

Нельзя во время сборки, в самом процессе сборки, что-то тянуть из сети. Нельзя. Точка. Кто не согласен, протестируйте прочность монолитного бетона.

Какой-то идиот придумал этот бред, а теперь весь мир сошел с ума. Ну впрочем как всегда, обычная планета Земля.

Почему игра(эмулятор) имеет доступ к SSH-ключам?

Потому что в свободной ОС никому не уперлось ограничивать такие вещи. В этом нет смысла. Бороться надо с причиной проблем - то есть с идиотами, тянущими что-то в процессе сборки из сети, и тянущими что-то не из репозитория без полной проверки, тем более в бинарном виде, а не со следствиями.

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

Масштаб: По предварительным подсчётам, инфицированные файлы могли быть загружены почти 20 000 раз.

Судя по лотерее в 1/6, Cemu зацепило гитхабовской эпидемией червя Mini Shai-Hulud. Общая же оценка количества загрузок всех подмененных и зараженных пакетов - 500 млн.

и тянущими что-то не из репозитория без полной проверки

А то ты весь репозиторий проверил.

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

Большое кол-во сторонних зависимостей, динамическое исполнение, множественные абстракции — это данность, факт, реальность. Даже в случае если ты сидишь в столяров-mode с выключенным JS в браузере.

Единственно правильный подход — изоляция, позволяющая снизить потенциальный ущерб.

Это как с паролями: один пароль на всё — одна утечка, и полная компрометация. Можно сказать: «Проблема не в моём пароле, а в дебилах, которые хранят пароль в базе», — но ты не можешь на это повлиять, а зачастую даже не можешь об этом знать.

Это очень печально, что этого не понимают посетители технического, «админского» форума.

были скомпрометированы

…намеренно авторами ПО.

@moderator второй скрин не имеет отношения к новости.