https://www.opennet.ru/opennews/art.shtml?num=62441

29 новых уязвимостей в #gstreamer.

Текст про описание подхода - https://github.blog/security/vulnerability-research/uncovering-gstreamer-secrets/

TL;DR - был использован fuzzer, отдельный интерес представляет то, как коллега строил корпус для фаззинга.

Полагаю, что это только начало, потому что он нашел ошибки только в тех контейнерах, которые он явно таргетировал, а таргетировал он далеко не все, что бывает (mkv/mp4).

https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

TL;DR - из libcurl удаляют альтернативный HTTP/1 backend, основанный на https://hyper.rs/ (кстати, не открывается у меня без VPN, наверное, очередная контора пидорасов! Нет, просто они не осилили QUIC)

Почему?

Закончились деньги из гранта.

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

Как-то обсуждали, что fish shell перепишут на Rust - https://www.tgoop.com/it_pg_talks/20668

И, пожалуйста, переписали - https://github.com/fish-shell/fish-shell/releases/tag/4.0b1 (ну, не все, но большую часть, ладно).

Но зато закрыли тикет про то, что в fish shell не хватает set -e, то есть, выхода, когда какая-то команда завершилась с ошибкой - https://github.com/fish-shell/fish-shell/issues/510

Как без этого можно вообще писать серьезные скрипты, я не знаю.

Но точно знаю, что "переписывать на Rust" явно больше fun, чем пилить какие-то продуктовые фичи.

https://www.phoronix.com/news/Linux-6.12-Liquorix-Performance

Заметка от Миши с фороникса, про то, что не надо использовать васянские сборки ядра Linux, потому что получается плохо.

"On a geo mean basis across all of the benchmarks, the upstream kernel ended up being faster by 21%"

https://openbenchmarking.org/result/2412205-PTS-LIQUORIX70&sgm=1&swl=1 - вот тут вот особенно хорошо видно, что Liquorix иногда выигрывает на копеечку, но регулярно сливает в разы, на определенных нагрузках.

https://lwn.net/SubscriberLink/1002371/0ff2be6a2c7624ca/

"Process creation in io_uring"

Пишут про добавление clone() в #io_uring.

Я, даже не читая текст, закатил глаза, и подумал "#ebpf", потому что это очень разумно - загрузить через io_uring программу, которая сделает необходимый setup, и позовет clone()

(вообще, напомню в данном контексте свой текст от 21 года - https://www.tgoop.com/itpgchannel/56)

И, пожалуйста, первый же комментарий про это - https://lwn.net/Articles/1003051/

Но, в целом, этот текст (и дикуссия по ссылкам) не дает ответа на самый главный вопрос - а какая семантика у асинхронного clone()?

Тут же основная проблема - а что происходит, если clone() реально происходит хз когда, когда программа имеет неизвестное состояние блокировок/открытых fd/memory maps и так далее?

Синхронно-то сложно обеспечить нормальное окружение для clone(), а асинхронно - это какой-то леденящий душу пиздец!

Исследование производительности разных дистрибутивов Linux.

https://www.phoronix.com/review/intel-arrowlake-cachyos/5

Разница между самым быстрым, и самым медленным Linux - порядка 5%, разница между двумя лидерами CachyOS (основан на Arch), и Arch - порядка процента.

По мне так "овчинка выделки не стоит".

https://www.opennet.ru/opennews/art.shtml?num=62469

"Опубликован корректирующий релиз платформы совместной разработки Gogs 0.13.2, в котором устранено 6 уязвимостей. 5 уязвимостям присвоен критический уровень опасности (10 из 10). Исправленные проблемы позволяют непривилегированному пользователю Gogs выполнить код на сервере, изменить данные в репозиториях других пользователей или получить SSH-доступ к серверу"

Проект (git хостинг) написан на memory safe языке (нет, не на том, на другом), поэтому ошибки про обработку "../" в путях.

Мораль?

* Не надо поддерживать свою васянскую инфру (#gitlab #infra), а надо брать, и использовать github.

* По мере переписывания с С/C++ на memory safe языки, CVE меньше не будет, потому что безопасники тоже хотят кушать, просто искать их будут в других местах, возможно, поиск станет чуть дороже.

Пара перлов с opennet, от расто-любов/хейтеров:

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

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

"А вот будь оно на Си..."

Оказалось, у этой задачи есть вполне понятное решение (https://www.tgoop.com/itpgchannel/2543?comment=41578)!

"промоутим джуна в техлида, сами уебываем в стартап в ОАЭ, в американский визу не дают" (новый техлид тащит блокер, релиз, и себя)

Но зачем?

https://www.phoronix.com/news/Hash-Based-Integrity-Linux-RB

"Introduce a new mechanism to ensure only well-known modules are loaded by embedding a list of hashes of all modules built as part of the full kernel build into vmlinux"

Сначала героически создали себе проблему (модули), потом героически ее же и решаем.

Надо не хеши включать в ядро, а сами модули.

Я понимаю, какую задачу решали модули 30 лет назад (экономия памяти), а сейчас что? Сейчас все модули и так лежат в initrd, который целиком грузится в память (потом, наверное, очищается, но так можно сделать и в случае включения модулей в ядро).