Тем временем наш корпоративный Mattermost
UPD: скорее всего, это баг Firefox
UPD2: это комбинация кривого CSS (с вендор-специфичными свойствами) и поведения Firefox.
#трудовыебудни
UPD: скорее всего, это баг Firefox
UPD2: это комбинация кривого CSS (с вендор-специфичными свойствами) и поведения Firefox.
#трудовыебудни
#prog #video
Why does this Rust program leak memory? от Амоса
Спойлер:фрагментация памяти, так что это на самом деле не утечка и не специфично для Rust
Why does this Rust program leak memory? от Амоса
Спойлер:
YouTube
Why does this Rust program leak memory?
Follow me on Mastodon: https://hachyderm.io/@fasterthanlime
Support my work: https://fasterthanli.me/donate
Thanks to Omer from Egypt for submitting this question: https://github.com/mariocynicys/mem-hog
Submit your own questions: https://fasterthanli.me/submit…
Support my work: https://fasterthanli.me/donate
Thanks to Omer from Egypt for submitting this question: https://github.com/mariocynicys/mem-hog
Submit your own questions: https://fasterthanli.me/submit…
Forwarded from Dani-myte 🧨 (Delulu Vani)
"oh yes what a great sleep I had"
My neck: "oh ho ho no you didn't"
My neck: "oh ho ho no you didn't"
— Пожалуйста, дайте нам возможность использовать алиасы типов в protobuf
— Лол нет
Source
#prog #suckassstory
— Лол нет
Source
#prog #suckassstory
#prog #rust хайлайты:
Stabilize async closures (RFC 3668)
И нет, обойтись просто замыканиями, возвращающими async-блоки, не получится
Stabilize async closures (RFC 3668)
И нет, обойтись просто замыканиями, возвращающими async-блоки, не получится
GitHub
Stabilize async closures (RFC 3668) by compiler-errors · Pull Request #132706 · rust-lang/rust
Async Closures Stabilization Report
This report proposes the stabilization of #![feature(async_closure)] (RFC 3668). This is a long-awaited feature that increases the expressiveness of the Rust lan...
This report proposes the stabilization of #![feature(async_closure)] (RFC 3668). This is a long-awaited feature that increases the expressiveness of the Rust lan...
Forwarded from ReadMe.txt (Ilya)
🤦♂️ Короче, в Англии какие-то тиктокеры завирусили «Белые ночи» Достоевского
И это теперь одна из самых продаваемых книг на всем острове. Все это дело назвали Fyodor Fever — британские зумеры и альфа побежали сметать Федора Михайловича с книжных полок.
И это теперь одна из самых продаваемых книг на всем острове. Все это дело назвали Fyodor Fever — британские зумеры и альфа побежали сметать Федора Михайловича с книжных полок.
#itsec
Uncovering GStreamer secrets
TL;DR: чел написал кастомный генератор начальных данных для фаззера и нашёл 29 новых потенциальных уязвимостей в GStreamer.
Фаззинг программ, разбирающих медиа-форматы, затруднителен тем, что готовые медиа-файлы слишком большие, чтобы эффективно использовать фаззинг, поскольку фаззеры обычно применяют побайтовые мутации к входным данным. Конкретно в случае с MP4 проблема усугубляется строением формата. Именно, файл MP4 состоит из нескольких box-ов, которые могут быть вложенными, и каждый из них начинается с заголовка, который включает в себя размер всего box-а. Если фаззер применяет мутацию, которая вставляет новые данные, он не в состоянии одновременно также и скорректировать размеры в нужных местах.
В статье описан алгоритм для генерирования случайных MP4-файлов. Коротко:
* создаётся случайное дерево, описывающее вложенные box-ы
* по узлам раскидываются теги
* листья дерева получают случайные размеры, размер остальных подсчитывается из суммы вложенных
* для каждого узла генерируются случайные данные в рамках выбранных размеров
* итоговое дерево сериализуется
К сожалению, из статьи непонятно, написал ли автор только генератор тестовых данных или ещё и мутатор.
Сами найденные ошибки, кстати, все типичные сишные: OOB-чтение/запись, разыменовывания NULL-указателей и даже одно use after free.
Uncovering GStreamer secrets
TL;DR: чел написал кастомный генератор начальных данных для фаззера и нашёл 29 новых потенциальных уязвимостей в GStreamer.
Фаззинг программ, разбирающих медиа-форматы, затруднителен тем, что готовые медиа-файлы слишком большие, чтобы эффективно использовать фаззинг, поскольку фаззеры обычно применяют побайтовые мутации к входным данным. Конкретно в случае с MP4 проблема усугубляется строением формата. Именно, файл MP4 состоит из нескольких box-ов, которые могут быть вложенными, и каждый из них начинается с заголовка, который включает в себя размер всего box-а. Если фаззер применяет мутацию, которая вставляет новые данные, он не в состоянии одновременно также и скорректировать размеры в нужных местах.
В статье описан алгоритм для генерирования случайных MP4-файлов. Коротко:
* создаётся случайное дерево, описывающее вложенные box-ы
* по узлам раскидываются теги
* листья дерева получают случайные размеры, размер остальных подсчитывается из суммы вложенных
* для каждого узла генерируются случайные данные в рамках выбранных размеров
* итоговое дерево сериализуется
К сожалению, из статьи непонятно, написал ли автор только генератор тестовых данных или ещё и мутатор.
Сами найденные ошибки, кстати, все типичные сишные: OOB-чтение/запись, разыменовывания NULL-указателей и даже одно use after free.