Про acme.sh, эксплойты и костыли

Случайно наткнулся на
https://github.com/acmesh-official/acme.sh/issues/4659
(кстати, этот issue открыли ровно год назад 🎉)

История очень эпичная:
- какая-то китайская компания занимается перепродажей сертификатов и захотела сделать бесплатную автоматическую выдачу сертификатов через ACME, как Let's Encrypt
- но увы, сама компания не являются CA и не может выписывать сертификаты, поэтому полностью протокол ACME реализовать не может
- вместо этого китайцы используют RCE-эксплойт (оно же — удаленное выполнение произвольного кода) в acme.sh, который позволяет им вставить костыль в процесс выдачи сертификата. При этом они никакого вредоносного кода у клиентов не исполняют (скорее всего), но варварски эксплуатируют страшную дыру в безопасности
- клиентов, конечно же, просят юзать только acme.sh для выписывания сертификатов
- через некоторое время эта вся история с эксплойтом вскрывается, и появляется issue на гитхабе (ссылку на который я уже давал в самом начале поста)
- далее китайскую компанию, по всей видимости, жестко DDoS'ят (что можно узнать из комментов к issue)
- потом в issue приходит представитель этой самой компании и жалуется, что (далее прямая цитата, орфография сохранена)

we provides HiCA for non profit purpose, to provide ssl for free (RSA). We even donated 1000 USD to acme.sh last year to support the community developers, Except us any CA or reseller did this?

и сообщает, что

finally, we closed HiCA project and keep this before the community investigation finished.

- дыру с RCE, конечно же, в конце концов поправили

Мораль всей этой истории мне придумывать лень, оставлю это в качестве упражнения читателям 🐳 Могу лишь сказать, что использовать уязвимости для того, чтобы что-то закостылить или обойти — не самая удачная идея :)

#llvmweekly

http://msinilo.pl/blog2/post/compilers-are-too-smart/

Текст про то, что чувак дизассемблировал какую-то простую функцию, состоящую из какого-то довольно простого вызова в libc++, и охуел удивился увиденному.

Как выяснилось, авторы libc++ заложились на то, что clang проведет определенную оптимизацию вот такого блока кода:

inline _LIBCPP_HIDE_FROM_ABI size_t __constrain_hash(size_t __h, size_t __bc) {
  return !(__bc & (__bc - 1)) ? __h & (__bc - 1) : (__h < __bc ? __h : __h % __bc);
}

И заменит его на popcount (что не произошло в случае автора этого текста).

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

Ну вот нужен тебе popcount, проверь, что он есть, и позови напрямую, даже через какой-нить builtin/intrinsic, чтобы у людей опыт использования либы был более-менее консистентным.

UPD: меня вот тут поправляют, что я неверно все понял - https://xn--r1a.website/c/1469934025/27643

https://www.phoronix.com/review/intel-meteorlake-epp-perf

TL;DR - разработчики из Intel потюнили три константы в своем драйвере intel_pstate, что привело к ускорению вообще всего, суммарно процентов на 7, без ухудшения в потреблении энергии.

Интересно конечно, как выбирали начальные параметры.

Кстати, раз уж речь зашла про энергопотребление, то я какое-то время назад перешел на amd_pstate, c автоматической подстройкой (как это делается можно подсмотреть в https://wiki.archlinux.org/title/CPU_frequency_scaling), и всем советую попробовать сделать так же, потому что ноутбук живет дольше, греется меньше, да и вообще, умеет уходить в довольно низкие скорости CPU:

cpu MHz: 400.000

До этого был то ли acpi, то ли ccpc, (+ schedutil в качестве governor) и ниже 1200MHz они мой CPU не замедляли.

#scheduler

Расширяемый шедулер едет в ядро - https://www.phoronix.com/news/Linux-6.11-Extensible-Scheduler https://lwn.net/Articles/978007/
https://www.opennet.ru/opennews/art.shtml?num=61354

День, когда у меня перестанет тормозить браузер, все ближе и ближе, what a day to be alive!

Оказывается, swift умеет в статическую линковку, поверх musl - https://www.swift.org/documentation/articles/static-linux-getting-started.html

Pros of static linking:

No runtime overhead.
Only include code from libraries that is actually needed.
No need for separately installed dynamic libraries.
No versioning issues at runtime.

Cons of static linking:

Programs cannot share code (higher overall memory usage).
No way to update dependencies without rebuilding program.
Larger executables (though this can be offset by not having to install separate dynamic libraries).


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

США запрещают предоставление услуг в сфере программного обеспечения и IT любому лицу на территории России.

https://3dnews.ru/1106385/arm-potrebovala-unichtogit-vse-noutbuki-na-chipah-qualcomm-snapdragon-x
https://habr.com/ru/news/696198/ - история вопроса

Совершенно потрясная новость, одни жадные капиталисты наехали на других жадных капиталистов.

Разные комментаторы пишут разные мнения на этот счет.

Кто-то считает, что ARM в своем праве, потому что после покупки IP Qualcomm (у Nuvia) использует этот IP не в соответствии тем лицензиям, которые были даны при разработке этого IP, а кто-то - что у Qualcomm и так своя "жирная" лицензия есть, поэтому они в своем праве использовать этот IP так, как используют.

Я же просто запасся попкорном, и слежу за этой историей.

#wasi #wasm #webassembly #bootstrap

https://determinate.systems/posts/nix-wasm/

Вот, коллега очень верно пишет про "nix as a meta build system", для сборки кода в WASI. Но, как это часто бывает, начал он за здравие, а кончил тем, что собрал какое-то мелкое приложение на Rust, так и не продемонстрировав мощь метапакетной системы для сборки произвольного кода.

Ну потому что Rust и так умеет собирать в этот target, ничего нового не произошло.

А надо это продемонстрировать на каком-нибудь интересном примере, когда в rust приложение подмешивается что-то интересное, помимо экосистемы rust.

https://xn--r1a.website/itpgchannel/1330
https://xn--r1a.website/itpgchannel/1195

Даже мои эксперименты с wasm бывали более содержательны - https://xn--r1a.website/itpgchannel/1189

Или, например, вот - https://xn--r1a.website/itpgchannel/1553

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

#bootstrap, #rant

Вот, например, есть проект https://github.com/lm-sensors/lm-sensors

У него последняя версия - 3.6.0.

Со мной согласны arch, lfs, и так далее:

https://archlinux.org/packages/extra/x86_64/lm_sensors/

https://packages.gentoo.org/packages/sys-apps/lm-sensors (при этом gentoo верит repology, и говорит, что есть апдейт до 3.6.2)

В https://repology.org/tools/important_updates действительно приехал update до 3.6.2.

Несложный анализ показывает, что 3.6.2 есть ТОЛЬКО в openSUSE - https://repology.org/project/lm-sensors/versions

https://build.opensuse.org/package/show/openSUSE:Factory/sensors

Смотрите какая красота - https://build.opensuse.org/request/show/1142254

Даже changelog есть.

А вот места, откуда эти господа скачали не существующий в природе 3.6.2 - нет.

Это как?

На самом деле, они берут какой-то васянский форк - https://github.com/hramrach/lm-sensors

Что, зачем, почему? А это точно не https://en.wikipedia.org/wiki/Supply_chain_attack

Тут, конечно, вспоминается история про Гришу - https://xn--r1a.website/itpgchannel/1221

Класс программирования, 1985 год, Москва

Retired engineer discovers 55-year-old bug in Lunar Lander computer game code | Ars Technica
https://arstechnica.com/gaming/2024/06/retired-engineer-discovers-55-year-old-bug-in-lunar-lander-computer-game-code/

Мы?

https://servernews.ru/1099765
https://servernews.ru/1081397

Совершенно неожиданная новость, которую я пропустил.

Оказывается, в 21 году Google установили срок жизни своих серверов в 4 года, вместо 3, как было очень долгое время до этого, а в 23 году так и вообще до 6 лет.

Интересно, что это - желание временно показать более хорошие финансовые результаты, или простая констотация того факта, что железо стало развиваться медленнее, и, тем самым, не устаревать морально дольше?