Автор библиотеки, которая используется в продуктах Anthropic, решил туда устроится работать и его не взяли, даже до собеса не дошёл 🌝

I am very proud that enigo matured enough for a company with a seemingly infinite development budget to choose it for their commercial project. Input simulation is surprisingly difficult due to little documentation and a lot of OS-specific quirks and warrants its own blog post. In my (admittedly not completely objective) opinion enigo is a great choice for the job. As far as I know, it is the only library that works on Windows, macOS, *BSD and Linux (Wayland, X11 and libei) without root. It is written in Rust and thus is mostly memory safe while being very fast. It is the most popular choice on crates.io with almost 300,000 downloads and 1,200+ stars on Github. And yet it makes me a little nervous knowing that my hobby project is used by Claude Desktop and deployed to thousands of devices.

Through a friend of a friend, I found out that Anthropic had an open position in the team implementing the secret, unreleased feature of Claude Desktop using enigo. I wrote a cover letter and sent out my application. An automatic reply informed me that they might take some time to respond and that they only notify applicants if they made it to the next round. After a few weeks without an answer, I had assumed they chose other applicants. I already forgot about the application when I received an e-mail from Anthropic. I excitedly opened it. Unfortunately they thanked me for my application but said the team doesn't have the capacity to review additional applications.

Overall I am overjoyed enigo is used in Claude Desktop and I tell everyone who listens to me about it :P. It's so cool to think that I metaphorically created the arms and legs for Claude AI, but I can't help but wonder if the rejection letter was written by a human or Claude AI. Did the very AI I helped equip with new capabilities just reject my application?

I gave the AI arms and legs — then it rejected me
https://grell.dev/blog/ai_rejection

Мне в этом контексте вспомнилась старая история Макса Хауэлла (Max Howell, создатель Homebrew), который собесился в Google и его не взяли, потому что Макс запутался в "деревьях" (тут хотя бы до этапа собесов дошёл)

Для тех кто пропустил, то почитать можно тут от самого Макса

What's the logic behind Google rejecting Max Howell, the author of Homebrew, for not being able to invert a binary tree?
https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree/answer/Max-Howell

Перевод

Логично ли, что Гугл отклонил кандидатуру Макса Хауэлла, автора Homebrew, за неумение инвертировать двоичные деревья?
https://habr.com/ru/articles/345756/

ЗЫ

> The only thing I get in return is more stars on GitHub and higher download counts on crates.io (the nerd equivalent of street creds).

Это вообще классика open source

Ясно

В докладе "О чём я говорю, когда говорю о тестировании корректности работы компиляторов" я рассказывал про один из способов верификации оптимизаций в компиляторах с помощью SMT-солвера. Такой способ используется на практике для LLVM с помощью Alive2, для GCC с помощью smtgcc, в PyPy и других компиляторах. В LuaJIT есть некоторых набор оптимизаций для IR и не всегда эти оптимизации работают корректно, мы это знаем по проблемам, которые уже были выявлены пользователями LuaJIT и исправлены. Поэтому такой способ верификации хотелось реализовать и для LuaJIT, тем более что технически это возможно - в LuaJIT можно экспортировать IR и управлять как уровнями оптимизаций так и отдельными оптимизациями.

Несколько лет назад мы в Tarantool организовали лабораторию, в рамках которой студенты в течение учебного года решают задачи, которые мы им даём, мы им в этом помогаем и платим стипендию, а по итогам такой работы можем пригласить их на стажировку. Из успешно выполненных задач: фаззеры на основе грамматики для SQL и Lua (это как раз от меня задачи были), инструментирование dlmalloc для ASAN, sysprof и memprof для LuaJIT. Более подробно про саму лабораторию можно почитать на сайте.

Одна из задач, которую мы делали со студентами, заключалась как раз в том, чтобы сделать верификатор для оптимизаций в LuaJIT. Студенты познакомились с SMT-солверами, с LuaJIT IR и сделали первую версию библиотеки, с помощью которой можно было проверифицировать код и выявить две заранее известные проблемы (они уже были исправлены в LuaJIT). В этом году я опять предлагаю эту задачу студентами. Чем конкретно прийдется заниматься: изучать LuaJIT IR, читать код на C, научиться читать и понимать SMT-LIB (популярный LISP-подобный язык для SMT-солверов), писать код на Lua и в итоге точно смоделировать семантику LuaJIT IR на SMT-LIB. В семантике IR есть много открытых вопросов, например как моделировать снапшоты и нужно или их моделировать или нет. Конечный результат, который хотелось бы получить по этой задаче это верификация оптимизаций в LuaJIT для случайно сгенерированного Lua кода, то есть чтобы верификатор работал в связке с нашими фаззинг тестами для LuaJIT.

Пример одного из тех двух багов, которые верификатор уже может выявить:

Тикет: https://github.com/LuaJIT/LuaJIT/issues/783
Патч: https://github.com/tarantool/luajit/commit/ab0c0793a43fc0fb0c7b71b6250339117d99254a

Оптимизация fold x - (-0) ==> x работает некорректно для x = -0 в арифметике с плавающей точкой. Результат выражения будет -0 вместо +0.

Пример ниже воспроизводит проблему с включенной оптимизацией fold:

local minus_zero = -0
local results = {}

for i = 1, 100 do
   local lhs = minus_zero
   local rhs = -1.0 * (2^1016) * 0.
   results[i] = lhs - rhs
end

Мои друзья делают уже второй UnderConf, пройдёт он 28 сентября в Москве (Quattro Space, ул. Мясницкая, 13, строение 20).

Ссылка на прошлогодний анонс
https://xn--r1a.website/tech_b0lt_Genona/4676
и записи докладов
https://xn--r1a.website/tech_b0lt_Genona/4843

Повторюсь, что люблю и поддерживаю такие мероприятия, потому что они делаются сообществом для сообщества.

Скоро стартует продажа билетов и ждите обновления программы, потому что пока что она слишком секретная 🌝

Канал - @und3rc0nf
Чат - @und3rc0nf_chat
Сайт - https://underconf.ru/

В Clang намерены добавить режим усиленной безопасности
https://www.opennet.ru/opennews/art.shtml?num=63675

Аарон Баллман (Aaron Ballman), главный сопровождающий компилятор Clang и участник команд разработки стандартов WG21 (C++) и WG14 (C), начал обсуждение добавления в компилятор Clang режима усиления безопасности. Новый режим позволит разом активировать набор опций для усиления защиты по аналогии с добавленным в GCC 14 флагом "-fhardened", при котором включаются опции "-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full".

Отмечается, что в настоящее время ведётся работа по добавлению возможностей для усиления безопасности в стандарты C и C++, но этот процесс не быстрый, при том, что в Сlang уже доступны отдельные опции с реализацией дополнительных механизмов защиты. Реализуемые методы защиты часто приводят к отдельным несовместимостям с существующим кодом или нарушению ABI, что не позволяет активировать их по умолчанию. Кроме того, подобные опции разрознены (флаги для управления компиляцией, флаги генерации машинных инструкций, привязанные к аппаратным архитектурам, предупреждения, режимы диагностики, макросы), плохо документированы и выпадают из поля зрения многих разработчиков.

Единая настройка унифицирует включение связанных с безопасностью опций и упростит их применение. Рассматривается несколько вариантов активации режима усиленной безопасности, например, обсуждается активация через флаг "-fhardened", набор настроек "--config=hardened", отдельный драйвер (clang --driver-mode) или раздельные опции "-fhardened, -mhardened и -Whardened", привязанные к компиляции, генерации кода и выводу предупреждений. Режим может охватывать:

* Возможности компилятора: -ftrivial-auto-var-init, -fPIE, -fcf-protection и т.п.
* Возможности, привязанные к генерации кода для целевых платформ: -mspeculative-load-hardening, -mlvi-hardening и т.п.
* Предупреждения: -Wall, -Wextra, -Werror=return-type и т.п.
* Режимы усиления безопасности в стандартной библиотеке функций.
* Макросы: _FORTIFY_SOURCE, _GLIBCXX_ASSERTIONS и т.п.
* Требование к явному выбору используемого стандарта языка.
* Отказ компилировать код с использованием устаревших стандартов C89 и C++98.
* Передача дополнительных флагов компоновщику, например, для включения рандомизации адресов.

Ссылка на обсуждение

[RFC] Hardening mode for the compiler
https://discourse.llvm.org/t/rfc-hardening-mode-for-the-compiler/87660

> Для GNU/Hurd портирован Rust

Релиз Debian GNU/Hurd 2025
https://www.opennet.ru/opennews/art.shtml?num=63706

Операторы связи предложили заблокировать звонки в зарубежных мессенджерах
https://www.forbes.ru/tekhnologii/543646-operatory-svazi-predlozili-zablokirovat-zvonki-v-zarubeznyh-messendzerah

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

Блокировка звонков в зарубежных мессенджерах, как считают компании, позволит вернуть трафик в обычные голосовые вызовы. Кроме того, по мнению операторов, она позволит решить проблему кибермошенничества, так как преступники часто звонят жертвам в WhatsApp (принадлежит компании Meta, которая признана в России экстремистской и запрещена) и Telegram.

> позволит решить проблему кибермошенничества

Наконец-то. Спасибо.

ЗЫ

«Наверное, технически это и возможно сделать [заблокировать связь], но не предполагаю, как . . . Уверен, что обойти эту блокировку тоже можно. И какого-то плюса для общества точно не принесет», — заявил Ткачев «Газете.Ru».

https://ura.news/news/1052978051

А по ссылке на Газету.Ru отдаёт 404, получается не было такого заявления 🌝

$ curl -I https://www.gazeta.ru/social/news/2025/08/10/26465036.shtml

HTTP/2 404 
server: nginx

Уязвимость в ядре Linux, позволяющая обойти sandbox-изоляцию Chrome
https://www.opennet.ru/opennews/art.shtml?num=63710

Исследователи безопасности из компании Google выявили в ядре Linux уязвимость (CVE-2025-38236), позволяющую повысить свои привилегии в системе. Среди прочего уязвимость даёт возможность обойти механизм sandbox-изоляции, применяемый в Google Chrome, и добиться выполнения кода на уровне ядра при выполнении кода в контексте изолированного процесса рендеринга Chrome (например, при эксплуатации другой уязвимости в Chrome).

Уязвимость вызвана ошибкой в реализации флага MSG_OOB, который можно выставить для сокетов AF_UNIX. Флаг MSG_OOB ("out-of-band") позволяет прикрепить дополнительный байт к отправляемым данным, который получатель может прочитать до получения остальных данных.

В реализации sandbox-окружении Chrome разрешены операции с UNIX-сокетами и системные вызовы send()/recv(), в которых флаг MSG_OOB допускался наряду c другими опциями и не был отдельно отфильтрован. Ошибка в реализации MSG_OOB позволяла добиться обращения к памяти после её освобождения (use-after-free) после выполнения определённой последовательности системных вызовов:

   char dummy;
   int socks[2];
   socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
   send(socks[1], "A", 1, MSG_OOB);
   recv(socks[0], &dummy, 1, MSG_OOB);
   send(socks[1], "A", 1, MSG_OOB);
   recv(socks[0], &dummy, 1, MSG_OOB);
   send(socks[1], "A", 1, MSG_OOB);
   recv(socks[0], &dummy, 1, 0);
   recv(socks[0], &dummy, 1, MSG_OOB);

Все подробности в оригинале

From Chrome renderer code exec to kernel with MSG_OOB
https://googleprojectzero.blogspot.com/2025/08/from-chrome-renderer-code-exec-to-kernel.html

PoC
https://project-zero.issues.chromium.org/action/issues/423023990/attachments/67577205