Forwarded from Тысяча фичей
Делюсь тем, как ебашу проекты.
👹 Project Hub 👹 — шаблон репозитория-«кабины» для ведения проекта с Claude Code: глоссарий, инварианты, ADR-решения, живой статус, каталог сервисов, подключение реп симлинками, параллельные агенты в git worktree, safety-hook перед прод-командами.
Скопируй промпт и вставь в Claude Code — расспросит про проект и соберёт хаб под тебя:
https://github.com/PakhomovAlexander/project-hub
Пост, где я рассказываю как это работает: https://t.me/toxic_enterprise/369
Скопируй промпт и вставь в Claude Code — расспросит про проект и соберёт хаб под тебя:
Create a project hub from this template: https://github.com/PakhomovAlexander/project-hub
https://github.com/PakhomovAlexander/project-hub
Пост, где я рассказываю как это работает: https://t.me/toxic_enterprise/369
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - PakhomovAlexander/project-hub: A template for running a project with Claude Code as a 'cockpit' repo: ubiquitous-language…
A template for running a project with Claude Code as a 'cockpit' repo: ubiquitous-language glossary, invariants, ADRs, a living tracker, repo linking, and a prompt-before-risky-comm...
Self-host and scale web apps without Kubernetes complexity | Uncloud
https://uncloud.run/
https://uncloud.run/
Uncloud
Self-host and scale web apps without Kubernetes complexity | Uncloud
Take your Docker Compose apps to production with zero-downtime deployments, automatic HTTPS, and cross-machine scaling. Self-hosting made reliable without the complexity.
masterking32/MasterDnsVPN: Advanced DNS tunneling VPN for censorship bypass, optimized beyond DNSTT and SlipStream with low-overhead ARQ, resolver load balancing, high packet-loss stability and speed.
https://github.com/masterking32/MasterDnsVPN
https://github.com/masterking32/MasterDnsVPN
GitHub
GitHub - masterking32/MasterDnsVPN: Advanced DNS tunneling VPN for censorship bypass, optimized beyond DNSTT and SlipStream with…
Advanced DNS tunneling VPN for censorship bypass, optimized beyond DNSTT and SlipStream with low-overhead ARQ, resolver load balancing, high packet-loss stability and speed. - masterking32/MasterDn...
Exploring Windows UAC Bypasses: Techniques and Detection Strategies — Elastic Security Labs
https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies
https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies
www.elastic.co
Exploring Windows UAC Bypasses: Techniques and Detection Strategies — Elastic Security Labs
In this research article, we will take a look at a collection of UAC bypasses, investigate some of the key primitives they depend on, and explore detection opportunities.
Forwarded from Hacker News
Networkflowalgs
Network Flow Algorithms
Forwarded from El Monitorro - Feed Reader
Phoronix
ReactOS Implements First Windows NT6 System Call In Step Toward Vista Compatibility
The ReactOS project that is striving to be the "open-source Windows" with Windows driver and software binary compatibility hit another milestone today. ReactOS to date has primarily targeted Windows NT 5.2 as the architecture from Windows XP and Windows Server 2003 but with an eye toward Windows NT 6.0 for Windows Vista and later compatibility with software. ReactOS has now landed their first NT6 system call...
2026-07-03 06:22:38 +06:00
https://www.phoronix.com/news/ReactOS-First-NT6-Syscall
ReactOS Implements First Windows NT6 System Call In Step Toward Vista Compatibility
The ReactOS project that is striving to be the "open-source Windows" with Windows driver and software binary compatibility hit another milestone today. ReactOS to date has primarily targeted Windows NT 5.2 as the architecture from Windows XP and Windows Server 2003 but with an eye toward Windows NT 6.0 for Windows Vista and later compatibility with software. ReactOS has now landed their first NT6 system call...
2026-07-03 06:22:38 +06:00
https://www.phoronix.com/news/ReactOS-First-NT6-Syscall
Phoronix
ReactOS Implements First Windows NT6 System Call In Step Toward Vista Compatibility
The ReactOS project that is striving to be the 'open-source Windows' with Windows driver and software binary compatibility hit another milestone today
Modernizing Lambda + S3 workloads with Amazon S3 Files | AWS Compute Blog
https://aws.amazon.com/blogs/compute/modernizing-lambda-s3-workloads-with-amazon-s3-files/
https://aws.amazon.com/blogs/compute/modernizing-lambda-s3-workloads-with-amazon-s3-files/
Amazon
Modernizing Lambda + S3 workloads with Amazon S3 Files | Amazon Web Services
Learn how Amazon S3 Files simplifies Lambda functions by eliminating transfer code and /tmp constraints. See three modernization patterns with code examples for image processing, ETL pipelines, and multi-agent AI workloads. AWS Lambda functions that interact…
Forwarded from TheCacheWorks
Линия жизни
Проблема DF (double free)/UAF (use-after-free) в действительности глубже, чем может показаться.
Причем эта кроличья нора мало того, что бездонная - она тщательно замаскирована и угодить в нее можно буквально где угодно и почти на каждом шагу.
Она не очень точно называется владением памятью, более точно назвать ее проблемой висящих указателей (dangling pointers), что, в свою очередь, тоже не совсем точно.
Если объяснять совсем на пальцах, в языках с ручным управлением памятью, память - разумеется - не может знать, сколько на нее смотрит указателей из разных мест кода. Сырые указатели штука тупая и циничная. Это просто адрес ячейки или блока.
Считать указатели в обертках (
Проблема усугубляется тем фактом, что в том же C++ на сырых указателях под капотом много чего строится - наследование, полиморфизм, vtable - и заменить всё это на умные указатели (которые тоже вовсе не панацея) или на ссылки не получится по определению, совместимость и гигатонны работающего кода. Что касается Си, то там указатели буквально фундамент всей и всяческой алгоритмики.
Суть проблемы, однако же, даже не в этом. А в том, что нижележащий слой - libC, системные и мажорные аллокаторы - проблему прячут и прячут глубоко в своем бэкэнде.
Теоретически аллокатор должен предоставлять один железный контракт - после free() память считается не твоей, всё, забудь о ней. Сразу же, незамедлительно, как только произошел возврат из free(). И правильно занулить указатель, потому что повторный free(NULL) - по POSIX - не бросит исключения или сегфолта и просто молча ничего не выполнит. Это не абсолютная защита, но хотя бы кое-что.
На практике освобожденный блок может достаточно долго болтаться в бэкэнде аллокатора и любые другие указатели (о которых никто, кроме приложения, не знает и знать не может) позволяют видеть эту память. Кардинально менять архитектуру аллокаторов никто не станет, и плевать на контракты - тут так принято. Исторически сложилось.
Так DF плавно превращается в UAF, что уже значительно хуже. Представили, да, извлечение приватных данных из памяти?
Так что АНБ напрасно мутит воду с безопасными языками программирования. Во-первых, никто не станет переписывать этит самые гигатонны работающего кода. Во-вторых, кто посмеет хоть пальцем тронуть системные аллокаторы?
Снова и снова - никакие костыльные защиты не спасают. Они либо чрезвычайно дороги в плане оверхеда, либо фрагментарны, либо бесполезны.
Архитектуру приложений переделывать очень дорого по времени, деньгам и когнитивной сложности. Обнаружить висящие указатели непросто даже бригаде сеньоров с микроскопами, по коду надо буквально ползать, выверяя владение, указатели, логику освобождения.
Статический анализ малоэффективен. Санитайзеры очень тяжеловесны (а чего вы ожидали?) и нацелены, в общем, на другое.
В целом, резюме очень малоутешительное. Нужно либо дьявольски тщательно и качественно код писать (что на практике является ненаучной фантастикой), либо заменять системные и иже с ними аллокаторы на архитектурно другие, с жесточайшим соблюдением контракта освобождения.
С тем, чтобы приложение, в случае DF/UAF, немедленно грохнулось в дамп, и чтобы в дампе на стеке было то самое место, где DF/UAF произошел.
Помимо того, что разработка аллокатора общего назначения сама по себе чрезвычайно нетривиальная задача, нужно еще принять волевое решение о внедрении, с тем, что отныне ошибки памяти такого класса не закапываются под ковер, а вытаскиваются на свет божий с целью незамедлительного исправления.
По очевидной причине, которую все понимают - такие ошибки это буквально приглашение к RCE. Ведь понимают? Ведь правда?
Проблема DF (double free)/UAF (use-after-free) в действительности глубже, чем может показаться.
Причем эта кроличья нора мало того, что бездонная - она тщательно замаскирована и угодить в нее можно буквально где угодно и почти на каждом шагу.
Она не очень точно называется владением памятью, более точно назвать ее проблемой висящих указателей (dangling pointers), что, в свою очередь, тоже не совсем точно.
Если объяснять совсем на пальцах, в языках с ручным управлением памятью, память - разумеется - не может знать, сколько на нее смотрит указателей из разных мест кода. Сырые указатели штука тупая и циничная. Это просто адрес ячейки или блока.
Считать указатели в обертках (
shared_ptr) накладно и в горячих путях дорого. Счетчики, блокировки. Наворачивать слои безопасности при работе с памятью - чрезвычайно дорого.Проблема усугубляется тем фактом, что в том же C++ на сырых указателях под капотом много чего строится - наследование, полиморфизм, vtable - и заменить всё это на умные указатели (которые тоже вовсе не панацея) или на ссылки не получится по определению, совместимость и гигатонны работающего кода. Что касается Си, то там указатели буквально фундамент всей и всяческой алгоритмики.
Суть проблемы, однако же, даже не в этом. А в том, что нижележащий слой - libC, системные и мажорные аллокаторы - проблему прячут и прячут глубоко в своем бэкэнде.
Теоретически аллокатор должен предоставлять один железный контракт - после free() память считается не твоей, всё, забудь о ней. Сразу же, незамедлительно, как только произошел возврат из free(). И правильно занулить указатель, потому что повторный free(NULL) - по POSIX - не бросит исключения или сегфолта и просто молча ничего не выполнит. Это не абсолютная защита, но хотя бы кое-что.
На практике освобожденный блок может достаточно долго болтаться в бэкэнде аллокатора и любые другие указатели (о которых никто, кроме приложения, не знает и знать не может) позволяют видеть эту память. Кардинально менять архитектуру аллокаторов никто не станет, и плевать на контракты - тут так принято. Исторически сложилось.
Так DF плавно превращается в UAF, что уже значительно хуже. Представили, да, извлечение приватных данных из памяти?
Так что АНБ напрасно мутит воду с безопасными языками программирования. Во-первых, никто не станет переписывать этит самые гигатонны работающего кода. Во-вторых, кто посмеет хоть пальцем тронуть системные аллокаторы?
Снова и снова - никакие костыльные защиты не спасают. Они либо чрезвычайно дороги в плане оверхеда, либо фрагментарны, либо бесполезны.
Архитектуру приложений переделывать очень дорого по времени, деньгам и когнитивной сложности. Обнаружить висящие указатели непросто даже бригаде сеньоров с микроскопами, по коду надо буквально ползать, выверяя владение, указатели, логику освобождения.
Статический анализ малоэффективен. Санитайзеры очень тяжеловесны (а чего вы ожидали?) и нацелены, в общем, на другое.
В целом, резюме очень малоутешительное. Нужно либо дьявольски тщательно и качественно код писать (что на практике является ненаучной фантастикой), либо заменять системные и иже с ними аллокаторы на архитектурно другие, с жесточайшим соблюдением контракта освобождения.
С тем, чтобы приложение, в случае DF/UAF, немедленно грохнулось в дамп, и чтобы в дампе на стеке было то самое место, где DF/UAF произошел.
Помимо того, что разработка аллокатора общего назначения сама по себе чрезвычайно нетривиальная задача, нужно еще принять волевое решение о внедрении, с тем, что отныне ошибки памяти такого класса не закапываются под ковер, а вытаскиваются на свет божий с целью незамедлительного исправления.
По очевидной причине, которую все понимают - такие ошибки это буквально приглашение к RCE. Ведь понимают? Ведь правда?
colbymchenry/codegraph: Pre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, and Hermes Agent — fewer tokens, fewer tool calls, 100% local
https://github.com/colbymchenry/codegraph
https://github.com/colbymchenry/codegraph
GitHub
GitHub - colbymchenry/codegraph: Pre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini,…
Pre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, and Hermes Agent — fewer tokens, fewer tool calls, 100% local - co...
J-jaeyoung/bad-epoll
https://github.com/J-jaeyoung/bad-epoll
Bad Epoll (CVE-2026-46242) is a race-condition use-after-free in the Linux kernel's epoll subsystem. This bug lets an unprivileged process become root, not only on Linux desktops and servers but also on Android devices.
https://github.com/J-jaeyoung/bad-epoll
Bad Epoll (CVE-2026-46242) is a race-condition use-after-free in the Linux kernel's epoll subsystem. This bug lets an unprivileged process become root, not only on Linux desktops and servers but also on Android devices.
GitHub
GitHub - J-jaeyoung/bad-epoll
Contribute to J-jaeyoung/bad-epoll development by creating an account on GitHub.
Forwarded from Hacker News