Ну не прошло и двух лет, как коллеги озаботились проблемой воспроизводимости сборки Python - https://sethmlarson.dev/security-developer-in-residence-weekly-report-13

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

Я уже как-то писал (https://xn--r1a.website/itpgchannel/776), и напишу еще раз - при всех прочих равных я стараюсь брать автоматически сгенеренный tgz из системы контроля версий (ну или напрямую git clone), нежели чем tar.xz, "сваренный" каким-то человеком из хрен знает каких исходников. Большое поле для злоупотреблений, или для человеческих ошибок.

#maskray, #llvmweekly

Очередной зажигательный текст от нашего коллеги - https://reviews.llvm.org/rG904b3f66f59e

TL;DR - новая эвристика в алгоритме, который пытается наиболее оптимальным образом (видимо, с точки зрения заданного perf/call graph) распределить код функций по бинарнику.

Говорят, более хорошо учли instruction cache, и все такое.

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

Наверное, можно примерно себе представить самый тупой алгоритм, который попробует все возможные взаиморасположения функций, посчитает для каждого такого расположения теоретический perf (с точки зрения кеша инструкций), например, запустив монтекарлу (вероятности перехода между функциями мы знаем из call graph, вроде, больше ничего и не нужно).

Ну а как сделать что-то такое "быстро", с ходу совсем не очевидно.

Пишут, что ажно +1% перфа, по сравнению с предыдущим алгоритмом.

Забавная статья, под названием "Is Guix full-source bootstrap a lie?"

https://simon.tournier.info/posts/2023-10-01-bootstrapping.html

Наши постоянные слушатели помнят, что мне очень интересна эта тема (#bootstrap) - "как из ничего получить что-то", и я уже пару раз писал про то, как Guix трепетно относится к этой задаче (Nix - в целом, наплевательски, они больше запариваются по воспроизводимости (что похоже, но не совсем то же самое), ну а мой #ix - где-то посредине)

Поэтому, конечно, я не смог пройти мимо этого текста, потирая свои потные ручонки в предвкушении жареного!

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

No, it is not a lie! Guix blog post told me: « today, you get a package graph of more than 22,000 nodes rooted in a 357-byte program »

В целом, довольно вторичный текст, по сравнению с тем, что я уже кидал на тему, но вот пара интересных цифр там есть:

Summarizing what we get
In all that story, which binary do we have to trust?

First, we must trust bootstrap-seeds. That’s nice because it is small enough for auditing the binary seeds. That’s already very excellent!

That’s said, although the package graph is rooted in bootstrap-seeds, second we also must trust the driver. It means: 1.3MiB for tar, 1.3MiB for bash, 0.7MiB for mkdir and 0.844MiB for xz. Last, 14MiB for uncompressed static Guile binary. Result, it is a bit less that 20MiB.

Что тут написано? Что, "на самом деле", часть цепочки от 300 байт на ассемблере до 20 мегабайт бинарей, с которыми собирается вся остальная система, есть участок, который был пройден руками, и авторы guix про него "мамой клянутся", что там все честно.

20мб - это уже очень хороший результат, лучше сделать довольно сложно.

https://daniel.haxx.se/blog/2023/10/11/how-i-made-a-heap-overflow-in-curl/

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

Последние несколько дней интернеты бурлили на новостях от автора curl, что, там, мол, самая страшная ошибка в curl за долгое время, готовьтесь - https://www.phoronix.com/news/Curl-8.4-Coming.

Вот вышел фикс для ошибки, с подробным описанием, что там и как.

Не знаю, по мне, так больше разговоров было. Наверное, автор просто привлекал к себе (и к проекту) внимание.

Забавно, как коллега подстелил себе соломку, сразу предупредив школоту, что не надо им лезть со своим Rust во все дыры в калашный ряд в проект:

Rewrite it?
Yes, this family of flaws would have been impossible if curl had been written in a memory-safe language instead of C, but porting curl to another language is not on the agenda. I am sure the news about this vulnerability will trigger a new flood of questions about and calls for that and I can sigh, roll my eyes and try to answer this again.

The only approach in that direction I consider viable and sensible is to:

allow, use and support more dependencies written in memory-safe languages and
potentially and gradually replace parts of curl piecemeal, like with the introduction of hyper.
Such development is however currently happening in a near glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.

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

"Опубликованы результаты независимого аудита безопасности открытого кэширующего прокси-сервера Squid, проведённого в 2021 году. В ходе проверки кодовой базы проекта выявлено 55 уязвимостей, из которых в настоящее время 35 проблем пока не исправлены разработчиками (0-day). Разработчики Squid были уведомлены о проблемах ещё два с половиной года назад, но так и не завершили работу по их устранению. В конечном счёте автор аудита решил раскрыть информацию не дожидаясь исправления всех проблем и предварительно уведомил об этом разработчиков Squid"

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

"X.org имеет исторические проблемы с безопасностью, например десять лет назад, на 30-й конференции Chaos Communication Congress (CCC) в докладе исследователя безопасности Ильи ван Шпрунделя (Ilja van Sprundel) половина презентации была посвящена проблемам в сервере X.Org, а другая половина безопасности клиентских библиотек X11. В докладе Ильи, который в 2013 году выявил 30 уязвимостей, затрагивающих различные клиентские библиотеки X11, а также DRI-компоненты Mesa, присутствовали такие эмоциональные высказывания, как "GLX - это ужасный демотиватор! 80 000 строк сплошного ужаса!" и "За последние пару месяцев я нашёл в нем 120 ошибок, и я ещё не закончил проверку"

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

Программисты на С могут сколько угодно говорить, что, "если писать аккуратно, то не будет проездов и утечек". Кроме того, что это явная логическая уловка https://en.wikipedia.org/wiki/No_true_Scotsman (у тех, у кого проезды и утечки - просто не true С программисты, ага), так это еще и неправда.

Чтобы не было проездов и утечек, нужна не аккуратность, а нормальная система типов. В С++ она уже почти нормальная (если не пользоваться наследием C, а пользоваться векторами), в Rust еще более почти нормальная.

Скорее бы весь опасный код переписали с С, вот как Google - https://www.opennet.ru/opennews/art.shtml?num=59900

Про вандализм в инсталляторе Ubuntu уже написали все, поэтому я писать не буду, а просто дам ссылку на годное (разве что, букв Z там чуть больше, чем нужно) описание - https://xn--r1a.website/leaveitru/469

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

https://gaultier.github.io/blog/wayland_from_scratch.html

А вот, кстати, хороший текст про то, как написать #wayland клиент с 0.

Без использования libwayland, без использования всратого xml codegen, а вот так вот - открыть сокет, записать такие-то байты, так-то распарсить результат. Фрейминг, содержание каждого пакета, устройство event loop - все объясняется "на пальцах".

Короче, если хочется разобраться "как оно работает внутри", а не в изысках, которые нахуевертили вокруг этой простой модели - must read.

Жалко, что там нет самой "мякотки" - инициализации drm context, для 3D ускорения, но это было бы сложновато для такой короткой статьи.

#sfc #gpl #Vizio

https://writing.kemitchell.com/2023/10/13/Wrong-About-GPLs

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

Вообще, конечно, это все совершенно прекрасно, когда на сайтах ты пишешь одно, а в суде заявляешь вот такое:

"This is not in the contract. This is on a website. And it’s, again, rather fanciful to imagine that every party to the GPLs is going to the website, looking at a list of 200-plus FAQs, and fixating on the one that concerns enforcement, means of enforcement, in the event of a breach"

С другой стороны, FSF тоже можно понять, потому что идея, и механизм ее реализации - это очень разные вещи.

Ну вот хочется, чтобы было "красиво", но, чтобы работало в каком-то конкретном законодательстве, нужно, чтобы было "ужасно, но единообразно".

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

Кластер PG (хехе), V2.0
Все машинки в моем ДЦ работают на #stal/IX, а как иначе!

Я, кстати, когда собирал DirectXShaderCompiler, подумал про одну штуку, а вот написать про нее - не написал.

Я почему-то всегда считал, что clang/llvm - это "второй среди равных" компиляторов. Так как я с clang практически с самого его рождения, то привык считать, что он всегда находится в догоняющих, по отношению к gcc, позициях.

Поэтому, когда я затеял собирать #ix clang'ом, то думал, что я в "меньшинстве". Возможно, оно так и было, в 19 году.

Но так-то, если подумать, то сейчас clang - главный компилятор С++, потому что:

* В любом tooling его библиотеки. Собственно, dxsc тоже.
* *BSD собираются clang
* macos/ios собирается clang - а это, на минуточку, один из самых популярных сторов приложений!
* С недавних (ну, как недавних, так-то уже дофига времени прошло) пор android (даже ядро для него!) собирается кленгом, и, полагаю, нативные приложения (которые без jvm) в сторах - тоже.
* Непустое количество дистрибутивов Linux, собираемых clang. И не только мой #stal/IX, а та же Open Mandriva.
* Самые популярные программы на любом компьютере (браузеры) собираются clang (chrome, webkit, и все производные). Vscode? Electron?

Удел gcc сейчас - это серверные дистрибутивы в датацентрах, и, так-то, это довольно узкая область, да хотя бы по числу инсталляций! Но и в них без llvm никуда, потому что llvm широко используется во всякого рода компиляторах шейдеров (#mesa).

Ну и получается, что случайное приложение, которое ты используешь, собрано clang, а не gcc.

Такие дела.

https://rachelbythebay.com/w/2023/10/16/env/

getaddrinfo() из glibc зовет getenv(). Ну зовет и зовет, и не такое бывает.

Мне вот помнится boost condvar timed wait, который иногда начинал шуршать диском, потому что там внутре была заиспользована какая-то "не такая" функция работы с временем, и она пыталась читать локаль с диска.

(если у кого-то есть про это ссылка, поделитесь, потому что, с ходу, я не нашел)

https://www.phoronix.com/news/GNOME-Foundation-New-Director

Новый исполнительный директор у GNOME foundation.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1415943-gnome-foundation-names-a-new-executive-director?p=1415977#post1415977

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

name is Holly Million, and I am a professional shaman, an artist, an herbal medicine maker, and a micro-homesteader.​

Eight years ago, I realized the best word to describe me must be “shaman.”​
​​​​​​
I do energy healing work on behalf of individuals, land, houses, and businesses. I can do this work remotely because everything is connected. We live in a quantum universe. My clients for personal and land clearing are located all over the country.

Как пишет другой коллега:

"The perfect person to shaman in the miracle required to make GNOME a good DE"

https://nibblestew.blogspot.com/2023/10/the-road-to-hell-is-paved-with-good.html

Странный текст про модули в С++, от автора #meson.

Я ожидал чего-то горячего, но весь текст, в основном, про то, какие gcc/clang негодяи, как им нужно правильно парсить command line, и как разбирать файлы.

Я бы сказал, что у автора зашкалило ЧСВ, и он, на голубом глазу, рассказывает, как clang/gcc должны выстраивать интерфейсы, чтобы их удобно можно было звать в #ninja.

Ну или он просто не видит дальше своего носа, и не понимает, что модель парсинга зависимостей у meson/ninja - ущербна (*), и что не надо ей потакать.

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

https://github.com/rui314/mold/releases/tag/v2.3.0

Вышел новый #mold.

Вполне обычный релиз, в changelog глаз зацепился за

"mold 2.3.0 has introduced an experimental flag, -z rewrite-endbr, which rewrites superfluous endbr64 instructions as nop"

Полез смотреть, что это за инструкция, https://stackoverflow.com/questions/56905811/what-does-the-endbr64-instruction-actually-do - вполне норм описание, с выдержками из арх. мануалов, и все такое.

Прикольная штука, насколько я понимаю, она делает #ROP почти obsolete.

А вы знали? Я не знал!

Как мы себе это представляем:

https://ru.wikipedia.org/wiki/%D0%9F%D0%BB%D0%B0%D0%BC%D1%8F_%D0%BD%D0%B0%D0%B4_%D0%B1%D0%B5%D0%B7%D0%B4%D0%BD%D0%BE%D0%B9

"Все внимание новорожденного повернулось к уходящим кораблям. Микробы, вдруг оказавшиеся болезнетворными. Как могло это случиться? Вдруг ускорились миллионы планов. Расцвет обычным порядком более не рассматривался, следовательно, отпала нужда в людях, оставшихся в Лаборатории.

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

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

Как это происходит на самом деле:

https://github.com/OpenBMB/XAgent#-xagent-1

....
Safety: XAgent is designed to run safely. All actions are constrained inside a docker container. Run it anyway!
....

https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98

MR в #GNOME, насколько я понимаю, он убирает возможность выбора X11 сессии в login manager.

Ну и хорошо.

Wayland, конечно, местами, слишком анально огорожен, на каждый чих нужен протокол, и чтобы его поддержали основные вендоры, но X11 - это тихий ужас.

Если вы запустили X сессию от рута/#suid (раньше точно нельзя было иначе), то вы, считай, подарили свой компьютер кому угодно. Потому что проезды в коде X11 перестали находить не потому, что они там кончились, а просто никто, в здравом уме, не хочет читать ЭТО.

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

Взлом jabber.ru, с перехватом трафика, в течение длительного периода времени.

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

С одной стороны, новость "вкусная", с другой - ну взломали и взломали, mitm, при условии контроля над инфраструктурой, дело не очень хитрое - "Первый поддельный TLS-сертификат был получен 18 апреля 2023 года через сервис Let’s Encrypt, в котором атакующий, имея возможность перехватить трафик, смог подтвердить доступ к сайтам jabber.ru и xmpp.ru".

Мораль?

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

А если вам нужна настоящая приватность - то, получается, нельзя доверять никаким third party, только обмен ключами на бумажке, при личной встрече.