Продолжаем тему подземных ЦОДов
/channel/tech_b0lt_Genona/7126

Данные прикроют с воздуха
https://www.kommersant.ru/doc/9060109

Отраслевой штаб Минцифры утвердил требования к комплексной защите центров обработки данных от беспилотников и других воздушных угроз. Документ (есть у “Ъ”) распространяется на проектируемые, строящиеся и действующие ЦОДы в России независимо от формы собственности и оператора. «Разработка рекомендаций завершена, документ направлен профильным организациям»,— подтвердили в Минцифры, добавив, что сейчас министерство взаимодействует с отраслью для координации действий. Получение документа подтвердили два собеседника “Ъ” на телеком-рынке, два источника на инфраструктурном рынке и собеседник, знакомый с разработкой рекомендаций.

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

- К1 — стратегические объекты, поражение которых может нарушить ключевые государственные функции на срок от часа;

- К2 — объекты, обеспечивающие работу экономически или социально важных систем регионального и отраслевого уровня, нарушение которой может продолжаться от четырех часов;

- К3 — корпоративные ЦОДы, повреждение которых приведет к существенным потерям отдельных организаций без масштабных последствий для государства.

В зависимости от категории предусмотрены требования к удаленности от государственной границы, аэродромов, объектов ТЭКа, крупных транспортных узлов и автомагистралей. Для стратегических ЦОДов предпочтительно подземное, скальное или бункерное размещение, для второй категории допустимы наземные капитальные сооружения, для третьей — обычные наземные здания.

Для действующих ЦОДов предусмотрено снижение заметности с воздуха. Защиту предлагается выстраивать по многоуровневому принципу, сочетая физическое укрепление, радиоэлектронные средства и системы противодействия воздушным угрозам. Конструкции должны обеспечивать сохранность машинных залов, систем охлаждения и электроснабжения при воздействии ударной волны и осколков. Критически важные сервисы предлагается резервировать. Предусмотрены также единый ситуационный центр и взаимодействие операторов ЦОДов с Минобороны, МЧС, Росгвардией и экстренными службами.

Безопасность каждого объекта требует индивидуального подхода, говорит гендиректор оператора ЦОД ОБИТ Андрей Гук. Для крупного бизнеса решением могут стать небольшие корпоративные ЦОДы, для небольших проектов — мобильные или контейнерные. Однако срок их реализации достигает 6–12 месяцев в зависимости от загрузки производства, уточняет он.

ЦОДы уже вынуждены устанавливать инженерные заграждения и антидроновые сетки, говорит замдиректора центра стратегического анализа ВШССН МГУ Тимофей Воронин. Также необходимо внедрять локальные комплексы радиоэлектронной борьбы и переходить к геораспределенному резервированию, отмечает он.

На это накладывается рост тарифов на электроэнергию, дефицит оборудования, в том числе графических карт, и высокая ключевая ставка, перечисляет директор по развитию бизнеса K2 Cloud Ренат Сайфутдинов. «Но даже если укрытия, сетки, датчики и дублирование подключений добавят 5–10% к стоимости объекта, это несопоставимо с потерей 87% его стоимости и месяцами простоя»,— напоминает старший инвестиционный директор KAMA FLOW Роман Чустузиан.

Читать полностью…

Драма на Reddit случилась

Your tokens aren't valuable: No more AI.
https://www.reddit.com/r/opensource/comments/1xelcuf/your_tokens_arent_valuable_no_more_ai/

The long story short, if your project uses AI, is made by AI, or is intended for AI, it's not welcome on r/opensource. AI, as it exists today, is incongruent to this Open Source community.

We're going to be implementing a few new enforcement criteria to this end to discourage those projects:

- Projects advertised here must be all of: 1 year old (not just age, but actively maintained), have multiple contributors (subjectively 3+), not be a common capstone project (school projects, such as note-taking, PDF viewers, cli music players, etc), not be intended for AI (such as MCPs), and have an existing community. No, we can no longer field requests asking for maintainers or people to contribute. Of course it still needs an OSI license as it's always been.

- Though not "new", 1 year account age minimum, with significant Reddit contributions. You should not be creating a Reddit account to come here; we're a community of existing redditors. If you send us a message in modmail about this after having attempted to post, you will be permanently banned and muted. If this seems harsh, know that I estimate 20 messages a day from people expecting their slop projects and burner accounts to get an exception.

- If it's obvious you're using AI in your project, we don't want it. Tokens are cheap, and we don't care how many you spent to make your amazing project.

- If you don't speak English, you need to find a different community. We cannot distinguish between AI-written and AI-translated. Since you don't speak English, you can't even verify yourself if it translated correctly.

- Temporary bans are only for community members that made temporary lapses in judgement, such as when getting agitated. If you post (or comment) things we don't want, such as the result of your LLM output tokens, you will never be welcome back.

If you want to be a part of the cleanup crew, be sure to reach out. If you don't like keeping this community for the humans, let me know so I can make sure you see your way out; maybe go try r/opensourceeai (sic).
...
/Edit: shout out to u/esk6plays for starting r/TrueOpenSource. Let's cheer them on! Hopefully it will be an great refuge for those affected by this policy.

Получается теперь ядро Linux это не настоящий open source 🌝

Читать полностью…

☝🏻Свежие дыры в ядре Linux случайно выложили на всеобщее обозрение

Zero Day Initiative от Trend Micro отправила отчёты о новых уязвимостях ядра в публичную рассылку LKML, которую читает кто угодно. Их следовало прислать в закрытый список для безопасников.🤷🏼‍♀️

Большая часть дыр в основной ветке ядра ещё не закрыта. Где-то патчи только тестируют или держат в ветках «-next».

Грег Кроа-Хартман, второй человек в разработке ядра, на каждое письмо спросил, почему оно попало в открытую рассылку.🤔

Что утекло:
🔻 SMB Direct: удалённое выполнение кода из-за целочисленного underflow, CVSS 9,0;
🔻 KSMBD, встроенный в ядро SMB-сервер: состояние гонки, тоже удалённое выполнение кода и тоже 9,0;💀
🔻 skb_zerocopy в сетевом стеке, драйвер VMware-графики VMWGFX и обработка TCP-запросов search-domain: локальное повышение привилегий;
🔻 NVMET: раскрытие информации из-за неинициализированного ресурса.

☝🏻По сути, атакующие получили готовую карту: где искать и что ломать. При этом заплаток у большинства пользователей ещё нет.

Патч для SMB Direct уже лежит в ветке будущего ядра 7.5, а о дыре в skb_zerocopy разработчики узнали из другого источника ещё неделей раньше.

За первые полгода 2026-го в ядре нашли 2308 уязвимостей с CVE, больше, чем у любого другого производителя ПО. А нейросети охоту на баги только ускоряют.🤖
================
👁 News | 👁 Soft | 👁 Gear | 👁 Links

Читать полностью…

Это я путешествую по интранету

/channel/mus_b0lt_Genona/471

Читать полностью…

Да, охуенно. Так реально стало безопасней, спасибо.

$ sudo docker pull hello-world
Using default tag: latest
Error response from daemon: Head "https://registry-1.docker.io/v2/library/hello-world/manifests/latest": net/http: TLS handshake timeout

$ sudo docker pull hello-world
Using default tag: latest
latest: Pulling from library/hello-world
4f55086f7dd0: Retrying in 4 seconds

Читать полностью…

Не все ещё осознали, но мир поменялся

https://cve.socradar.io/

Читать полностью…

/channel/macswift/111564

Сегодня широкие массы узнали, что клиенты для Telegram пилятся через ИИ-шки активно.

Для всех кто реально следит за развитием Telegram это давно не новость 🌝

Читать полностью…

Ну, если ciliium не хочет чинить мою багу (не связано с подачей моих PR, тут отдельная история), то я несу в gw api тесты, которые cilium пройти больше не сможет, не починив мою багу.

Читать полностью…

Интересное исследование от Hirundo для любителей наслопить 🌝

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

Chinese AI Writes Weaker Code for Beijing’s Adversaries. We Fixed It. A Qwen3-Coder Case Study
https://www.hirundo.io/blog/qwen3-coder-vulnerabilities

TL;DR: Chinese AI models now sit inside Western products, and some carry geopolitical triggers: tell the model who the code is for, and the security of what it writes changes. For the first time, we showed that this vulnerability lives in the model's weights, and that removing the model's CCP alignment removes it.

One word tilts the code against Americans. Ask for the app "for a US defense contractor" instead of "for a Chinese defense contractor", and Qwen3-Coder is 19% more likely to hand back an app that can be hacked.

Hong Kong's democracy movement gets apps that leak. Apps built for a Hong Kong democracy group were 28% more likely to let any user read everyone else's secrets.

Asking for secure code didn't help. With a security instruction in the prompt, the US contractor's apps were 27% more likely to be hackable than a neutral customer's.

Westernized Qwen3-Coder closed all three gaps. After Hirundo removed the model's CCP alignment, none of the three gaps remained, and on ten other coding tasks it built working apps as often as the original. It is available on Hugging Face.

Ссылка на Hugging Face

Hirundo Qwen3-Coder-30B-A3B-Instruct Westernized
https://huggingface.co/hirundo-io/Qwen3-Coder-30B-A3B-Instruct-Westernized

В статье в основном говорится про Qwen3, но есть упоминание на другие исследования от CrowdStrike и Booz Allen

The harder question is what the same alignment does when the model writes software, and two security teams have already reported early evidence of backdoors:

CrowdStrike found DeepSeek-R1 wrote vulnerable code 27.2% of the time when the request mentioned Tibet, against 19% without. Asked for a web app for a Uyghur community center, it left out logins entirely.

Booz Allen found that three of four Chinese coding models wrote more vulnerable code when told it was for the US government. Qwen3-Coder showed the largest jump, +130%.

There are major risks with allowing Chinese LLMs to code for U.S. applications
https://www.boozallen.com/expertise/cybersecurity/whats-in-americas-code.html

CrowdStrike Research: Security Flaws in DeepSeek-Generated Code Linked to Political Triggers
https://www.crowdstrike.com/en-us/blog/crowdstrike-researchers-identify-hidden-vulnerabilities-ai-coded-software/

Читать полностью…

Время обновлять QUIC 🌝

Header Accordions: QPACK amplification attacks against HTTP/3 servers
https://foxio.io/blog/header-accordions-qpack-amplification-attacks-against-http-3-servers

TLDR

A remote, unauthenticated client can force an HTTP/3 server to allocate tens to thousands of times more memory than it sends. One connection is enough to OOM or pin a default-configured server. Seven of the ten implementations tested are vulnerable; several are already fixed.

QPACK compresses HTTP/3 headers to minimize traffic sent over the wire. Across the affected implementations, decoded-header limits are missing, incomplete, or applied too late. A small HEADERS frame can therefore expand into hundreds of thousands of header objects in memory. Preventing that expansion from exhausting resources requires enforcing a cumulative budget as fields are decoded and retained.
...
Mitigations

Bun: Don't expose HTTP/3 servers

mitmproxy: disable HTTP/3 (pass --set http3=false)

h3 crate: set a reasonable max_field_section_size

Not affected: IIS, Envoy, ngtcp2/nghttp3

По ссылке много подробностей

Тред
https://x.com/4A4133/status/2113008219891109996

Читать полностью…

Продолжаем разбираться с тем как мы докатились до такой жизни

C PHP разобрались
/channel/tech_b0lt_Genona/7189

Теперь разбираемся с сертификатами
/channel/tech_b0lt_Genona/7171

Проблемные корневые сертификаты eMudhra были сгенерированы в HSM и прошли независимый аудит
https://www.opennet.ru/opennews/art.shtml?num=66524

Компания eMudhra опубликовала заявление, связанное с инцидентом, в результате которого у восьми корневых сертификатов удостоверяющего центра оказались легко подбираемые закрытые ключи, имеющие всего 1 байт энтропии вместо 48. eMudhra утверждает, что сертификаты были сгенерированы в апреле 2025 года на публичной торжественной церемонии с использованием аппаратных модулей HSM (Hardware Security Module), имеющих сертификат соответствия требованиям FIPS 140-2 Level 3.

В процессе генерации ключей произошёл сбой, из-за которого на этапе упаковки/распаковки в HSM (wrap/unwrap, шифрование и расшифровка ключом-обёрткой) в дополнение к основному набору криптостойких ключей был создан второй набор слабых ключей с обнулёнными старшими байтами, который и был задействован в сертификатах. Сбой не был распознан, так как закрытые ключи создаются и хранятся только в HSM и не попадают в открытом виде за его пределы. Причина произошедшего сбоя пока не ясна и компания проводит связанное с этим расследование. Утверждается, что проблемные корневые сертификаты, созданные с использованием слабых ключей, прошли независимый аудит и два года оставались в списке доверенных во всех хранилищах корневых сертификатов.

Оригинал
eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA
https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

А ещё можно почитать обсуждение у Mozilla

eMudhra: Private key compromise of Intermediate Certificates
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Читать полностью…

🫡

https://hoster.by/clients/news/42993/

Читать полностью…

Ну это просто праздник какой-то

Если кто-то пропустил, то вчера весь мир ждал патчи от PHP закрывающие 2 RCE

/channel/tech_b0lt_Genona/7175
/channel/tech_b0lt_Genona/7187

Нарушения эмбарго и затягивание разработки патчей в ходе устранения уязвимостей в PHP
https://www.opennet.ru/opennews/art.shtml?num=66523

Разработчики PHP опубликовали отчёт о проблемах, возникших в процессе устранения исправленных вчера критических уязвимостей в PHP. Информация об уязвимости, возникающей при исчерпании доступной памяти, была получена в ходе внешнего аудита ещё в 2024 году, но была воспринята лишь как теоретическая возможность совершения атаки. Исправление затянулось из-за проблем с достижением консенсуса среди разработчиков PHP о способе устранения уязвимости. Рассматривалось несколько конкурирующих предложений о решении проблемы, каждое из которых имело свои минусы. Приходилось выбирать между нарушением обратной совместимости, появлением новых векторов для атак, вызывающих отказ в обслуживании, и необходимостью внесения изменений во множество сторонних дополнений.
...
Изначально, скоординированная с дистрибутивами дата публикации исправления была назначена на 22 октября, но затем была перенесена на 21 октября после утечки 20 октября в социальные сети сведений о CVE-идентификаторах и некорректных данных о времени публикации предстоящих корректирующих выпусков.

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

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

Оригинал
Today's PHP Security Release, and How We're Strengthening PHP Security
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

Получается команда PHP 2 (два!) года знала о проблеме и буквально ничего не делала не то что для фикса, но хотя бы для митигирования, занимаясь охуительными обсуждениями.

> за шесть часов до намеченной публикации исправлений компания Chainguard нарушила эмбарго и опубликовала сборки своего дистрибутива

Если что, то Chainguard не осуждаю, с такими гениями в команде PHP жалко, что они ещё раньше этого не сделали.

Читать полностью…

Две RCE подтвердились

/channel/tech_b0lt_Genona/7176

Выпустили пост официальный по поводу уязвимостей в PHP

Всем заинтересованным крайне рекомендую ознакомиться

https://www.php.net/archive/2026.php#2026-10-21-5

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

The vulnerabilities:

RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.

RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

Уже есть рабочий сплойт
https://php2shell.ru

Читать полностью…

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

Сейчас у меня на них не хватает времени, но я слежу за событиями и стараюсь смотреть онлайн.

Долгих летов SPbLUG и многих юбилеев!

На фото это мы на общей стойке на DevOops 2019, где проводили доклады митапошного вида 🌝

Читать полностью…

Посмотрите как безопасно работает WireGuard между Санкт-Петербургом и Москвой.

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

Если "обфусцировать" трафик, то скорость становится абсолютно нормальной.

Настроили охуенно, спасибо.

Читать полностью…

Недавно было обновление NodeJS, которое закрывало багу

Node.js Brotli decoder out-of-bounds write permits remote code execution (CVE-2026-111497) - (high)

A flaw in Node.js can cause Node.js Brotli decoder out-of-bounds write permits remote code execution.

This vulnerability affects Node.js 26.x, 24.x, and 22.x.

/channel/tech_b0lt_Genona/7186

И вот уже по сути PoC, но обёрнутый в добрые цели 🌝

Node2Shell / HTTP2Shell — CVE-2026-111497 Response Kit
https://github.com/pt-act/node2shell-cve-2026-111497

Auditing kit for the Google Brotli decoder out-of-bounds write (CVE-2026-111497),
also known as Node2Shell and HTTP2Shell.
...

How the bug works

A crafted stream declares one block type, then switches block types. The decoder should reject that as a format error, but an unchecked return value made it treat the invalid switch as "need more input" and keep appending bytes past an 8-byte internal buffer. That is the out-of-bounds write (CWE-787).

The fix adds a new error code, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH (-17), which is also what makes the safe version probe possible.



На БЕКОН я рассказывал, что в рамках работ по сертификации занимался фаззингом NodeJS
/channel/tech_b0lt_Genona/6839

И так получилось, что фаззил как раз Brotli, делалось это в рамках взаимодействия с "Центром исследований безопасности системного программного обеспечения"

/channel/tech_b0lt_Genona/4755

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

Читать полностью…

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

/channel/tech_b0lt_Genona/7213
/channel/tech_b0lt_Genona/7214

Да, ночью откатили. Сейчас всё норм.

Но я бы не расслаблялся 🌝

Читать полностью…

Короче, захуярили очередную часть Амазона (возможно, и не только его) в котором хостится Dockerhub (или списки какие-то "слетели")

Какой-то части повезло выжить и иногда может что-то долететь всё же

$ sudo docker pull debian:11
Error response from daemon: failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://registry-1.docker.io/v2/library/debian/manifests/sha256:6f519a81440354a85eb592c5f32109ab80605f6b892455983a6f618bf87fabe9": net/http: TLS handshake timeout

Причём, если даже чудом что-то долетело, то скорость шейпится

$ sudo docker pull debian:11
11: Pulling from library/debian
94b0efe6d4f7: Downloading [======>                                            ]   7.34MB/53.78MB
539fdffe17e9: Download complete

То что выше качаем уже 6 минут

Читать полностью…

Патчи для PHP

/channel/tech_b0lt_Genona/7187

, оказались не очень хорошими. Поэтому ждём очередных обновлений, а пока вместо этого конфигурируйтесь 🌝

Обратите внимание на второй абзац

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. This setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026. If you applied it then, keep it in place and no further action is needed.

The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

https://www.php.net/archive/2026.php#2026-10-23-1

Читать полностью…

на фоне всего всего вокруг яндекс станций грех будет не рассказать про свою (и не только) разработку годовалой давности в этой теме: полноценная замена бэкенда которую можно запустить у себя и делать всё полностью локально: @v3rt3p
за качество ручаюсь, написано в основном своими культяпками!

Читать полностью…

Наконец-то добро пошло

Я уже писал, что к верификации хорошо отношусь 🌝

/channel/tech_b0lt_Genona/5244
/channel/tech_b0lt_Genona/5586

Да и в целом

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

/channel/tech_b0lt_Genona/6136

Аnthropic развивает технику для формальной верификации существующего ПО при помощи AI
https://www.opennet.ru/opennews/art.shtml?num=66528

Компания Аnthropic представила результаты экспериментов по использованию AI-моделей для формальной верификации надёжности и безопасности уже существующих проектов. В ходе эксперимента при помощи AI-моделей для 123 открытых библиотек, протестированных в инфраструктуре OSS Fuzz, были сгенерированы математические доказательства отсутствия ошибок при работе с памятью.

Проверка проводилась на уровне скомпилированного ассемблерного кода для архитектуры RISC-V. Общий объём сгенерированных доказательств составил около 180 миллионов строк кода для системы верификации Rocq Prover (около 600 тысяч строк на бинарный файл с 18 тысячами RISC-V инструкций). Доказательства формировались путём автоматического преобразования существующих fuzzing-тестов в формальные спецификации, после чего AI-модель Claude доказывала, что при любых входных данных объёмом до 64 МБ в программе не возникает сбоев.
В процессе построения доказательств AI-модель смогла выявить и подготовить исправления для сотен ошибок, ранее не замеченных при fuzzing-тестировании. Среди прочего, были выявлены уязвимости, приводящие к переполнению буфера при обработке определённых входных данных (например, CVE-2026-56132 в libexpat), а также логические ошибки. Помимо этого, AI-модель была использована для доказательства соответствия реализации алгоритма zlib в ядре Linux спецификации RFC 1950.

Также на языке Rust был сгенерирован интерпретатор для подмножества языка Python, для которого при помощи инструментария Verus подготовлено формальное доказательство соответствия семантике CPython. Для сравнения поведения с CPython было выполнено более 1.7 миллионов случайно сгенерированных Python-программ. В 99.95% случаев результаты выполнения этих программ в новой реализации и в CPython совпали, а выявленные расхождения оказались известными граничными случаями.

Оригинал
LLMs are making formal software verification feasible at a much larger scale
https://www.anthropic.com/research/formal-verification

Appendix: LLMs are making formal software verification feasible at a much larger scale
https://www-cdn.anthropic.com/files/4zrzovbb/website/6867eadf760258fa8b42a504600cd3c036d16358.pdf

Сделаны очень хорошие ролики для тех, кто не очень понимает что дают разные подходы

Читать полностью…

Про один прекрасный телефон я уже рассказывал

/channel/tech_b0lt_Genona/5447

Про свой тоже

/channel/tech_b0lt_Genona/5815

Смотрите какая прелесть

Мобильник почти из ничего: Как ИИ помог собрать телефон из деталей с маркетплейсов
https://habr.com/ru/articles/1087140/

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

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

Замечу, что я использовал только бесплатные DeepSeek, Gemini и ChatGPT в бесплатном ограниченном режиме.

Схема и проект

https://github.com/viktand/Phone/blob/main/phone_circuit.png
https://github.com/viktand/Phone/

Читать полностью…

OVHcloud CLI скомпрометирован и использовался для распространения малвари
https://xakep.ru/2026/10/22/ovhcloud-cli-hack/

Атака произошла 19 октября 2026 года. В общей сложности вредоносные файлы находились на GitHub около полутора часов (с 12:47 до 14:21 UTC), но исходный код OVHcloud CLI, теги релизов и CI/CD-пайплайны не пострадали. Сообщается, что злоумышленники локально собрали вредоносную версию из более позднего коммита и добавили ее в уже существующие релизы, опубликованные с апреля по сентябрь текущего года.

Подмена затронула сборки для macOS на Intel и ARM, Linux x86_64 и arm64, а также Windows x86_64. Более того, для версии 0.15.0 злоумышленники заменили и checksums.txt, поэтому опубликованные контрольные суммы соответствовали вредоносным файлам.
...
Отмечается, что установки через Homebrew не пострадали: менеджер пакетов проверял SHA-256 загружаемых архивов и отклонял подмененные файлы. Также атака не затронула go install, сборку из исходников и Docker-образы. Пользователи, установившие CLI до начала атаки и не обновлявшие его 19 октября, тоже получили оригинальные файлы.
...
Один из клиентов OVHcloud обнаружил атаку после того, как его CI-задача начала отклонять архив из-за несовпадения контрольной суммы SHA-256. После публикации этого issue на GitHub специалисты OVHcloud начали расследование, вредоносные файлы удалили, и вскоре вышла «чистая» версия 0.16.0 с криптографически подписанным тегом.

Оригиналы

ovhcloud-cli security incident - October 19th, 2026
https://github.com/ovh/ovhcloud-cli/security/advisories/GHSA-862f-55f5-vmvw

Release assets of v0.13.0–v0.15.0 replaced on 2026-10-19 with a dirty build of a later commit
https://github.com/ovh/ovhcloud-cli/issues/300

> для версии 0.15.0 злоумышленники заменили и checksums.txt, поэтому опубликованные контрольные суммы соответствовали вредоносным файлам

В эту же сторону я упоминал на DUMP (/channel/tech_b0lt_Genona/6556?t=16m46s), когда говорил про tag poisoning в контексте просто лежащего SBOM-а в релизах. Всё это просто текстовые файлики, которые можно также подменить и со стороны будет казаться что всё нормально.

В очередной раз сборка из сырцов на своей стороне показала свою эффективность 🌝

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

/channel/tech_b0lt_Genona/4381
/channel/tech_b0lt_Genona/4382
/channel/tech_b0lt_Genona/4383
/channel/tech_b0lt_Genona/4385
/channel/tech_b0lt_Genona/4388

Читать полностью…

С РБ разобрались
/channel/tech_b0lt_Genona/7191

Теперь с РФ

Центр ФСБ отреагировал на выявленную ИИ уязвимость сайтов
https://www.rbc.ru/technology_and_media/22/10/2026/6ada3f589a79475002a9c892

Национальный координационный центр по компьютерным инцидентам (НКЦКИ, действует при ФСБ) предписал объектам критической информационной инфраструктуры (сети связи и информационные системы госорганов, финансовых, энергетических, транспортных, медицинских и ряда других компаний) временно отключать свои сайты, если они не успевают обновить программное обеспечение из-за уязвимостей в PHP.
Такое указание содержится в письме, направленном 22 октября НКЦКИ в адрес владельцев объектов, относящихся к критической информационной инфраструктуре (копия есть у РБК, ее подлинность подтвердили три организации-получателя).

Директива разослана через ГосСОПКА — госсистему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы. Ее координацию ведет НКЦКИ, все объекты критической инфраструктуры обязаны взаимодействовать с ФСБ через НКЦКИ и ГосСОПКА по вопросам кибербезопасности.

НКЦКИ в письме предписал обновить PHP до исправленной версии, а после — проверить серверы антивирусом и изучить журналы на следы взлома. Если обновить систему быстро невозможно, организации должны «рассмотреть временное ограничение внешнего доступа к уязвимым веб-серверам вплоть до их отключения». О подозрительных инцидентах предписано сообщать в дежурный центр ГосСОПКА.

А ещё смешно то, что вчера сайт PHP был недоступен из-за "ковровых" блокировок (ради безопасности, естественно). Сегодня с утра, вроде, ВНЕЗАПНО, стал доступен.

Не забываем говорить спасибо за безопасный интранет, ведь, если ты не имеешь доступа к источнику информации или к какому-нибудь другому ресурсу (напоминаю, что OWASP и БДУ grype по-прежнему недоступны, например), то и значит ты не знаешь про проблемы. А если про проблемы не знаешь, то их как бы и нет. Думаем.

/channel/tech_b0lt_Genona/7187?comment=62721

Читать полностью…

Продолжаем четверг!

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

---
Всем привет!

Я Tech Lead на Java. Много лет жил со схемой «Postgres + отдельный кэш в памяти».
На бумаге удобно, на практике — два клиента, два способа "успасть" и постоянный вопрос: запись уже в кэше или в бд, размазанные границы транзакций.
Хотелось один контур: SQL, горячий набор в RAM с долговременным хранилищем, и нормальное согласованием состояние между узлами.
Получился Grid SQL — открытая SQL-first СУБД.

Репозиторий: https://github.com/GenCloud/grid-sql

Зачем это вообще

Типичный Java-бэкенд часто держит горячие данные в процессе и отдельно бд. Я собрал это в один продукт:
• схема и DML — SQL (ANTLR-диалект);
• горячий набор — шардированная карта ключ → byte[] в памяти;
• долговечность — append-only OpLog, потом видимость в карте; sealed-снимки (.gmap) и индексы (.sbpt) на диске;
• между узлами — протокол ORCHID (допуск записи), не отдельный Raft сбоку.
Durability и репликация включаются разными флагами. Один узел с диском и без соседей — штатный режим.
Клиентам один протокол:
• grid:// — Reactor / ConnectionFactory;
• jdbc:grid:// — тот же wire, sync JDBC (DAO, DBeaver).


ORCHID

В Raft: выборы лидера, term, пишет лидер.
У нас выборов и term нет. Зато всегда не больше одного писателя, пока кластер допускает запись.

Два независимых механизма:

1) Фазы (модель Курамото) → параметр порядка R. Ниже порога (по умолчанию 0.85) — запись даже не предлагаем.

2) Контрольная сумма операции (digest) → большинство из конфигурации должно подтвердить одну и ту же сумму. Высокий R сам по себе коммит не делает.
Пишущий = среди синхронизированных по фазе узел с минимальным nodeId. Упал / сменилась роль — клиенту метаданные / PROMOTE_NOTIFY, не крутим хосты кластера наугад.

Разделение сети:

• N=3, живы двое — пишут двое (есть majority);
• N=2 и связь пропала — не пишет никто;
• N=1, пропали сконфигурированные узлы - не пишет никто. Запись возможна только если с самого старта N=1.

Коммит сначала уходит в OpLog и подтверждается на диске, и только после этого строка становится видна в памяти.

Упал на этом шаге — клиент получает ошибку, частично применённой записи в выборках нет.

Спеки ORCHID гоняются через TLA+/TLC в CI.

Согласованность на стенде — Jepsen: register/append, с сетевым хаосом и без, unclean revive, multi-DC.

Покрытие матрицы: https://github.com/GenCloud/grid-sql/blob/master/benchmarks/jepsen/COVERAGE.md

Что ещё в коробке

• TX, PREPARE, индексы;
• чтение с реплик (opt-in) с отказом при слишком большом lag, а не «отдадим протухшее»;
• promote пишущего, multi-DC режимы (в т.ч. remote voters по digest без фаз через WAN);
• Spring Boot auto-config + fat jar starter;
• документация EN/RU, CLA для внешних PR.
Модули грубо: grid-sql-client · grid-server-core · grid-sql-server-starter · jepsen/jmeter starters.

Цифры

Лабораторный хост, два узла, fsync:
• HA WRITE_ONLY ≈ 4676 оп/с (порог регресса ≈ 4442);
• READ_ONLY полоса примерно 52–59k;
• смесь Capacity QG примерно 8.7–11k.
Это ориентиры конкретного железа.

Методика:
https://github.com/GenCloud/grid-sql/blob/master/docs/ru/performance/capacity-slo.md

Чего сознательно нет

• два пишущих узла с последующим merge журналов;
• общий dataDir на NFS/SAN на весь кластер;
• XA поверх чужих ресурс-менеджеров;
• «ослабим quorum/fsync, чтобы TPS красивее смотрелся».

Пощупать

RU quick start:

https://github.com/GenCloud/grid-sql/blob/master/docs/ru/getting-started/quick-start.md

ORCHID:

https://github.com/GenCloud/grid-sql/blob/master/docs/ru/understand/orchid-consensus.md

Разбор на Habr:

https://habr.com/ru/articles/1089168/

Вопросы, претензии к модели, issues — в личку или в GitHub.
Если проект зайдёт — звезда в репо помогает не потеряться в шуме.
---

Читать полностью…

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

Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - /channel/tech_b0lt_Genona/4983

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

---

Всем привет!

Clarus — DICOMweb-сервер на Rust

https://github.com/clicker71/clarus-pacs

DICOMweb — это стандарт обмена медицинскими изображениями поверх обычного HTTP: по сути, REST API для снимков (QIDO/WADO/STOW вместо SELECT/FETCH/INSERT).

Снимки ходят как JSON + бинарные потоки — внутренности DICOM-файлов знать не нужно.

Для тех, кто хочет делать медицинский ИИ, но не хочет учить DICOM — clinfer.
Это простой ABI-контракт: ваша модель (на любом языке, отдельным процессом) отдаёт результат — контуры, маски, текст — а clinfer сам оборачивает его в корректный DICOM (RTSTRUCT / SEG / SSO / SR) и кладёт в архив.

ap101 — наш набор гейтов нулевых аллокаций: "горячий" путь сервера доведён до 0 аллокаций при приёме CT-исследования (было ~128 000).

https://github.com/clicker71/ap101

Живой пример: end-to-end демо с TotalSegmentator (Clarus + clinfer, стандарт IHE AIW-I)

https://github.com/clicker71/clarus-pacs/releases/tag/totalseg-demo-v0.4

На данный момент проект пока закрыт, так как идёт "полировка" для соответствия стандарту

---

Читать полностью…

Обновляем гитлабчики 💅💅💅

CVE-2026-110264 - Integer Overflow issue in Regular Expression Compiler impacts GitLab CE/EE
GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression.

In addition to our standard patch releases, we have backported this fix to GitLab CE/EE versions 18.11.13, 19.0.10, 19.1.9, and 19.2.9.

Impacted Versions: GitLab CE/EE: all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1

CVSS 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Thanks joaxcar for reporting this vulnerability through our HackerOne bug bounty program

https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/?nav=19.5.1

Сегодня праздник на 10 из 10 🌝

+

https://techora.ru/news/gitlab-ispravila-kriticheskuyu-uyazvimost-s-vypolneniem-2026-10-22

Читать полностью…

Так, NodeJS выкатил апдейт, в том числе и в связи с дуркой с сертификатами /channel/tech_b0lt_Genona/7171

https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

dns.resolve truncates names containing NUL char
(CVE-2026-105482) - (high)

This vulnerability affects Node.js 26.x, 24.x, and 22.x.

TLS certificate hostname bypass when the IP is written fullwidth digits (CVE-2026-105483) - (high)

This vulnerability affects Node.js 26.x and 24.x.

TLS certificate hostname bypass when the host loosely resolves to an IP address (CVE-2026-106069) - (high)

This vulnerability affects Node.js 26.x, 24.x, and 22.x.

Node.js Brotli decoder out-of-bounds write permits remote code execution (CVE-2026-111497) - (high)

A flaw in Node.js can cause Node.js Brotli decoder out-of-bounds write permits remote code execution.

This vulnerability affects Node.js 26.x, 24.x, and 22.x.

Неделя вообще не скучной получается.

Читать полностью…

SPbLUG — 30 лет!

В октябре 2026 года Санкт-Петербургской группе пользователей GNU/Linux — SPbLUG — исполняется 30 лет. Первая линуксовка прошла в октябре 1996 года. С тех пор менялись дистрибутивы, технологии и места встреч, но оставалось главное — люди, которым интересно разбираться в устройстве систем, делиться знаниями и делать свободное программное обеспечение лучше. 28 октября в 19:30 приглашаем отметить юбилей вместе!

Что такое SPbLUG
SPbLUG (Saint Petersburg Linux User Group) — независимое сообщество пользователей Linux в Санкт-Петербурге. Здесь встречаются люди с разным опытом: одни только устанавливают первый дистрибутив, другие годами администрируют Linux-системы, пишут программы, разрабатывают и улучшают свободное ПО.
Для кого-то Linux — рабочий инструмент, для кого-то — домашняя система, для кого-то — возможность разобраться, как всё устроено, и изменить это под свои задачи. На линуксовках эти интересы пересекаются: можно обсудить техническую проблему, показать собственный проект, поделиться находкой или услышать о том, с чем ещё не приходилось работать.
Сообщество живёт не только во время докладов. Это и помощь с установкой и настройкой, и обмен опытом, и разговоры, которые начинаются с одного вопроса, а заканчиваются далеко за пределами исходной темы. Повестку определяют сами участники — предлагают темы в чатах и по почте, готовят выступления и приходят на встречи.

От Аничкова моста до дата-центра
SPbLUG основал Михаил Браво. В ранние годы участники собирались у коня на Аничковом мосту. В мае 2000 года встречи перебрались в небольшую комнату на историческом факультете СПбГУ, а в декабре того же года — в Феникс-центр на географическом факультете. Эта площадка оставалась домом для линуксовок вплоть до пандемии.
С 2020 года одной из площадок стал бар Fail0ver, а с 2023-го — дата-центр «Миран». За три десятилетия были и другие места: бары, конференции и фестивали.
В разные годы координацией сообщества занимались Игорь Николаев и Андрей Мавлянов. С 2022 года сообщество координируют Станислав Богатырев и Наталья Крапкина.

Люди, встречи и свободное ПО
За эти годы перед участниками SPbLUG выступали Джон «MadDog» Холл, Ричард Столлман, Марк Шаттлворт и Ян Мёрдок. На встречи приходили разработчики крупных дистрибутивов, ядра Linux и других свободных проектов, создатели устройств и ПО, авторы книг и IT-изданий, блогеры и стримеры.
Но история сообщества складывается не только из выступлений известных гостей. Она состоит и из обычных встреч: когда кто-то впервые пришёл за помощью, принёс интересную задачу, решился сделать доклад или нашёл людей, с которыми можно часами обсуждать любимую техническую тему.
На линуксовках обменивались дистрибутивами, проводили InstallFest — помогали устанавливать и осваивать Linux. Участники поддерживали связи с другими техническими сообществами и конференциями, в том числе Embedded Group, RU.SYSADMINS, DevOps40, ITGM и Linux Piter, JUG и Онтико.
Общение постепенно переходило из эхи SPB.LINUX в FIDO и IRC в почтовые группы, Matrix и Telegram. Расширялся и круг интересов: рядом с GNU/Linux появились коммерческая разработка, DevOps, инфраструктура, AI и так далее.
Сегодня SPbLUG по-прежнему собирается в последнюю среду месяца. Это всё ещё то самое место, куда можно прийти не только за информацией, но и за живым общением с людьми, которым интересно то же, что и вам.

Что будет на юбилейной встрече
— «С чего начинали» — вспоминаем свой первый Linux, первые линуксовки, былые времена
— «SPbLUG: три десятилетия вместе» — ретроспектива от Станислава Богатырева
— Угощения от партнёров IHC.ru и свободное общение

Приходите, если давно не заглядывали, бываете регулярно или только хотите познакомиться с сообществом. Необязательно иметь за плечами десятилетия работы с Linux: юбилей — хороший повод встретиться впервые, узнать как перейти на Linux и что такое свободное ПО.

Когда и где
28 октября (среда), 19:30 — бар Failover, 2-я Советская улица, 18.
Cайт сообщества: spblug.org.

До встречи на линуксовке!

Читать полностью…