Rust всемогущий: ищу истории успеха

безопасная генерация кодов для 2FA

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

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

Ага. Потому что ООП не нужно, тем более в Rust.

и высокоуровневые языки, пишем на ASSembler… хотя и он не нужен. Почему бы как тру-кодеры не писать программы в хекс-редакторе?

https://www.thecodedmessage.com/posts/oop-2-polymorphism/

tldr - у Rust полиморфизм куда гибче того что в плюсах, без всяких наследований, так что да, ООП в Rust не нужен

и высокоуровневые языки, пишем на ASSembler… хотя и он не нужен. Почему бы как тру-кодеры не писать программы в хекс-редакторе?

Потому что ты не знаешь, что такое языки высокого уровня.

CVE-2021-45720 An issue was discovered in the lru crate before 0.7.1 for Rust. The iterators have a use-after-free, as demonstrated by an access after a pop operation.

CVE-2021-45719 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. update_hook has a use-after-free.

CVE-2021-45718 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. rollback_hook has a use-after-free.

CVE-2021-45717 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. commit_hook has a use-after-free.

CVE-2021-45716 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_collation has a use-after-free.

CVE-2021-45715 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_window_function has a use-after-free.

CVE-2021-45714 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_aggregate_function has a use-after-free.

CVE-2021-45713 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_scalar_function has a use-after-free.

CVE-2021-45702 An issue was discovered in the tremor-script crate before 0.11.6 for Rust. A merge operation may result in a use-after-free.

CVE-2021-45701 An issue was discovered in the tremor-script crate before 0.11.6 for Rust. A patch operation may result in a use-after-free.

CVE-2021-45707 An issue was discovered in the nix crate 0.16.0 and later before 0.20.2, 0.21.x before 0.21.2, and 0.22.x before 0.22.2 for Rust. unistd::getgrouplist has an out-of-bounds write if a user is in more than 16 /etc/groups groups.

CVE-2021-28027 An issue was discovered in the bam crate before 0.1.3 for Rust. There is an integer underflow and out-of-bounds write during the loading of a bgzip block.

CVE-2021-26957 An issue was discovered in the xcb crate through 2021-02-04 for Rust. It has a soundness violation because there is an out-of-bounds read in xcb::xproto::change_property(), as demonstrated by a format=32 T=u8 situation where out-of-bounds bytes are sent to an X server.

CVE-2020-36435 An issue was discovered in the ruspiro-singleton crate before 0.4.1 for Rust. In Singleton, Send and Sync do not have bounds checks.

CVE-2020-35877 An issue was discovered in the ozone crate through 2020-07-04 for Rust. Memory safety is violated because of out-of-bounds access.

Так! Падажжите! Но ведь раст гарантирует безопасный доступ к памяти!

Или не гарантирует?

CVE-2018-25026 An issue was discovered in the actix-web crate before 0.7.15 for Rust. It can add the Send marker trait to an object that cannot be sent between threads safely, leading to memory corruption.

CVE-2017-20004 In the standard library in Rust before 1.19.0, there is a synchronization problem in the MutexGuard object. MutexGuards can be used across threads with any types, allowing for memory safety issues through race conditions.

CVE-2020-35914 An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockWriteGuard unsoundness.

CVE-2020-35913 An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockReadGuard unsoundness.

CVE-2020-35912 An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockWriteGuard unsoundness.

CVE-2020-35911 An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockReadGuard unsoundness.

CVE-2020-35910 An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedMutexGuard unsoundness.

Ой! И потокобезопасность тоже не гарантирует штоле???

CVE-2019-16882 An issue was discovered in the string-interner crate before 0.7.1 for Rust. It allows attackers to read from memory locations associated with dangling pointers, because of a cloning flaw.

CVE-2020-26235 In Rust time crate from version 0.2.7 and before version 0.2.23, unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires the user to set any environment variable in a different thread than the affected functions. The affected functions are time::UtcOffset::local_offset_at, time::UtcOffset::try_local_offset_at, time::UtcOffset::current_local_offset, time::UtcOffset::try_current_local_offset, time::OffsetDateTime::now_local and time::OffsetDateTime::try_now_local. Non-Unix targets are unaffected. This includes Windows and wasm. The issue was introduced in version 0.2.7 and fixed in version 0.2.23.

CVE-2020-35881 An issue was discovered in the traitobject crate through 2020-06-01 for Rust. It has false expectations about fat pointers, possibly causing memory corruption in, for example, Rust 2.x.

CVE-2020-35907 An issue was discovered in the futures-task crate before 0.3.5 for Rust. futures_task::noop_waker_ref allows a NULL pointer dereference.

CVE-2021-45681 An issue was discovered in the derive-com-impl crate before 0.1.2 for Rust. An invalid reference (and memory corruption) can occur because AddRef might not be called before returning a pointer.

CVE-2021-45680 An issue was discovered in the vec-const crate before 2.0.0 for Rust. It tries to construct a Vec from a pointer to a const slice, leading to memory corruption.

CVE-2021-43620 An issue was discovered in the fruity crate through 0.2.0 for Rust. Security-relevant validation of filename extensions is plausibly affected. Methods of NSString for conversion to a string may return a partial result. Because they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first ‘\0’ byte, which might not be the end of the string.

Охренеть! Но это же только в сишке может быть!

Или нет?

CVE-2020-35860 An issue was discovered in the cbox crate through 2020-03-19 for Rust. The CBox API allows dereferencing raw pointers without a requirement for unsafe code.

Тааак, а это походу «дырявые абстракции» от не менее дырявых авторов…

CVE-2021-25904 An issue was discovered in the av-data crate before 0.3.0 for Rust. A raw pointer is dereferenced, leading to a read of an arbitrary memory address, sometimes causing a segfault.

А вот это очень напоминает heartbleed которым растомани пугали сишников последние несколько лет, ЛОЛ!

Можешь потроллить и переписать программу написанную на rust на любой другой язык.

https://github.com/BurntSushi/ripgrep уже приносили?

сам пользуюсь: bottom broot

Возьму только один пример,

CVE-2021-43620 An issue was discovered in the fruity crate through 0.2.0 for Rust. Security-relevant validation of filename extensions is plausibly affected. Methods of NSString for conversion to a string may return a partial result. Because they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first ‘\0’ byte, which might not be the end of the string.

Проще отследить части unsafe кода, чем весь код когда он весь unsafe

CVE доказывает, что в данном случае этот тезис не работает.

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

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

Так что спасибо, заверните и унесите, откуда принесли :))

CVE показывает, что в unsafe коде, который оборачивается в unsafe {} в расте или же который целиком таковой в Си и С++, могут быть ошибки доступа к памяти.

не дает видимых преимуществ в скорости за пределами каких-нибудь гигантских монореп

Где-то дает преимущество - это хорошо.

компиляется в 5-мегабайтный бинарь по сравнению с сотней килобайт у конкурентов

Это определенный недостаток для некоторых платформ. С другой стороны, для многих платформ подобная разница в размере бинарного файла cli утилиты является несущественной.

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

По сути поста:

[x] на расте уделывала имеющиеся аналоги

[x] с реальными бенчмарками и цифрами

Неа!

Все эти CVE показывают, что как только рустеры начинают писать что-то реальное, а не очередую вычислялку факториалов, - сразу же начинают совершать все те ошибки, от которых руст якобы защищает.

А опыт вот этого чувака:

https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

(спасибо Siborgium за историю успеха) говорит нам о том, что:

Unsafe Rust is hard. A lot harder than C, this is because unsafe Rust has a lot of nuanced rules about undefined behaviour (UB) — thanks to the borrow checker — that make it easy to perniciously break things and introduce bugs.

т.е. за пределами мира розовых поней unsafe не просто нужен, чтобы огородить участки с возможным UB;

unsafe это и есть концентрированное UB!

unsafe это и есть концентрированное UB!

Ещё и растаманы необучаемые просто. Верят в мифический бороу чекер.

Когда говоришь им, что в Rust есть AddressSanitizer, ThreadSanitizer и прочие санитайзеры и нужно точно также их настраивать как для C/C++ проектов, они говорят что для Rust не нужно и их защитит бороу чекер.

Достаточно проверить проекты на Rust и что почти нигде не настроены санитайзеры…

Доки по санитайзерам: https://doc.rust-lang.org/unstable-book/compiler-flags/sanitizer.html

https://doc.rust-lang.org/reference/behavior-considered-undefined.html

The following list is not exhaustive. There is no formal model of Rust’s semantics for what is and is not allowed in unsafe code, so there may be more behavior considered unsafe. The following list is just what we know for sure is undefined behavior. Please read the Rustonomicon before writing unsafe code.

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

Потому что никто не хочет делать это бесплатно.

То есть легче следить за 100 строками чем за 5?

Неа!

То есть он не защищает и не способен уберечь хотя бы даже от одной ошибки в реальном проекте, которая могла бы случится в С/C++?

То есть он не защищает и не способен уберечь хотя бы даже от одной ошибки в реальном проекте, которая могла бы случится в С/C++?

задача раст в том, чтобы защитить тебя от С/C++ и уберечь от реальных проектов. ошибки-то тут причем?

Потом librsvg автор переписал на rust. Это больше на историю успеха похоже. Не знаю как по скорости работы, но скорость сборки пострадала значительно.

А ещё необходимое дисковое пространство.

Ага. Потому что ООП не нужно, тем более в Rust.

А что это такое на макросах кривое-косое? https://github.com/gtk-rs/gtk4-rs/blob/master/book/listings/g_object_subclass...

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

Ну у си хоть какая-то спецификация есть. Другое дело что в ней написано…

Дотянуться ты можешь, правда, разве что до портов на локалхосте.

Скорее всего скорость упала по причине того, что он ещё и зависимости из crate собирает и заметная часть времени на это уходит.

rusqlite

Это обвязка над sqlite либой. Там unsafe во все поля и наколоться можно влёт.

CVE-2020-36435

Окей, но тут надо прям самострел устроить

CVE-2020-35877

Чуваки решили поиграть с памятью в unsafe блоке и проиграли. ВНЕЗАПНО. Ну то есть буквально - вышли за заборчик и отстрелили яйца в погоне за перформансом.

остальное лень копать.

по сравнению с сотней килобайт у конкурентов

А потом приносишь эти сто килобайт на другую машину и ой: «version `GLIBC_2.15’ not found»

Хотя рачту действительно ещё есть куда оптимизироваться, по размеру бинарей, да.

И при этом по несколько раз разные версии одной и той же библиотеки. Ужас.

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

unsafe это и есть концентрированное UB!

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

кто более опенсорсный, Java или C#? (комментарий)

Что впрочем так для большинства языков.

Которые не являются торговыми марками, в отличие от раст.

Тем не менее cranelift и gcc-rs как-то живут. В целом раст это (пока ещё) не тот проект, где бы зависимость от вендора заставляла страдать.

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

потом приносишь 5-мегабайтный растовый бинарь на другую машину, а он тоже «version `GLIBC_2.15’ not found»

Это обвязка над sqlite либой. Там unsafe во все поля и наколоться можно влёт.

И кто мешал пейсателям обвязки правильно поуправлять памятью?

Что опять сишники какаху в шаровары подложили?

Окей, но тут надо прям самострел устроить

И вовсе то мы не облажались!

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

Ещё раз:

Unsafe Rust is hard. A lot harder than C, this is because unsafe Rust has a lot of nuanced rules about undefined behaviour (UB) — thanks to the borrow checker — that make it easy to perniciously break things and introduce bugs.

A lot harder than C

A lot

Смекаешь? unsafe это не «заборчик», это портал в АДЪ!!адин

остальное лень копать.

Ну логично, так можно символов веры лишиться

И кто мешал пейсателям обвязки правильно поуправлять памятью?
Что опять сишники какаху в шаровары подложили?

Примерно то же самое, что и https://www.cve.org/CVERecord?id=CVE-2023-0401 сишникам. Ну что ты будешь делать, постоянно рукожопы какие-то пишут важные проекты, вместо хороших, годных сишников.

A lot harder than C
Смекаешь? unsafe это не «заборчик», это портал в АДЪ!!адин

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

Ну логично, так можно символов веры лишиться

Ойвэй, а что это у нас так взбугуртнуло-то? Ты из неосиляторов и у тебя пригорает от того, что пусть кривой и странный инструмент, оказывается удобнее твоего каменного молоточка? Антипригарин продаётся в ближайшей аптеке, не является медицинской рекомендацией, перед применением посоветуйтесь с вашим лечащим психиатром.

Что-то когда я приношу бинари с собранные с musl ничего не вылезает.

дак а на сишке с плюсами что мешает на мюсле собрать? Это же сишная библиотека, если что))

Ой вэй, там один зигонафт обосрался от того, что пришлось писать на си в синтаксисе раста.

Нет. У него пригорело от того, что unsafe-блоке пришлось делать работу бороучекера руками.

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

Вот пример его БОЛИ:

You might make a mutable reference to some data, call some functions, and then like 10 layers deep into the call stack one function might make an immutable reference to that same data, and now you have undefined behaviour. Woo!

Печалька, да…

Ойвэй, а что это у нас так взбугуртнуло-то?

Уж не знаю, что там у тебя взбугуртнуло.

Я лежу с простудой и зашел на ЛОР почитать что-нибудь не слишком умное.

Вот читаю растоманские сказки про серебряные пули.

Ты из неосиляторов

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

У меня бывают задачи под C,C++,python,cython и даже KiCAD с FreeCAD.

Скоро может возникнуть нечто на verilog и Gowin (импортозамещение же!).

Задач, в которых нужно применить Раст пока не было и в обозримом будущем не предвидится.

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

Сравнение не корректно.

Я бы сказал, что мы сравниваем лапти с новой блестящей инвалидной каталкой.

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

З.Ы. В постах могут быть ошибки и опечатки, плохо по кнопкам попадаю…

Выходит, что так. Программист привыкает, что компилятор делает проверки за него и не следит за местами, где компилятор их не делает. Либо в принципе не нарабатывает необходимых навыков безопасной разработки.

Выходит, что так. Программист привыкает, что компилятор делает проверки за него и не следит за местами, где компилятор их не делает.

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

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

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

Ага. Потому что ООП не нужно, тем более в Rust.

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

Дженереки в Go не нужны, потому что сам Go не нужен. Как и ООП.

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

потом приносишь 5-мегабайтный растовый бинарь на другую машину, а он тоже «version `GLIBC_2.15’ not found»

Потому что glibc – днище и не может в статическую линковку. Проще с musl линковаться.

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

Ну сишники так и считают, в общем-то. Смотри вот этот тред: Навеяно свежей дырой в Xorg

В частности, про то как firkax ругает -Wall, потому что тот ломает ему код.

Дженереки в Go не нужны, потому что сам Go не нужен. Как и ООП.

Да, нам же так скучно, что мы хотим эмулировать ООП на С, а вместо строгой типизации использовать void*

Моя мечта вместо std::list<anything> всю жизнь писать вот этот трэш

typedef struct node {
    struct node* prev, *next;
    void* data;
} Node;