В РФ сейчас достаточно популярна тема со SBOM и вообще контролем зависимостей, потому что много каких зависимостей из open source оказывали и могут оказать деструктивное влияние так сказатб 🌝

Но тут случилось ВНЕЗАПНОЕ1!11!. Hunted Labs озаботились зависимостями, которые тянутся в проекты и обнаружили российский след (полный PDF-отчёт скину в комменты). Более того, как они пишут, отказаться от этой зависимости сложно. Речь о easyjson (https://github.com/mailru/easyjson)

What is easyjson?

Easyjson is a Go package designed to optimize JSON serialization and deserialization processes by generating Go code for JSON encoding and decoding. Widely adopted across cloud-native ecosystems, it is a critical dependency for numerous open source and enterprise projects. This includes high-performance JSON handling in distributed systems, real-time data serialization for financial and analytics platforms, and optimization of cloud-native applications.

Who maintains easyjson?

A group of developers from VK, an entity with leadership that is under active U.S. and E.U. sanctions and has connections to Russian security services.

Who is impacted?

Cornerstones of the modern software supply chain and cloud-native tools have dependencies on easyjson, and all applications that pull in these dependencies could potentially be impacted, including, but not limited to:

- Helm
- Istio
- Kubernetes

How could this be weaponized or exploited?

Russia doesn’t need to attack directly. By influencing state-sponsored hackers to embed a seemingly innocuous OSS project deep in the American tech stack, they can wait, watch, and pull strings when it counts.

The Russian Open Source Project That We Can’t Live Without
https://huntedlabs.com/the-russian-open-source-project-that-we-cant-live-without/

По ссылке подробно расписано как и зачем они занимались исследованием зависимостей и к чему пришли

Hunted Labs has provided exhaustive evidence regarding this advisory to the U.S. government and relevant stakeholders. So, what’s next? 

The widespread use of easyjson makes finding a solution challenging. However, we cannot continue to blindly rely on this package due to the state of the current threats to our increasingly fragile software supply chain.

Мне понравилась заключительная фраза в статье

> Oh, and we haven’t even talked about China…yet.

Сколько же их ещё открытий ждёт 🌝

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

Я эту проблему (бинари в поставке ventoy) обнаружил в процессе https://www.tgoop.com/itpgchannel/2357, потому что они у меня не загружались, так как слинкованы с glibc, я тогда их все вынес, и заменил на свои сборки.

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

"Подход к обработке ошибок в Nimony претерпел значительные изменения. Автор Nim выражает неудовлетворённость традиционными механизмами исключений и их эмуляцией через алгебраические типы данных (sum types). Вместо этого предлагается концепция интеграции состояния ошибки непосредственно в сам объект данных. В качестве примеров приводятся: представление ошибки в потоках ввода-вывода через специальное состояние, использование NaN для чисел с плавающей запятой, или low(int) для невалидных целочисленных значений. В случаях, когда объект не может инкапсулировать состояние ошибки, предлагается использовать потоко-локальную (thread-local) переменную для сигнализации"

Эх, забавный был язык, я даже хотел написать на нем пару программок для #stal/IX, но его автор, очевидным образом, сошел с ума - говорит, в каждом типе данных должен быть особый sentinel.

Это уже не говоря про то, что он хочет уметь расширять синтаксис загружаемыми #plugins!

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

TL;DR - китайский брат (deepin), в обход RPM, качает себе нужные файлики из интернет, и использует их в обход политики SUSE по безопасности.

"Правила openSUSE предписывают сопровождающим устанавливать файлы конфигурации сервисов D-Bus и политики Polkit только после проверки их безопасности участниками SUSE Security Team и помещения в белый список допустимых компонентов. Часть подобных компонентов Deepin прошла проверку и была включена в штатные пакеты, но некоторые компоненты были возвращены на доработку из-за выявленных проблем с безопасностью. Проблемы не были устранены должным образом и желаемые компоненты не получили одобрение на включение. Вместо устранения замечаний сопровождающий Deepin продвинул проблемные компоненты обходным путём"

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

Deepin - прямой конкурент KDE, и непонятно, чего тут больше, политики (SUSE - главный спонсор KDE), или реальной заботы о пользователях.

Никогда #stal/#IX не был так свеж!

Introducing VibeCon — the world’s largest vibe coding conference.

Make sure you register today: http://127.0.0.1:8080/register

речь, конечно, про с++1917

Most AI spending driven by FOMO, not ROI, CEOs tell IBM
Article, Comments

Я, когда читал код #mesa, у меня обычно из глаз шла кровь.

Вдруг, внезапно, за столько лет ее чтения, я понял, почему:

https://docs.mesa3d.org/codingstyle.html

"Basic formatting guidelines
* 3-space indentation, no tabs"

Это какой-то зашкаливающий уровень пиздеца, что просто нет слов.

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

TL;DR - скорее бы на "almost memory safe" написали норм ssh клиент, вот реальной пользы-то было.

https://www.tomshardware.com/pc-components/gpus/u-s-inks-bill-to-force-geo-tracking-tech-for-gpus-and-servers-high-end-gaming-gpus-also-subject-to-tracking

U.S. inks bill to force geo-tracking tech for high-end gaming and AI GPUs

Senator Tom Cotton's legislation seeks to "prevent advanced American chips from falling into the hands of adversaries like Communist China"

Мне вот интересно, оно без интернета (то есть, без регулярного получения от сервера разрешения на продолжение работы) будет работать? Если да - то кто мне мешает положить карточку в клетку Фарадея, или в коробочку из фольги?

(предложка)

#llvmweekly

https://discourse.llvm.org/t/rfc-intra-procedural-lifetime-analysis-in-clang/86291

"This analysis draws inspiration from Rust’s Polonius borrow checker. While adapted for C++'s semantics (e.g., handling opaque calls, no enforced exclusivity, configurable strictness), its internal model still uses concepts like Loans and Origins which are analogous to formulation of lifetime in Rust’s Polonius.

This notion of a Origin/Loans serves a role closely related to the lifewww.tgoop.com/origin tracking in Polonius, providing a conceptual bridge. This proposal develops the necessary CFG-based dataflow infrastructure that could also support more explicit, Rust-style lifetime systems if they were introduced to Clang"

TL;DR - в clang уже есть [[clang::lifetimebound]], его предлагается расширять так, чтобы он мог работать между вызовами функций, используя идеи из Rust borrow checker.

КМК, это хороший путь для С++ - постепенно учиться проверять время жизни объектов все в большем и большем числе случаев, с разметкой времен жизни там, где это необходимо (а может, потом, и всегда).

Это вам не сраные профили безопастности от Страуструпа (https://www.tgoop.com/itpgchannel/2763), ага.

#llvmweekly #cplpl_doomed

https://discourse.llvm.org/t/factoid-each-class-template-instantiation-costs-1kib/86189

TL;DR - каждый раз, когда вы инстанциируете шаблон, в мире умирает котик, вы тратите 1K памяти, и это очень много, потому что header only библиотеки:

"Maybe what this all points to is that header-only library evolution is a dead end when it comes to compile time, and that if you want to have fast compiles, the old ways, i.e. forward declarations, pimpl patterns, and other forms of implementation hiding, are still relevant if you care about compile time, even in a modular world"

Очень пересекается с цитатой из https://www.tgoop.com/itpgchannel/22, 100500 раз писал, и буду продолжать писать, что избыточная мономорфизация/inline - зло, не надо бояться virtual method call, pimpl, и вот это вот все.

И это коллега пишет только про время и потребление ресурсов компилятором, и не упоминает того, что избыточно встроенный код еще и медленнее может быть, потому что плохо использует кеши процессора (например, https://www.tgoop.com/itpgchannel/1547).

UPD: про pimpl вот еще ссылка - https://github.com/llvm/llvm-project/commit/bb1765179e1f, пример того, как сам LLVM у себя выпиливает излишнюю мономорфизацию.

(сорян, у меня много #llvmweekly, я их с месяц не читал, там много накопилось интересного)

https://discourse.llvm.org/t/improving-the-reproducibility-of-linker-benchmarking/86057

"The idea is to use the Nix project to build the projects with a custom linker wrapper that collects the reproducers. Nix builds are (at least theoretically) reproducible and all projects are built in a fairly uniform way which makes it fairly easy to inject the linker wrapper into any project without knowing project-specific details. Nix also supports cross compilation so the same machine can be used to build reproducers for all architectures (but there are some bugs which mean that at the moment not all projects can be cross compiled and not all projects end up using the linker wrapper). And we can upgrade project versions by using a new version of Nixpkgs (Nix’s “ports tree”)"

TL;DR - давайте возьмем reproducible Nix + наш враппер над LLD, чтобы уметь собирать статистику по временам работы LLD при сборке произвольно большого набора OSS проектов.

Очень, очень, хорошая и плодотворная идея.

#llvmweekly

https://github.com/llvm/llvm-project/commit/d68c732473a1

"flang/lib/Parser/Fortran-parsers.cpp:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:47.31 -> 0:41.68
Maximum resident set size (kbytes): 2062140 -> 1745584

flang/lib/Lower/Bridge.cpp:
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:19.16 -> 0:45.86
Maximum resident set size (kbytes): 3849144 -> 2443476

flang/lib/Lower/PFTBuilder.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:29.24 -> 1:00.99
Maximum resident set size (kbytes): 4218368 -> 2923128

flang/lib/Lower/Allocatable.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:53.03 -> 0:22.50
Maximum resident set size (kbytes): 3092840 -> 2116908

flang/lib/Semantics/Semantics.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:18.75 -> 1:00.20
Maximum resident set size (kbytes): 3527744 -> 2545308"

TL;DR - прямо ооочень значимое сокращение времен сборки flang, с использованием precompiled headers, даже неожиданно. Правда, это тщательно выбранные файлы, не общее время, но, тем не менее.

#llvmweekly (Остапа понесло, ага)

https://github.com/llvm/llvm-project/commit/d1fd97737e90

А вот если кому-то интересно, как запилить поддержку санитайзера под пока неподдерживаемую OS.

В целом, копируешь куски реализации из Linux, + немного #protaskivanie по обертке релеватных системных вызовов, + код для определения раскладки замапленых участков памяти процессом.

Муторно, но не очень сложно.

И взгляд с другой стороны - https://keithp.com/blogs/sanitizer-fun/, как поддержать неизвестную libc в санитайзерах, и с чем пришлось столкнуться.