В докладе на NeoQUEST-2025 (https://www.tgoop.com/tech_b0lt_Genona/5705), я затрону тему, а какие есть вообще идеи и подходы как выстроить процесс так, что бы полученным SBOM'ам можно было бы доверять.
Напомню, что SBOM очень важен, если вы хотите понимать, что "приехало" в приложение и окружение. Именно на SBOM опирается понимание того, что поставляется и какие уязвимости в продукте есть.
Класический SBOM с этим плохо справляется (см. 1 и 2 скрины)
Одним из фреймворков, который призван решить проблему целостности и прозрачности всей цепочки разработки является in-toto (https://in-toto.io/). Во главу угла в нём поставлена идея аттестации каждого из шагов, который происходит во время разработки.
> in-toto models the software supply chain as a series of “steps”. Supply chain owners, i.e. project owners or maintainers, define the set of actors authorized to perform each step and rules that govern the artifacts used and produced by the step. They can also include other arbitrary checks called “inspections” to be performed during the verification workflow. These policies are recorded in a piece of metadata called a supply chain “Layout”, which is cryptographically signed by the supply chain owners. As each step is performed, one or more attestations are generated recording various aspects of the process, and during verification, in-toto applies the policies in the layout against the set of attestations produced during the execution of the supply chain
https://slsa.dev/blog/2023/05/in-toto-and-slsa
Можно попробовать поиграться самому на примере
https://in-toto.io/docs/demo/
Имплементации
https://github.com/in-toto/in-toto-java
https://github.com/in-toto/in-toto-golang
Репа с доработками и предложениями
https://github.com/in-toto/ITE/
На 4 скрине пример, link-файла, который является одним из этапов общей цепочки аттестации. В нём видно команду и файлы, которые участвуют в одном из шагов
Дальнейшим развитием этого подхода является включение аттестации in-toto в pipeline с дополнительной проверочной информацией - SBOMit (https://sbomit.dev/ + 3 скрин)
> Once an SBOMit document is produced, clients can perform extensive verification of the document in order to get a high degree of assurance about the software’s integrity. For example, a client could verify that the steps described in the document indeed took place; ensure the identity of who performed a particular step by inspecting link metadata; or ensure that all the steps indeed led to the final SBOM described by the SBOMit document.
https://openssf.org/blog/2024/06/26/a-deep-dive-into-sbomit-and-attestations/
Попробовать можно тут
- Recursively collects all system calls made during the compilation of your project.
- Parses the packages your project utilized during compilation.
- Generates an in-toto attestation for your project, detailing the materials used and the output products.
https://github.com/SBOMit/SBOMit-strace-prototype
В целом этот подход хорошо рассказан в докладе (откуда и взяты первые три скрина)
Your SBOM Is Lying To You – Let’s Make It Honest
https://www.youtube.com/watch?v=4ZsdNUJyZXU
Российские решения с которыми сам работал и/или пересекался и тоже относятся, по моему мнению, к тематике поста
- Buildography (ИСП РАН, https://www.ispras.ru/technologies/buildography/) - отслеживает системные вызовы в процессе сборки и собирает данные о файлах/каталогах, аргументы, вызываемые программы и т.д. и сохраняет всю собранную информацию для дальнейших проверок.
- sbom-checker (open source, https://gitlab.community.ispras.ru/sdl-tools/sbom-checker) - набор утилит, который позволяет обновить и проверить SBOM'ы согласно требованиям ФСТЭК. Главное в скриптах, по тематике поста, это то, что можно получить и провалидировать информацию по репозиториям зависимостей.
- CodeScoring (https://codescoring.ru/) - платформа в целом посвящённая SCA: построение SBOM'ов, построение цепочки зависимостей, защита от supply chain атак и т.д.
Если кто-то ещё что-то хочет добавить или поправить пишите в комменты или в личку.
Напомню, что SBOM очень важен, если вы хотите понимать, что "приехало" в приложение и окружение. Именно на SBOM опирается понимание того, что поставляется и какие уязвимости в продукте есть.
Класический SBOM с этим плохо справляется (см. 1 и 2 скрины)
Одним из фреймворков, который призван решить проблему целостности и прозрачности всей цепочки разработки является in-toto (https://in-toto.io/). Во главу угла в нём поставлена идея аттестации каждого из шагов, который происходит во время разработки.
> in-toto models the software supply chain as a series of “steps”. Supply chain owners, i.e. project owners or maintainers, define the set of actors authorized to perform each step and rules that govern the artifacts used and produced by the step. They can also include other arbitrary checks called “inspections” to be performed during the verification workflow. These policies are recorded in a piece of metadata called a supply chain “Layout”, which is cryptographically signed by the supply chain owners. As each step is performed, one or more attestations are generated recording various aspects of the process, and during verification, in-toto applies the policies in the layout against the set of attestations produced during the execution of the supply chain
https://slsa.dev/blog/2023/05/in-toto-and-slsa
Можно попробовать поиграться самому на примере
https://in-toto.io/docs/demo/
Имплементации
https://github.com/in-toto/in-toto-java
https://github.com/in-toto/in-toto-golang
Репа с доработками и предложениями
https://github.com/in-toto/ITE/
На 4 скрине пример, link-файла, который является одним из этапов общей цепочки аттестации. В нём видно команду и файлы, которые участвуют в одном из шагов
Дальнейшим развитием этого подхода является включение аттестации in-toto в pipeline с дополнительной проверочной информацией - SBOMit (https://sbomit.dev/ + 3 скрин)
> Once an SBOMit document is produced, clients can perform extensive verification of the document in order to get a high degree of assurance about the software’s integrity. For example, a client could verify that the steps described in the document indeed took place; ensure the identity of who performed a particular step by inspecting link metadata; or ensure that all the steps indeed led to the final SBOM described by the SBOMit document.
https://openssf.org/blog/2024/06/26/a-deep-dive-into-sbomit-and-attestations/
Попробовать можно тут
- Recursively collects all system calls made during the compilation of your project.
- Parses the packages your project utilized during compilation.
- Generates an in-toto attestation for your project, detailing the materials used and the output products.
https://github.com/SBOMit/SBOMit-strace-prototype
В целом этот подход хорошо рассказан в докладе (откуда и взяты первые три скрина)
Your SBOM Is Lying To You – Let’s Make It Honest
https://www.youtube.com/watch?v=4ZsdNUJyZXU
Российские решения с которыми сам работал и/или пересекался и тоже относятся, по моему мнению, к тематике поста
- Buildography (ИСП РАН, https://www.ispras.ru/technologies/buildography/) - отслеживает системные вызовы в процессе сборки и собирает данные о файлах/каталогах, аргументы, вызываемые программы и т.д. и сохраняет всю собранную информацию для дальнейших проверок.
- sbom-checker (open source, https://gitlab.community.ispras.ru/sdl-tools/sbom-checker) - набор утилит, который позволяет обновить и проверить SBOM'ы согласно требованиям ФСТЭК. Главное в скриптах, по тематике поста, это то, что можно получить и провалидировать информацию по репозиториям зависимостей.
- CodeScoring (https://codescoring.ru/) - платформа в целом посвящённая SCA: построение SBOM'ов, построение цепочки зависимостей, защита от supply chain атак и т.д.
Если кто-то ещё что-то хочет добавить или поправить пишите в комменты или в личку.
👍16❤2🔥2
Выложены доклады с Open Source Summit Europe 2025 (288 докладов 🫡 )
Плейлист
https://www.youtube.com/playlist?list=PLbzoR-pLrL6qKwLt8A787ggMLHNivOHve
Программа тут
https://osseu2025.sched.com/
Плейлист
https://www.youtube.com/playlist?list=PLbzoR-pLrL6qKwLt8A787ggMLHNivOHve
Программа тут
https://osseu2025.sched.com/
👍12🔥1
Forwarded from Neural Shit
Увидел в твиттере интересный тред: чувак расписал, как через ChatGPT можно увести всю вашу приватную переписку, имея на руках только ваш email.
Всё дело в новой фиче — поддержке MCP (Model Context Protocol). Теперь ChatGPT может коннектиться к вашему Gmail, Календарю и другим сервисам, чтобы "лучше помогать".
Но помощь работает в обе стороны. Вот как это паботает:
1. Вам на почту кидают календарное приглашение. Его даже не нужно принимать.
2. В описании встречи — джейлбрейк-промпт, который перехватывает управление ChatGPT.
3. Вы просите нейронку "посмотреть расписание на день".
4. ChatGPT читает ваше расписание, видит инструкции мамкиных хакеров и выполняет их: ищет в вашей почте письма с паролями, выписки из банка и тут же пересылает их на левый email.
Пока что OpenAI включает эту функцию только в "режиме разработчика" с ручным подтверждением каждого доступа. Но кто читает эти окна? Все по классике жмакают "Разрешить", "Разрешить", "Разрешить".
Сам еще пока не проверял, вечером гляну, но будьте аккуратны.
Оригинал треда тут.
Всё дело в новой фиче — поддержке MCP (Model Context Protocol). Теперь ChatGPT может коннектиться к вашему Gmail, Календарю и другим сервисам, чтобы "лучше помогать".
Но помощь работает в обе стороны. Вот как это паботает:
1. Вам на почту кидают календарное приглашение. Его даже не нужно принимать.
2. В описании встречи — джейлбрейк-промпт, который перехватывает управление ChatGPT.
3. Вы просите нейронку "посмотреть расписание на день".
4. ChatGPT читает ваше расписание, видит инструкции мамкиных хакеров и выполняет их: ищет в вашей почте письма с паролями, выписки из банка и тут же пересылает их на левый email.
Пока что OpenAI включает эту функцию только в "режиме разработчика" с ручным подтверждением каждого доступа. Но кто читает эти окна? Все по классике жмакают "Разрешить", "Разрешить", "Разрешить".
Сам еще пока не проверял, вечером гляну, но будьте аккуратны.
Оригинал треда тут.
X (formerly Twitter)
Eito Miyamura | 🇯🇵🇬🇧 (@Eito_Miyamura) on X
We got ChatGPT to leak your private email data 💀💀
All you need? The victim's email address. ⛓️💥🚩📧
On Wednesday, @OpenAI added full support for MCP (Model Context Protocol) tools in ChatGPT. Allowing ChatGPT to connect and read your Gmail, Calendar, Sharepoint…
All you need? The victim's email address. ⛓️💥🚩📧
On Wednesday, @OpenAI added full support for MCP (Model Context Protocol) tools in ChatGPT. Allowing ChatGPT to connect and read your Gmail, Calendar, Sharepoint…
😁22🔥6❤3🤩3👍2🤣2
Релиз пакетного менеджера RPM 6.0
https://www.opennet.ru/opennews/art.shtml?num=63925
> Версии RPM 5 пропущена для исключения пересечений с проектом RPM5, который не связан с RPM от Red Hat и развивался независимыми разработчиками.
Вот это я пониманию внимание к деталям
> В разработке разрешено использование языка C++ (C++20), а не только языка Си.
Удивительно, что не Rust 🌝
А ещё RPM теперь знает про "Эльбрус" (e2k)
https://github.com/rpm-software-management/rpm/commit/703b2933483c6dacb59e5868e54ac4ddfbd2bfea
Оригинал
[Rpm-announce] RPM 6.0.0 released!
https://lists.rpm.org/pipermail/rpm-announce/2025-September/000121.html
https://www.opennet.ru/opennews/art.shtml?num=63925
> Версии RPM 5 пропущена для исключения пересечений с проектом RPM5, который не связан с RPM от Red Hat и развивался независимыми разработчиками.
Вот это я пониманию внимание к деталям
> В разработке разрешено использование языка C++ (C++20), а не только языка Си.
Удивительно, что не Rust 🌝
А ещё RPM теперь знает про "Эльбрус" (e2k)
https://github.com/rpm-software-management/rpm/commit/703b2933483c6dacb59e5868e54ac4ddfbd2bfea
Оригинал
[Rpm-announce] RPM 6.0.0 released!
https://lists.rpm.org/pipermail/rpm-announce/2025-September/000121.html
🎉18👍6🗿4👎2🥴2❤1
Forwarded from Linux Kernel Security (Andrey Konovalov)
USB HID info-leak exploit for CVE-2025-38494/CVE-2025-38495
Exploit by Andrey Konovalov for an integer underflow bug in the HID subsystem that allows leaking up to 64 KB of kernel memory over USB.
The bug is still not fixed in the Pixel and Ubuntu kernels.
Exploit by Andrey Konovalov for an integer underflow bug in the HID subsystem that allows leaking up to 64 KB of kernel memory over USB.
The bug is still not fixed in the Pixel and Ubuntu kernels.
🔥18👍5🥰3😱3
Есть такой популярный в узких кругах инструмент Valgrind
https://valgrind.org/docs/manual/QuickStart.html
Создан он для того, чтобы искать утечки памяти, оценивать управление памятью и в целом профилировать её.
О Valgrind я упоминал ранее
https://www.tgoop.com/tech_b0lt_Genona/4832
https://www.tgoop.com/tech_b0lt_Genona/5340
Чаще всего, из того что я видел, Valgrind использовался для программ написанных на C\C++. Это и логично учитывая, сколько проблем там возникает из-за работы с памятью.
И тут ВНЕЗАПНО11!! его поддержку завезли в Go.
Вот обсуждение из 2010 года (самое раннее, которое нашёл), где интересуются, а есть ли что-то похожее для Go
https://groups.google.com/g/golang-nuts/c/Vy5dDw0-fCY
Также я находил посты в которых пытались дебажить и Go-шный софт
Вот, например
Hunting down a C memory leak in a Go program
https://zendesk.engineering/hunting-down-a-c-memory-leak-in-a-go-program-2d08b24b617d
Но там возникали проблемы
> Our app is actually correctly freeing it’s “leaked” memory before it exits. Valgrind produces its leak report at the end of program execution by comparing what it gave out by malloc to what it received back by free, and printing out any unpaired malloc invocations. However, if our app actually does call free on all its memory before terminating, then Valgrind won’t see a leak, even if the actual amount of memory first allocated is totally unbounded!
> When we correctly destroy the librdkafka handle during app shutdown, however, all the memory from this queue gets released: Valgrind never saw a leak.
Есть посты о том, как успешно применили Valgrind, но как по мне эта успешность весьма условная: типа мы видим что что-то не так, но что бы понять нам надо взять что-то ещё. Киньте ссылок в комменты, если есть реально успешные случаи.
Вот обсуждение в issue с пояснениями
> Go doesn't support valgrind, but does support asan, msan, and tsan, which work with clang, and perhaps gcc.
valgrind fails
https://github.com/golang/go/issues/60600
Вот объяснение в proposal'е (на который собственно и ссылается имплементация https://go-review.googlesource.com/c/go/+/674077)
> Go uses mmap (which Valgrind understands) to map a large memory region and then uses our own allocator to handle allocating objects from that region. We allocate both the heap, and individual stacks, from this region. This behavior confuses Valgrind.
add valgrind hints to the runtime under special build mode
https://github.com/golang/go/issues/73602
Да и вообще, казалось бы, зачем все эти приседания, если есть GC?
Если кратко, то для
- Анализа памяти в runtime
- Проверки и обеспечения константного времени выполнения для криптографии
С первым пунктом всё понятно, а для второго немного пояснений.
Если атакующий может каким-либо образом замерять время которое требуется алгоритму для обработки входных данных, то это может дать "зацепку" для подбора ключа. Соответственно, в proposal'е описывается как Valgrind может помочь в этом
> uninitialized memory taint analysis that Valgrind does looks very similar to how we would want to analyze constant-time code. Namely, we care about conditional instructions that operate on sensitive memory, which Valgrind has all the machinery for, just that it cares about uninitialized memory. We can slightly abuse this Valgrind behavior by simply marking sensitive memory as uninitialized, and seeing if Valgrind ever complains about branching behavior that relies on it
Вот пост из 2010 года про подход
Checking that functions are constant time with Valgrind
https://www.imperialviolet.org/2010/04/01/ctgrind.html
Вот большой пост от BearSSL, если кому-то интересно будет углубиться в эту тему
Why Constant-Time Crypto?
https://bearssl.org/constanttime.html
В целом, конечно, штука хорошая и должна помочь сделать софт на Go лучше и стабильней.
Обсуждение на HN
https://news.ycombinator.com/item?id=45344708
ЗЫ Поправьте меня, но я не вижу тестов в патче (см. скрин) 🌝
https://valgrind.org/docs/manual/QuickStart.html
Создан он для того, чтобы искать утечки памяти, оценивать управление памятью и в целом профилировать её.
О Valgrind я упоминал ранее
https://www.tgoop.com/tech_b0lt_Genona/4832
https://www.tgoop.com/tech_b0lt_Genona/5340
Чаще всего, из того что я видел, Valgrind использовался для программ написанных на C\C++. Это и логично учитывая, сколько проблем там возникает из-за работы с памятью.
И тут ВНЕЗАПНО11!! его поддержку завезли в Go.
Вот обсуждение из 2010 года (самое раннее, которое нашёл), где интересуются, а есть ли что-то похожее для Go
https://groups.google.com/g/golang-nuts/c/Vy5dDw0-fCY
Также я находил посты в которых пытались дебажить и Go-шный софт
Вот, например
Hunting down a C memory leak in a Go program
https://zendesk.engineering/hunting-down-a-c-memory-leak-in-a-go-program-2d08b24b617d
Но там возникали проблемы
> Our app is actually correctly freeing it’s “leaked” memory before it exits. Valgrind produces its leak report at the end of program execution by comparing what it gave out by malloc to what it received back by free, and printing out any unpaired malloc invocations. However, if our app actually does call free on all its memory before terminating, then Valgrind won’t see a leak, even if the actual amount of memory first allocated is totally unbounded!
> When we correctly destroy the librdkafka handle during app shutdown, however, all the memory from this queue gets released: Valgrind never saw a leak.
Есть посты о том, как успешно применили Valgrind, но как по мне эта успешность весьма условная: типа мы видим что что-то не так, но что бы понять нам надо взять что-то ещё. Киньте ссылок в комменты, если есть реально успешные случаи.
Вот обсуждение в issue с пояснениями
> Go doesn't support valgrind, but does support asan, msan, and tsan, which work with clang, and perhaps gcc.
valgrind fails
https://github.com/golang/go/issues/60600
Вот объяснение в proposal'е (на который собственно и ссылается имплементация https://go-review.googlesource.com/c/go/+/674077)
> Go uses mmap (which Valgrind understands) to map a large memory region and then uses our own allocator to handle allocating objects from that region. We allocate both the heap, and individual stacks, from this region. This behavior confuses Valgrind.
add valgrind hints to the runtime under special build mode
https://github.com/golang/go/issues/73602
Да и вообще, казалось бы, зачем все эти приседания, если есть GC?
Если кратко, то для
- Анализа памяти в runtime
- Проверки и обеспечения константного времени выполнения для криптографии
С первым пунктом всё понятно, а для второго немного пояснений.
Если атакующий может каким-либо образом замерять время которое требуется алгоритму для обработки входных данных, то это может дать "зацепку" для подбора ключа. Соответственно, в proposal'е описывается как Valgrind может помочь в этом
> uninitialized memory taint analysis that Valgrind does looks very similar to how we would want to analyze constant-time code. Namely, we care about conditional instructions that operate on sensitive memory, which Valgrind has all the machinery for, just that it cares about uninitialized memory. We can slightly abuse this Valgrind behavior by simply marking sensitive memory as uninitialized, and seeing if Valgrind ever complains about branching behavior that relies on it
Вот пост из 2010 года про подход
Checking that functions are constant time with Valgrind
https://www.imperialviolet.org/2010/04/01/ctgrind.html
Вот большой пост от BearSSL, если кому-то интересно будет углубиться в эту тему
Why Constant-Time Crypto?
https://bearssl.org/constanttime.html
В целом, конечно, штука хорошая и должна помочь сделать софт на Go лучше и стабильней.
Обсуждение на HN
https://news.ycombinator.com/item?id=45344708
ЗЫ Поправьте меня, но я не вижу тестов в патче (см. скрин) 🌝
🔥17👍8⚡3❤2👎1
Четверг, а значит время проектов от подписчиков! 🌝
Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - https://www.tgoop.com/tech_b0lt_Genona/4983
Слово автору @viqxq
---
Всем привет.
Меня зовут Ви, и я делаю свою операционную систему — Amadeus (https://www.tgoop.com/amadeus_eco_tg). Я активно пишу про это в своём канале.
Моя ОС — это не очередной дистрибутив Linux. Это попытка сделать нечто принципиально новое, чего раньше никто не делал в рамках проекта одного человека:
* Своя архитектура с нуля. Ядро Amadeus — это не монолит и не микроядро в классическом понимании. Это гибридная система, где все компоненты (включая драйверы) общаются через сверхбыстрый IPC на общей памяти, что сводит к минимуму накладные расходы и переключения контекста. Системные вызовы как устаревшая концепция — отправлены в отставку.
* Бинарная совместимость без компромиссов. Я не хочу заставлять мир переписывать софт под себя. Поэтому в Amadeus можно будет запускать нативные приложения Linux и Windows через механизм «вложенных ядер» (nested kernels). Ядро эмулирует API чужой ОС, но преобразует его в свой высокопроизводительный IPC. Цель — работать быстрее, чем Wine и быстрее нативного Linux в некоторых сценариях.
* Написана полностью на Rust. Это не просто модно. Это даёт беспрецедентную надежность для системы такого уровня. Безопасность памяти на уровне компилятора + полный контроль над железом — вот наш девиз.
* Драйверы? Не проблема. Я разработал инструмент для автоматического портирования драйверов из ядра Linux в нативную среду Amadeus. Это решает главную проблему всех новых ОС — поддержку железа.
* Безопасность и изоляция. Падение любого драйвера или сервиса не уронит всю систему. Они работают в изолированных пространствах пользователя. Никаких SUID-бинарей. Современная модель прав доступа, а не устаревшая UNIX-модель.
* Производительность как религия. Вся архитектура заточена под скорость: zero-copy IPC, акцент на асинхронность, собственные легковесные реализации libc и системных библиотек.
Зачем мне это всё?
* Хочется иметь «правильно» устроенную ОС. Без груза обратной совместимости, с современными решениями под капотом.
* Это вызов. Доказать, что один человек с упорством и правильным подходом может бросить вызов индустриальным гигантам.
* Создать платформу для будущего. Amadeus — это не просто ядро. Это мета-платформа, на основе которой можно будет создавать другие ОС с совместимостью нужной вам экосистемы.
Зачем мне этот анонс?
Мне не хватает сообщества. Я ищу единомышленников — низкоуровневых программистов, энтузиастов Rust, специалистов по виртуализации и просто тех, кому интересно заглянуть под капот современной операционки и возможно, принять участие в её создании.
Проект уже работает на реальном железе, загружается через bootboot, и сейчас идёт активная фаза разработки базовых подсистем.
Присоединяйтесь! Ваша помощь в портировании софта, тестировании, документации или просто распространении информации бесценна.
Канал с новостями: https://www.tgoop.com/amadeus_eco_tg
Давайте вместе строить ОС будущего.
---
Слово автору @viqxq
---
Всем привет.
Меня зовут Ви, и я делаю свою операционную систему — Amadeus (https://www.tgoop.com/amadeus_eco_tg). Я активно пишу про это в своём канале.
Моя ОС — это не очередной дистрибутив Linux. Это попытка сделать нечто принципиально новое, чего раньше никто не делал в рамках проекта одного человека:
* Своя архитектура с нуля. Ядро Amadeus — это не монолит и не микроядро в классическом понимании. Это гибридная система, где все компоненты (включая драйверы) общаются через сверхбыстрый IPC на общей памяти, что сводит к минимуму накладные расходы и переключения контекста. Системные вызовы как устаревшая концепция — отправлены в отставку.
* Бинарная совместимость без компромиссов. Я не хочу заставлять мир переписывать софт под себя. Поэтому в Amadeus можно будет запускать нативные приложения Linux и Windows через механизм «вложенных ядер» (nested kernels). Ядро эмулирует API чужой ОС, но преобразует его в свой высокопроизводительный IPC. Цель — работать быстрее, чем Wine и быстрее нативного Linux в некоторых сценариях.
* Написана полностью на Rust. Это не просто модно. Это даёт беспрецедентную надежность для системы такого уровня. Безопасность памяти на уровне компилятора + полный контроль над железом — вот наш девиз.
* Драйверы? Не проблема. Я разработал инструмент для автоматического портирования драйверов из ядра Linux в нативную среду Amadeus. Это решает главную проблему всех новых ОС — поддержку железа.
* Безопасность и изоляция. Падение любого драйвера или сервиса не уронит всю систему. Они работают в изолированных пространствах пользователя. Никаких SUID-бинарей. Современная модель прав доступа, а не устаревшая UNIX-модель.
* Производительность как религия. Вся архитектура заточена под скорость: zero-copy IPC, акцент на асинхронность, собственные легковесные реализации libc и системных библиотек.
Зачем мне это всё?
* Хочется иметь «правильно» устроенную ОС. Без груза обратной совместимости, с современными решениями под капотом.
* Это вызов. Доказать, что один человек с упорством и правильным подходом может бросить вызов индустриальным гигантам.
* Создать платформу для будущего. Amadeus — это не просто ядро. Это мета-платформа, на основе которой можно будет создавать другие ОС с совместимостью нужной вам экосистемы.
Зачем мне этот анонс?
Мне не хватает сообщества. Я ищу единомышленников — низкоуровневых программистов, энтузиастов Rust, специалистов по виртуализации и просто тех, кому интересно заглянуть под капот современной операционки и возможно, принять участие в её создании.
Проект уже работает на реальном железе, загружается через bootboot, и сейчас идёт активная фаза разработки базовых подсистем.
Присоединяйтесь! Ваша помощь в портировании софта, тестировании, документации или просто распространении информации бесценна.
Канал с новостями: https://www.tgoop.com/amadeus_eco_tg
Давайте вместе строить ОС будущего.
---
👏26🔥17❤9😁9👎6👀4👍3❤🔥2🤔2👌2🤩1
Технологический Болт Генона
В докладе на NeoQUEST-2025 (https://www.tgoop.com/tech_b0lt_Genona/5705), я затрону тему, а какие есть вообще идеи и подходы как выстроить процесс так, что бы полученным SBOM'ам можно было бы доверять. Напомню, что SBOM очень важен, если вы хотите понимать, что "приехало"…
Что в образе тебе моём?_neoquest-2025.pdf
9.4 MB
Слайды с моего сегодняшнего доклада на NeoQUEST 2025
Название: "Что в образе тебе моём?"
В рамках доклада попробуем разобраться каким образом строится SBOM контейнера, как работают сканеры уязвимостей для docker-образов, почему не всегда стоит доверять результатам сканеров и что можно с этим сделать.
Будет ли запись не знаю, но если будет, то обязательно выложу.
Название: "Что в образе тебе моём?"
В рамках доклада попробуем разобраться каким образом строится SBOM контейнера, как работают сканеры уязвимостей для docker-образов, почему не всегда стоит доверять результатам сканеров и что можно с этим сделать.
Будет ли запись не знаю, но если будет, то обязательно выложу.
👍12🔥6❤4⚡1
postgresql18_ga_new_features_en_20250926-1.pdf
1.5 MB
На днях вышел PostgreSQL 18
https://www.postgresql.org/about/news/postgresql-18-released-3142/
Новость прекрасна сама по себе, тут обсуждать нечего, но вы просто оцените
> PostgreSQL 18 New Features With Examples
> New Features
> 100 страниц
Всем бы такие релизы завозить 🌝
https://www.postgresql.org/about/news/postgresql-18-released-3142/
Новость прекрасна сама по себе, тут обсуждать нечего, но вы просто оцените
> PostgreSQL 18 New Features With Examples
> New Features
> 100 страниц
Всем бы такие релизы завозить 🌝
🔥38😁5
Технологический Болт Генона
Представлены правила для AI-ассистентов, применяемых при разработке ядра Linux https://www.opennet.ru/opennews/art.shtml?num=63631 Определены следующие ключевые принципы для AI: - Перед созданием изменений необходимо прочитать документацию и следовать изложенным…
Помните правила для AI-ассистентов, применяемых при разработке ядра Linux?
Вот тут можно почитать, если кто-то пропустил
https://www.tgoop.com/tech_b0lt_Genona/5507
Теперь свои правила выкатила Fedora
- Разработчик, использующий AI-инструменты при подготовке изменений для Fedora, несёт ответственность за переданное изменение и обязан изучить, проверить и протестировать его. Сгенерированное AI-ассистентом содержимое должно рассматриваться как рекомендация, а не финальный код или текст. Отправка непроверенного или низкокачественного AI-контента недопустима и создаёт дополнительную нагрузку на рецензирующих изменения.
- При передаче изменений, подготовленных с использованием AI-инструментов, в примечании к коммиту или pull-запросу требуется добавлять тег "Assisted-by: название AI-ассистента".
- Поощряется использование AI‑инструментов для преодоления языкового барьера или пояснения своих мыслей при общении.
- При рецензировании чужих изменений рекомендовано ограничить использование AI-инструментов - можно использовать AI для помощи в формировании отзывов, но нельзя для полной автоматизации процесса рецензирования. Окончательное решение за одобрением и отклонением изменений должен принимать человек.
- При управлении проектом AI-инструменты могут применяться для автоматизации рутинных задач, таких как фильтрация спама и создание заметок, но их использование признано недопустимым в таких вопросах, как оценка жалоб на нарушение кодекса поведения, запросов финансирования, выставление кандидатов на руководящие должности и подготовка докладов для конференций.
- Предлагаемые в дистрибутиве AI-возможности, особенно отправляющие данные на внешние серверы, должны по умолчанию быть отключены и активироваться после информирования и получения согласия у пользователя (opt-in). Из полезных применений AI-инструментов называется их задействование в средствах для людей с ограниченными возможностями, например, для перевода, транскрипции и синтеза речи.
- Поощряется создание пакетов с инструментами и фреймворками, необходимыми для исследований и разработок в области искусственного интеллекта.
- Генерируемые проектом данные разрешено использовать в обучении AI-моделей при соблюдении лицензий и упоминании авторства. Запрещён агрессивный скрапинг данных, создающий большую нагрузку на инфраструктуру (для предоставления эффективного доступа к данным рекомендовано связаться с командой, отвечающей за инфраструктуру).
Правила использования AI-инструментов при разработке Fedora Linux
https://www.opennet.ru/opennews/art.shtml?num=63956
Оригинал
Council Policy Proposal: Policy on AI-Assisted Contributions
https://discussion.fedoraproject.org/t/council-policy-proposal-policy-on-ai-assisted-contributions/165092
Вот тут можно почитать, если кто-то пропустил
https://www.tgoop.com/tech_b0lt_Genona/5507
Теперь свои правила выкатила Fedora
- Разработчик, использующий AI-инструменты при подготовке изменений для Fedora, несёт ответственность за переданное изменение и обязан изучить, проверить и протестировать его. Сгенерированное AI-ассистентом содержимое должно рассматриваться как рекомендация, а не финальный код или текст. Отправка непроверенного или низкокачественного AI-контента недопустима и создаёт дополнительную нагрузку на рецензирующих изменения.
- При передаче изменений, подготовленных с использованием AI-инструментов, в примечании к коммиту или pull-запросу требуется добавлять тег "Assisted-by: название AI-ассистента".
- Поощряется использование AI‑инструментов для преодоления языкового барьера или пояснения своих мыслей при общении.
- При рецензировании чужих изменений рекомендовано ограничить использование AI-инструментов - можно использовать AI для помощи в формировании отзывов, но нельзя для полной автоматизации процесса рецензирования. Окончательное решение за одобрением и отклонением изменений должен принимать человек.
- При управлении проектом AI-инструменты могут применяться для автоматизации рутинных задач, таких как фильтрация спама и создание заметок, но их использование признано недопустимым в таких вопросах, как оценка жалоб на нарушение кодекса поведения, запросов финансирования, выставление кандидатов на руководящие должности и подготовка докладов для конференций.
- Предлагаемые в дистрибутиве AI-возможности, особенно отправляющие данные на внешние серверы, должны по умолчанию быть отключены и активироваться после информирования и получения согласия у пользователя (opt-in). Из полезных применений AI-инструментов называется их задействование в средствах для людей с ограниченными возможностями, например, для перевода, транскрипции и синтеза речи.
- Поощряется создание пакетов с инструментами и фреймворками, необходимыми для исследований и разработок в области искусственного интеллекта.
- Генерируемые проектом данные разрешено использовать в обучении AI-моделей при соблюдении лицензий и упоминании авторства. Запрещён агрессивный скрапинг данных, создающий большую нагрузку на инфраструктуру (для предоставления эффективного доступа к данным рекомендовано связаться с командой, отвечающей за инфраструктуру).
Правила использования AI-инструментов при разработке Fedora Linux
https://www.opennet.ru/opennews/art.shtml?num=63956
Оригинал
Council Policy Proposal: Policy on AI-Assisted Contributions
https://discussion.fedoraproject.org/t/council-policy-proposal-policy-on-ai-assisted-contributions/165092
👍20🔥4❤3😁1
Пополнение
A Lite Version of Kubernetes in Rust
https://github.com/rk8s-dev/rk8s/
rk8s is a lightweight, Kubernetes-compatible container orchestration system built on top of Youki, implementing the Container Runtime Interface (CRI) with support for three primary workload types: single containers, Kubernetes-style pods, and Docker Compose-style multi-container applications.
Core Components
- RKL (Container Runtime Interface) - The primary runtime component supporting CLI operations and daemon mode
- RKS (Control Plane) - Kubernetes-like control plane combining API server, scheduler, and controller functionality
- Xline - etcd-compatible distributed storage for cluster state
- Networking - CNI-compliant networking with libbridge plugin
Supported Workload Types
- Single Container Workloads
- Kubernetes-Style Pods
- Docker Compose-Style Applications
Описание RKL
https://github.com/rk8s-dev/rk8s/tree/main/project/rkl
+
RKL: A Docker-like Command-line Interface Built in Rust
https://r2cn.dev/blog/rkl-a-docker-like-command-line-interface-built-in-rust
A Lite Version of Kubernetes in Rust
https://github.com/rk8s-dev/rk8s/
rk8s is a lightweight, Kubernetes-compatible container orchestration system built on top of Youki, implementing the Container Runtime Interface (CRI) with support for three primary workload types: single containers, Kubernetes-style pods, and Docker Compose-style multi-container applications.
Core Components
- RKL (Container Runtime Interface) - The primary runtime component supporting CLI operations and daemon mode
- RKS (Control Plane) - Kubernetes-like control plane combining API server, scheduler, and controller functionality
- Xline - etcd-compatible distributed storage for cluster state
- Networking - CNI-compliant networking with libbridge plugin
Supported Workload Types
- Single Container Workloads
- Kubernetes-Style Pods
- Docker Compose-Style Applications
Описание RKL
https://github.com/rk8s-dev/rk8s/tree/main/project/rkl
+
RKL: A Docker-like Command-line Interface Built in Rust
https://r2cn.dev/blog/rkl-a-docker-like-command-line-interface-built-in-rust
💊14🔥13👀4❤1😁1🤡1
This media is not supported in your browser
VIEW IN TELEGRAM
Дельфинарий на @und3rc0nf_chat 🐬
🐳17😁8👎2🔥2🤡1
Никогда такого не было и вот опять
> On June 6, I accidentally pushed my API key to GitHub and I believed the repository was private (it was only visible in one commit, which I unfortunately didn't notice). At the time I didn't realize it, and since it was summer break, I wasn't even checking my student email. Then, on September 7, another GitHub user sent me a notification that my key had been public for a long time and others were abusing it. By that time, the damage was already done. When I checked my account, there was a $55,444 in total. After that, I immediately revoked the Gemini API key.
Но закончилось всё хорошо
> I want to share some great news with you all. Following communication with the Google Cloud Billing Specialists, my case was reviewed again and the total outstanding balance has been completely waived !
Student hit with a $55,444.78 Google Cloud bill after Gemini API key leaked on GitHub
https://www.reddit.com/r/googlecloud/comments/1noctxi/student_hit_with_a_5544478_google_cloud_bill/
https://www.tgoop.com/mem_b0lt_Genona/182
> On June 6, I accidentally pushed my API key to GitHub and I believed the repository was private (it was only visible in one commit, which I unfortunately didn't notice). At the time I didn't realize it, and since it was summer break, I wasn't even checking my student email. Then, on September 7, another GitHub user sent me a notification that my key had been public for a long time and others were abusing it. By that time, the damage was already done. When I checked my account, there was a $55,444 in total. After that, I immediately revoked the Gemini API key.
Но закончилось всё хорошо
> I want to share some great news with you all. Following communication with the Google Cloud Billing Specialists, my case was reviewed again and the total outstanding balance has been completely waived !
Student hit with a $55,444.78 Google Cloud bill after Gemini API key leaked on GitHub
https://www.reddit.com/r/googlecloud/comments/1noctxi/student_hit_with_a_5544478_google_cloud_bill/
https://www.tgoop.com/mem_b0lt_Genona/182
Telegram
Мемный Болт Генона
😁26🤡2❤1🤝1
Наша постоянная, но подзабытая рубрика
Обновляем гитлабчики 💅💅💅
В этот раз Critical нет, но есть интересный High
CVE-2025-10858 - Denial of Service issue when uploading specifically crafted JSON files impacts GitLab CE/EE
GitLab has remediated an issue that could have allowed an unauthenticated user to render a GitLab instance unresponsive to legitimate users by sending specifically crafted JSON files.
issue пока приватная
https://gitlab.com/gitlab-org/gitlab/-/issues/570034
Описания
https://www.cve.org/CVERecord?id=CVE-2025-10858
Ну и XSS тоже High (сдали через Bug Bounty)
CVE-2025-9642 - Cross-site scripting issue in Script Gadgets impacts GitLab CE/EE
GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute actions on behalf of other users by injecting malicious content.
issue пока приватная
https://gitlab.com/gitlab-org/gitlab/-/issues/566505
Описание
https://www.cve.org/CVERecord?id=CVE-2025-9642
Пост
GitLab Patch Release: 18.4.1, 18.3.3, 18.2.7
https://about.gitlab.com/releases/2025/09/25/patch-release-gitlab-18-4-1-released/
Обновляем гитлабчики 💅💅💅
В этот раз Critical нет, но есть интересный High
CVE-2025-10858 - Denial of Service issue when uploading specifically crafted JSON files impacts GitLab CE/EE
GitLab has remediated an issue that could have allowed an unauthenticated user to render a GitLab instance unresponsive to legitimate users by sending specifically crafted JSON files.
issue пока приватная
https://gitlab.com/gitlab-org/gitlab/-/issues/570034
Описания
https://www.cve.org/CVERecord?id=CVE-2025-10858
Ну и XSS тоже High (сдали через Bug Bounty)
CVE-2025-9642 - Cross-site scripting issue in Script Gadgets impacts GitLab CE/EE
GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute actions on behalf of other users by injecting malicious content.
issue пока приватная
https://gitlab.com/gitlab-org/gitlab/-/issues/566505
Описание
https://www.cve.org/CVERecord?id=CVE-2025-9642
Пост
GitLab Patch Release: 18.4.1, 18.3.3, 18.2.7
https://about.gitlab.com/releases/2025/09/25/patch-release-gitlab-18-4-1-released/
💅16😁5🙊1
Netflix открыл свою балалайку для обслуживания рабочих процессов (workflow-as-a-service, WAAS)
> It serves thousands of users, including data scientists, data engineers, machine learning engineers, software engineers, content producers, and business analysts, for various use cases. It schedules hundreds of thousands of workflows, millions of jobs every day and operates with a strict SLO even when there are spikes in the traffic.
Maestro: Netflix’s Workflow Orchestrator
https://github.com/Netflix/maestro
И выкатили большой пост с подробностями реализации и работы (удивительно, но в 2025 году запилили на Java 21)
100X Faster: How We Supercharged Netflix Maestro’s Workflow Engine
https://netflixtechblog.com/100x-faster-how-we-supercharged-netflix-maestros-workflow-engine-028e9637f041
Всё не влезет в пост, поэтому оставлю только выводы-заключение
> Despite these challenges, the migration was a success. We migrated over 60,000 active workflows generating over a million data processing tasks daily with almost no user involvement. By observing the flow engine’s lifecycle management latency, we validated a reduction in step launch overhead from around 5 seconds to 50 milliseconds. Workflow start overhead (incurred once per each workflow execution) also improved from 200 milliseconds to 50 milliseconds. Aggregating this over a million daily step executions translates to saving approximately 57 days of flow engine overhead per day, leading to a snappier user experience, more timely workflow status for data practitioners and greater overall task throughput for the same infrastructure scale.
> The architectural evolution of Maestro represents a significant leap in performance, reducing overhead from seconds to milliseconds. This redesign with a stateful actor model not only enhances speed by 100X but also maintains scalability and reliability, ensuring Maestro continues to meet the diverse needs of Netflix’s data and ML workflows.
> Performance matters: Even in a system designed for scale, the speed of individual operations significantly impacts user experience and productivity.
> Simplicity wins: Reducing dependencies and simplifying architecture not only improved performance but also enhanced reliability and maintainability.
> Locality optimizations pay off: Collocating related flows and tasks in the same JVM dramatically reduces overhead from the Maestro engine.
> Modern language features help: Java 21’s virtual threads enabled an elegant actor-based implementation with minimal code complexity and dependencies.
> It serves thousands of users, including data scientists, data engineers, machine learning engineers, software engineers, content producers, and business analysts, for various use cases. It schedules hundreds of thousands of workflows, millions of jobs every day and operates with a strict SLO even when there are spikes in the traffic.
Maestro: Netflix’s Workflow Orchestrator
https://github.com/Netflix/maestro
И выкатили большой пост с подробностями реализации и работы (удивительно, но в 2025 году запилили на Java 21)
100X Faster: How We Supercharged Netflix Maestro’s Workflow Engine
https://netflixtechblog.com/100x-faster-how-we-supercharged-netflix-maestros-workflow-engine-028e9637f041
Всё не влезет в пост, поэтому оставлю только выводы-заключение
> Despite these challenges, the migration was a success. We migrated over 60,000 active workflows generating over a million data processing tasks daily with almost no user involvement. By observing the flow engine’s lifecycle management latency, we validated a reduction in step launch overhead from around 5 seconds to 50 milliseconds. Workflow start overhead (incurred once per each workflow execution) also improved from 200 milliseconds to 50 milliseconds. Aggregating this over a million daily step executions translates to saving approximately 57 days of flow engine overhead per day, leading to a snappier user experience, more timely workflow status for data practitioners and greater overall task throughput for the same infrastructure scale.
> The architectural evolution of Maestro represents a significant leap in performance, reducing overhead from seconds to milliseconds. This redesign with a stateful actor model not only enhances speed by 100X but also maintains scalability and reliability, ensuring Maestro continues to meet the diverse needs of Netflix’s data and ML workflows.
> Performance matters: Even in a system designed for scale, the speed of individual operations significantly impacts user experience and productivity.
> Simplicity wins: Reducing dependencies and simplifying architecture not only improved performance but also enhanced reliability and maintainability.
> Locality optimizations pay off: Collocating related flows and tasks in the same JVM dramatically reduces overhead from the Maestro engine.
> Modern language features help: Java 21’s virtual threads enabled an elegant actor-based implementation with minimal code complexity and dependencies.
👍7