Вторым участником сегодняшнего ностальгически конференцевого дня является Big Monitoring Meetup 13

Проходить он будет 20 ноября в Москве (БЦ “Калибр”, ул. Годовикова, дом 9, стр. 17), мероприятие бесплатное

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

Тоже поностальгируем 🌝

На BMM 4 я познакомился лично с Александром Валялкиным (@valyala) и мы потом в баре продолжительное время обсуждали относительно недавно появившуюся в open source, на тот момент, Victoria Metrics

Open-sourcing VictoriaMetrics
https://web.archive.org/web/20190702092906/https://blog.usejournal.com/open-sourcing-victoriametrics-f31e34485c2b

Вот Сашин доклад из 2019 года
Сравнение Thanos и VictoriaMetrics (Александр Валялкин, VictoriaMetrics)
https://www.youtube.com/watch?v=HyOXAdQE0Pk

А на BMM 5, точнее тоже после него, с Александром Зобниным из Grafana говорили о только-только релизнувшейся Grafana 8.
Релиз состоялся 8 июня 2021 года, а митап был 10 июня.

Ссылка на доклад из 2021
Что нового в Grafana 8 (Александр Зобнин, Grafana)
https://www.youtube.com/watch?v=xV3MATgtSWI

Для нынешнего BMM программа уже сформирована и среди докладчиков будут

- Максим Емельянов, Дмитрий Стюков "Дорожная карта внедрения SRE-практик в большой компании"

- Кирилл Борисов, "Эволюция культуры инцидент-менеджмента: от реактивного реагирования к проактивной инженерии надежности"

- Волотов Михаил, "DR большого кластера Zabbix — как сделать и с чем вы столкнетесь"

Сайт с программой и регистрацией - https://monhouse.tech/big-monitoring-meetup13/
Следить за обновлениями можно на канале - @monhousetech

В 2023 году Microsoft открыл проект CHERIoT (Capability Hardware Extension to RISC-V for Internet of Things), который направлен на то что бы улучшить безопасность уже существующих проектов на C и C++.

First steps in CHERIoT Security Research
https://www.microsoft.com/en-us/msrc/blog/2023/02/first-steps-in-cheriot-security-research/

И вот наконец-то он дорос до версии 1.0

Программно-аппаратная платформа CHERIoT 1.0 для повышения безопасности кода на языке Си
https://www.opennet.ru/opennews/art.shtml?num=64180

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

> Аппаратные компоненты CHERIoT оформлены в виде микроконтроллера на базе архитектуры RISC-V, реализующего защищённую процессорную архитектуру CHERI (Capability Hardware Extension to RISC-V) c моделью управляемого доступа к памяти на основе "capability" (каждая операция чтения и записи в память авторизуется). На базе предоставляемой в CHERIoT архитектуры набора команд (ISA) построена программная модель, гарантирующая безопасность работы с памятью на уровне отдельных объектов, предоставляющая защиту от обращения к уже освобождённой памяти и реализующая легковесную систему изоляции доступа к памяти.

> Указанная программная модель защиты напрямую отражается в языковую модель C/C++, что позволяет применять её для существующих приложений, для защиты которых требуется лишь перекомпиляция и запуск на оборудовании, поддерживающем ISA CHERIoT.

> Среди проблем, блокируемых при помощи CHERIoT:

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

Спецификация и эталонная формальная модель CHERIoT ISA
CHERIoT Specification and Sail model
https://github.com/CHERIoT-Platform/cheriot-sail/

Эталонная реализация 32-разрядного RISC-V CPU Ibex c поддержкой ISA CHERIoT, схемы прототипа CPU и описания аппаратных блоков на языке Verilog
cheriot-ibex is a RTL implementation of CHERIoT ISA based on LowRISC's Ibex core
https://github.com/microsoft/cheriot-ibex

На базе ядра CHERIoT Ibex готовятся к массовому производству чипы ICENI, поступление в продажу которых запланировано на следующий год

Модифицированный LLVM
Fork of LLVM adding CHERIoT, based on the CHERI LLVM fork
https://github.com/CHERIoT-Platform/llvm-project

Отдельно компанией Microsoft развивается микроконтроллер Kudu с поддержкой ISA CHERIoT
cheriot-kudu is a 32-bit dual-issue RISC-V MCU core with CHERIoT support
https://github.com/microsoft/cheriot-kudu

Эмулятор платформы на базе FPGA
https://github.com/microsoft/cheriot-safe

Docker-контейнер для разработчиков
https://github.com/CHERIoT-Platform/devcontainer
https://github.com/orgs/CHERIoT-Platform/packages/container/package/devcontainer

Прототип операционной системы реального времени
The RTOS components for the CHERIoT research platform
https://github.com/CHERIoT-Platform/cheriot-rtos

ЗЫ "Опёнок" не меняется 🌝

Google выпустила экстренное предупреждение о критической уязвимости в Android, которая позволяет атакующим выполнять произвольный код на устройстве без какого-либо участия пользователя. Zero Click-уязвимость обнаружена в системных компонентах операционной системы и описана в ноябрьском бюллетене безопасности Android за 2025 год.

Уязвимость получила идентификатор CVE-2025-48593 и признана одной из наиболее опасных за последнее время. Она затрагивает несколько версий Android Open Source Project (AOSP) — с 13-й по 16-ю, и может быть использована для удалённого выполнения кода (RCE) без необходимости предоставления дополнительных прав или действий со стороны владельца устройства.

По оценке Google, злоумышленники способны эксплуатировать ошибку, отправляя специально сформированные сетевые пакеты либо распространяя вредоносные приложения через сторонние магазины и sideload-установки. Успешная атака открывает полный доступ к устройству, включая возможность кражи данных, установки вымогательского ПО или превращения смартфона в элемент ботнета. Проблема зарегистрирована внутри компании под номером Android bug ID A-374746961 и уже устранена в последних сборках AOSP.

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

Всё, что вы делали на Android, больше не секрет: Google подтвердила RCE, открывающую полный доступ без единого клика
https://www.securitylab.ru/news/565701.php

Ссылка на бюллетень
https://source.android.com/docs/security/bulletin/2025-11-01

ЗЫ

Заголовок статьи у SecurityLab, конечно, моё почтение

ЗЫЫ

🌝

https://xn--r1a.website/tech_b0lt_Genona/5442
https://xn--r1a.website/tech_b0lt_Genona/5815

Вот это поворот! n8n запартнёрился с SAP

We’re happy to share that n8n is partnering with SAP.

Through this collaboration, we aim to extend the agentic capabilities of Joule and Joule Studio on the SAP Business Technology Platform (BTP) using n8n’s AI orchestration and automation capabilities.

Our goal is to bring these technologies together so teams can build governed, observable AI agents that integrate seamlessly with enterprise systems and data.

Looking forward to what we can build together. More to come as we continue working on this partnership.

https://x.com/n8n_io/status/1986035791433207885

Давным-давно, when the hills were still young, каждая торговая компания (ТЗК) имела свой отдел программистов, бизнес-приложения были database driven, т.е. вся бизнес-логика жила внутри СУБД (Oracle, DB2) в виде хранимых процедур, а клиенты писались на чем попало (perl, например).
Это приводило к тому, что весь бизнес какого-нибудь Walmart держался на одном очень дорогом компьютере и на одном очень дорогом программисте СУБД (DBD) и естественно это никого не устраивало.

В какой-то момент, фронтенд компьютеры начали стремительно дешеветь, в то время как компьютеры под БД в цене не падали, и возникла идея перенести часть логики на фронтенд.

В этой парадигме Sun представил миру EJB (1998 год) а в 2001 году был опубликован Agile манифест. Параллельно, с 1986 года по миру бродил Scrum — это методологический framework для управления проектами, суть которого в разбиении большого проекта на небольшие атомарные части. И в том же 2001 году Scrum натянули на Agile - т.к. они хорошо подходили друг другу: Agile как набор процессов (process framework) и Scrum как метод реализации процессов.

Основная беда Agile - растущий технический долг, т.к. “Responding to change over following a plan” на практике означает, что на глубокое планирование или рефакторинг существующего кода не выделяется ресурсов.

Так, мы как-то проводили аудит on-line кредитования для одного банка. Изначально предполагалось, что человек загружает пакет документов, и через несколько минут получает автоматический ответ. После нескольких месяцев работы бизнес решил увеличить время ответа до суток и оказалось, что за это время паспорт успевает просрочиться и нужно реализовать версионирование документов. Но на конвертацию уже накопленных данных, денег, естественно, не выделили. Так в системе появился второй, независимый от первого, менеджер документов. За два года таких менеджеров образовалось шесть, со сложным механизмом передачи клиента от одного другому.

Розничный бизнес готов платить эту цену за гибкость и уменьшение стоимости разработки. Если у вас есть “домашний” софт, который вы можете релизить когда захотите и у вас есть домашняя команда разработчиков, готовая откликаться на задачи бизнеса и переделывать все от Адама раз в две недели, то в этой среде Agile по сей день чувствует себя прекрасно.

Но как это бывает со всеми модными идеями, Agile стали пихать куда ни попадя – в автопром, разработку процессоров, софт для управления электростанциями и так далее. В 2011 году появился SAFe, который позволяет вам сделать из классического waterfall псевдо-agile, запихав Scrum внутрь каждой итерации (program increment), стоит это 20% проекта т.к. каждый 5 спринт объявляется техническим.

Ничего хорошего из этого вполне ожидаемо не выходит – сколько-нибудь сложный архитектурно софт или забывает про agile оставляя только внешнюю часть scrum ритуалов или срывает все планы по срокам и качеству

#blog

Коллега нашла редкий интересный вариант ошибки, связанной с макросом. Интересен баг тем, что изначально глядя на код (не прочитав тестовое описание), я не смог его заметить! Хотя глаз у меня натренирован. Более того, мне пришлось дважды прочитать предупреждение анализатора, приведённое в статье, прежде чем я наконец увидел, что же не так.

Красивое. Люблю такие ошибки, которые показывают как статический анализ является незаменимой парой глаз на обзорах кода. Если хотите, можете попробовать в начале сами поискать ошибку в функции tcp_send_error.

Предупреждение PVS-Studio: V1040 Possible typo in the spelling of a pre-defined macro name. The '__WIN_32__' macro is similar to '__WIN32__'. inet_drv.c 13506

Опечатка. Лишнее подчёркивание в имени макроса. Подробнее про эту и другие интересные ошибки можно прочитать в статье "Наследие кода: разбор С и С++ модулей Erlang, которые работают десятилетиями".

Это вам не CoC

Usage Manifesto

The bincode developers do not endorse or support: the gas and oil industry, gambling, the military industrial complex, or any usage of AI. This means we will not accept any contributions coming from or related to these fields. This includes both PRs and filed issues. If you fall in one of these categories; do better.

Additionally, if any contribution you make makes use of generative AI, be it in code or PR/issue descriptions, you will be immediately banned from this organization.

A compact encoder / decoder pair that uses a binary zero-fluff encoding scheme. The size of the encoded object will be the same or smaller than the size that the object takes up in memory in a running Rust program
https://sr.ht/~stygianentity/bincode/

Спасибо подписчику

Я надеюсь, что это шутка

> Yes that is normal. Recent Ubuntu versions are configured to kill a user session when the user uses over half the RAM. (If that‘s even what‘s happening, but it sounds like that should be it)

Ubuntu crashes when running cargo build without jobs limit
https://www.reddit.com/r/rust/comments/1oqaaac/ubuntu_crashes_when_running_cargo_build_without/

UPD:

Из комментариев

Пока пытался понять это шутку, которая не шутка, нашёл некоторые подробности :
1. Речь про psi а не объём, как можно подумать.
Psi показывает сколько времени система тратит впустую в ожидании освобождения ресурсов.
2. Эта штука хорошо работает в двух случаях - докеры/куберы вместе с прочими микросервисами и системы с несколькими пользователями. В первом случае можно просто грохнуть контейнер без особых проблем/degrade статусов и прочего. Он просто перезапустится на другой ноде. Во втором случае это уже подстраховка от того, чтобы oom (не systemd-oomd, а наш, классический) не убил критический процесс и не положил систему.
3. Основной задачей является защита от livelock. Это когда система намертво виснет минут на 10-30, что даже oom не запускается.
4. Никто в здравом уме не ставит это на десктоп или если в проде крутится древний монолит.
5. Всё можно подтюнить если надо. На серверах где важны все эти ваши high availability Systemd-oomd всё же лучше, чем если oom просто вырубит нужно-важное и девопсу нужно опять смотреть, что за алерт там прилетел

Протест японского сообщества Mozilla Support из-за навязывания машинного перевода
https://www.opennet.ru/opennews/art.shtml?num=64192

Масахико Иманака (Masahiko Imanaka), лидер японского сообщества SUMO (SUpport.Mozilla.Org), занимающегося поддержкой пользователей и написанием статей на сайте support.mozilla.org, объявил о прекращении деятельности в знак протеста против навязывания автоматизированной системы перевода "sumobot".

22 октября без учёта мнения сообщества данная система была задействована компанией Mozilla для автоматизированного перевода статей из базы знаний support.mozilla.org.В итоге, около 300 статей, написанных носителями японского языка, были заменены на машинный перевод англоязычных статей, качество которого не выдерживает критики.

В предложенном машинном переводе не учтены принятые правила перевода и не выполнена локализация с учётом специфики японских пользователей.

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

Прямой машинный перевод всех статей из архива был автоматически подтверждён для публикации без проведения рецензирования.

Также был введён процесс подтверждения ботом в течение 72 часов после обновления исходных статей, что мешает обучению новых участников.

Сообщество лишено возможности контролировать работу бота и влиять на совершаемые им действия. Введённые изменения восприняты как массовое уничтожение результатов многолетней работы сообщества и нарушение миссии Mozilla.

В связи с этим Масахико заявил о прекращении участия в поддержании support.mozilla.org и запрете использования своих ранее выполненных переводов для обучения AI-систем Mozilla

#filc

Прочитал историю коммитов в проект, https://github.com/pizlonator/fil-c/commits/deluge/, почитал код.

Коллеги, конечно, проделывают титаническую работу.

Им надо перехватывать все syscall, чтобы корректно размечать память, и они не придумали ничего лучше, как написать свой платформенный слой linux syscalls, и портировать на него ВЕСЬ код, который вызывает linux syscalls. Какой-то совершенно случайный коммит, добавляющий пару оберток над сисколлами для какой-то случайной либы - https://github.com/pizlonator/fil-c/commit/e9c68f14821a611ac93673e0e1678d61acd6bac5

Фактически, это порт на новую платформу, довольно приличного количества софта, в том числе, musl и glibc.

Патченое лежит вот тут - https://github.com/pizlonator/fil-c/tree/deluge/projects, список довольно внушительный, и выглядит, кстати, очень "монорепно".

Зацените, например, порт ruby на GC от fil-c - https://github.com/pizlonator/fil-c/tree/deluge/projects/ruby-3.3.10 (да, у них свой GC!)

Запатчить все это на голом энтузиазме можно пару раз, а потом им придется или нести это в upstream (искренней удачи им с этим), или как-то подойти к делу более системно (как - я не знаю, если что).

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

What I talk about when I talk about IRs
https://bernsteinbear.com/blog/irs/

A catalog of side effects
https://bernsteinbear.com/blog/compiler-effects/

Два интересных поста

Первый об IR (intermediate representation) в компиляторах и какие они бывают. В целом это некая база, в которойй рассказывается, например, про графа потока управления (CFG), SSA (static single assignment), SSI (static single information) и т.д.

Если вы ковырялись в этой теме, то скорей всего ничего нового не узнаете, но пост хорошо организован с показательными примерами и для менее искушённого читателя будет полезно. В конце есть полезные ссылки (реально по теме, я проверил 🌝).

Второй пост мне был более интересен, так как там рассказывается про эффекты в IR

В посте кратко рассматриваются

- Cinder (https://github.com/facebookincubator/cinder) - форк CPython, который ориентирован на производительность

- JavaScriptCore (https://docs.webkit.org/Deep%20Dive/JSC/JavaScriptCore.html) - это кусок WebKit (https://github.com/WebKit/webkit/tree/main/Source/JavaScriptCore)

> JavaScriptCore is an optimizing virtual machine. JavaScriptCore consists of the following building blocks: lexer, parser, start-up interpreter (LLInt), baseline JIT, a low-latency optimizing JIT (DFG), and a high-throughput optimizing JIT (FTL).

- Simple (https://github.com/SeaOfNodes/Simple) - Sea of Nodes появился, как академический проект диссертации Клиффа Клика (Cliff Click), потом IR поехал в HotSpot C2 и вообще сильно повлиял на отрасль в контексте IR и компиляторостроения.

> It became the core IR in the HotSpot C2 JIT compiler, and very quickly produces high quality code.
C2 and the Sea of Nodes is used today in nearly every JVM on the planet - and runs literally trillions of times daily. The IR inspired Google's V8 team (and thus is/has been in Chrome), the Graal compiler and other high profile compiler efforts.

Вот ссылка на его работу из 1995 года
Combining Analyses, Combining Optimizations
https://repository.rice.edu/server/api/core/bitstreams/c5ea1ab7-e6c6-41e7-8e06-3cd5b80aeccd/content

Сам Клифф достаточно популярная личность в узких кругах, ветеран этого вашего (нашего) IT, ведёт канал на YouTube и рассказывает всякое интересное

> All About Programming Language Implementations - compilers, JIT'ing, type theory, garbage collection, code-gen, concurrency, memory models, inline-caches, traits, mixins, and everything else in our modern programmed environment.

https://www.youtube.com/@compilers/

- HHVM (https://github.com/facebook/hhvm) - JIT-компилятор для языка Hack

- Android ART (https://source.android.com/docs/core/runtime) - Android RunTime

- .NET/CoreCLR (https://github.com/dotnet/runtime) - рантайм .NET

- V8 (https://github.com/v8/v8) - движок JavaScript

- Guile (https://www.gnu.org/software/guile/) - это имплементация Scheme. Наверное самое популярное его применение это дистрибутив Guix

Посмотреть серию докладов про него можно тут
https://xn--r1a.website/tech_b0lt_Genona/4494

> В Петербурге мужчина перевел мошенникам почти ₽32 млн. за то, чтобы вступить в наследство «богатого родственника из Западной Африки»

https://xn--r1a.website/fontankaspb/93223

Шёл 2025 год

Команда открытого проекта runc столкнулась с ростом pull-request и отчётов об ошибках, сгенерированных ИИ
https://habr.com/ru/news/964714/

Оригинальная issue
[rfc] LLM policy?
https://github.com/opencontainers/runc/issues/4990

Вероятно, пришло время принять решение о том, что мы должны и чего не должны принимать из-за активности ИИ, и задокументировать эти моменты, пояснил мейнтейнер команды проекта opencontainers (Open Container Initiative) Алекса Сарай (Aleksa Sarai).

По мнению разработчика:

- команда не должна принимать ничего, сгенерированного ИИ или им следует рассматривать сгенерированный ИИ код и issue отдельно;

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

- что еще важнее, при рассмотрении issue разработчики должны предполагать, что то, что написал пользователь, действительно произошло с ним, но в случае с проблемами, сгенерированными ИИ, — кто знает, действительно ли описание описывает что-то реальное? (cм. #4982 и #4972 в качестве возможных примеров сгенерированных ИИ отчётов об ошибках);

- что касается сгенерированного ИИ кода, минимальным требованием должно быть то, что отправитель должен быть в состоянии ответить на review request своими собственными словами.

По мнению Алекса Сарай использование LLM вполне допустимо для перевода с иностранного языка на английский, поиска и исправления грамматических ошибок и опечаток, автозаполнения тривиальных текстов и кода (например, if err != nil { return nil, err }).

Напомню о том, как автор cURL "сгорел" от генерённых ИИ сесурити репортов

https://xn--r1a.website/tech_b0lt_Genona/5314

В эту же сторону пост от Devansh Batham в котором он рассказывает, что AI Slop в виде отчётов об уязвимостях перегружает людей, которые их оценивают и пытаются понять где реальные проблемы, а где нет

On AI Slop vs OSS Security
https://devansh.bearblog.dev/ai-slop/

> The National Vulnerability Database experienced catastrophic problems throughout 2024. CVE submissions jumped 32% while creating massive processing delays. By March 2025, NVD had analyzed fewer than 300 CVEs, leaving more than 30,000 vulnerabilities backlogged. Approximately 42% of CVEs lack essential metadata like severity scores and product information.

> Now layer AI slop onto this already stressed system. Invalid CVEs are being assigned at scale. A 2023 analysis by former insiders suggested that only around 20% of CVEs were valid, with the remainder being duplicates, invalid, or inflated. The issues include multiple CVEs being assigned for the same bug, CNAs siding with reporters over project developers even when there's no genuine dispute, and reporters receiving CVEs based on test cases rather than actual distinct vulnerabilities.

> HackerOne's research indicates that 70% of security researchers now use AI tools in their workflow. AI-powered testing is becoming the industry standard. The emergence of fully autonomous hackbots—AI systems that submitted over 560 valid reports in the first half of 2025—signals both opportunity and threat.

> The crisis isn't merely about bad vulnerability reports. It's about whether we'll choose to sustain the human foundation of technological progress, or whether we'll let it burn out under the weight of automated exploitation.

Четверг, а значит время проектов от подписчиков! 🌝

Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - https://xn--r1a.website/tech_b0lt_Genona/4983

Слово автору @pwd_001

---

Все кто задавался целью найти утилиту для автоматической генерации YARA-правил (pattern-matching по байтовому содержимому файлов, применяемый для детектирования малвари), наверняка натыкались на проекты vxsig (https://github.com/google/vxsig) и yarGen (https://github.com/Neo23x0/yarGen). Однако vxsig использует слишком "умный подход" — дизассемблирование, биндиффинг и поиск наиболее частых подпоследовательностей инструкций, etc. Это круто, но не быстро, и оставляет за бортом большинство "лобовых" кейсов, где было бы достаточно просто накидать популярные строки из файлов.

Куда более простой и понятный подход у проекта yarGen — ищем интересные строчки во входных файлах, исключаем строки, которые в базе хороших файлов, и вуаля — яра готова. Но архитектурно yarGen — это монолитный python-скрипт на 3+к строк, портированный ещё с python2. Он медленный и давно прекратил своё развитие, так что применить его в своих проектах или как-то поправить оставаясь в рамках монолитного скрипта и мертвого репозитория было очень сложно — будь добр, используй два cli-шных юзкейса, которые автор запихнул в main-функцию.

Я столкнулся с этими же проблемами и постарался перевайбкодить и освежить yarGen, что вылилось в проект https://github.com/ogre2007/yarobot. Проект ещё сыроват, но что есть уже щас:
- код декомпозирован и исправлены ключевые проблемы, которые приводили к замедлению, немного обложен тестами;
- самые "горячие" части кода портированы на Rust;
- режим http-сервиса с веб-интерфейсом;
- выкладка на PyPi под некоторые версии - можно скачать и использовать как cli, как либу, или завести как локальный сервис под linux или windows.

АХТУНГ:
Хоть в проекте и есть небольшая магия под капотом, программа мало знает о малвари, и качество сгенерированных сигнатур не сравнится с ручными. Но отчасти это купируется базами "хороших" строк, которые вы можете сами сгенерировать из своих файлов (в будущем планирую выложить "чистые" базы, как это было у yarGen до остановки их сайта).

попробуйте сами и предложите что улучшить:
https://github.com/ogre2007/yarobot

---

🫡

Ingress NGINX Retirement: What You Need to Know
https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

> To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee are announcing the upcoming retirement of Ingress NGINX. Best-effort maintenance will continue until March 2026. Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Existing deployments of Ingress NGINX will continue to function and installation artifacts will remain available.

> The breadth and flexibility of Ingress NGINX has caused maintenance challenges. Changing expectations about cloud native software have also added complications. What were once considered helpful options have sometimes come to be considered serious security flaws, such as the ability to add arbitrary NGINX configuration directives via the "snippets" annotations. Yesterday’s flexibility has become today’s insurmountable technical debt.

> Despite the project’s popularity among users, Ingress NGINX has always struggled with insufficient or barely-sufficient maintainership. For years, the project has had only one or two people doing development work, on their own time, after work hours and on weekends. Last year, the Ingress NGINX maintainers announced their plans to wind down Ingress NGINX and develop a replacement controller together with the Gateway API community. Unfortunately, even that announcement failed to generate additional interest in helping maintain Ingress NGINX or develop InGate to replace it. (InGate development never progressed far enough to create a mature replacement; it will also be retired.)

> SIG Network and the Security Response Committee recommend that all Ingress NGINX users begin migration to Gateway API or another Ingress controller immediately.