Denis Evsyukov

Ссылки #393

denis@evsyukov.org (Denis Evsyukov) — Sat, 06 Jun 2026 08:54:16 +0300

За прошедшую неделю собрал 23 ссылки.

🤖 AI

mims-harvard/AutoScientists Система AI-агентов для долгих вычислительных научных экспериментов: агенты сами собираются в команды вокруг перспективных гипотез, критикуют предложения друг друга до траты вычислений на эксперимент и обмениваются удачами и провалами. Координация децентрализована, через локальный сервер, а не из единого центра.

LearningCircuit/local-deep-research Open-source research-ассистент для автономных глубоких исследований: поиск по 10+ источникам (arXiv, PubMed, Wikipedia, GitHub), 100+ моделей через Ollama и облако, шифрование баз и нулевая телеметрия. Всё может работать локально — приватность по умолчанию.

💻 Инструменты

harehare/mq jq для Markdown: командная утилита на Rust, которая фильтрует и трансформирует документ по структуре, а не по тексту. Полезна для LLM-пайплайнов, аудита документации и пакетной обработки .md-файлов. Есть REPL, VSCode-расширение и несколько форматов вывода.

🔒 Приватность

Filtr is a new privacy tool that blocks ads in almost every iPhone and Mac app Блокировщик рекламы уровня системы от автора Safari-блокировщика Wipr. Использует новый URL-фильтр из iOS 26 и macOS 26 и режет рекламные сети не только в браузере, но почти во всех приложениях. Блок-лист хранится на устройстве и обновляется сам.

На этой неделе — от AI-агентов, ведущих научные эксперименты, и локального research-ассистента до jq для Markdown и системного блокировщика рекламы на iOS и macOS.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #393 (Denis Evsyukov)

Ссылки #392

denis@evsyukov.org (Denis Evsyukov) — Sat, 30 May 2026 15:03:23 +0300

За прошедшую неделю собрал 27 ссылок.

🤖 AI

Using Claude Code: The unreasonable effectiveness of HTML Команда Claude Code объясняет, почему HTML выигрывает у Markdown для результатов работы агентов: плотность информации, визуальная наглядность, лёгкий шеринг и интерактивность.

rasbt/LLMs-from-scratch Реализация GPT-подобного LLM на PyTorch с нуля, шаг за шагом — официальный репозиторий книги Себастьяна Рашки, 96K звёзд.

💻 Программирование

Looking closer at Claude Generated Lisp Code | skybert.net Разбор AI-сгенерированного Emacs Lisp кода: автор обнаружил, что Claude написал десятки строк там, где хватило бы трёх вызовов стандартного API. Хорошее напоминание, почему AI-код нужно ревьюить.

Production начинается там, где заканчивается вайбкодинг История pet-проекта, собранного с помощью LLM: демка собирается быстро, а sync, rollback, техдолг, безопасность и эксплуатация требуют ещё месяцев инженерной работы. О разрыве между вайбкодингом и production.

На этой неделе — от HTML как формата для AI-агентов и книги по LLM с нуля до ревью AI-сгенерированного кода и опыта превращения вайбкодинг-демки в production.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #392 (Denis Evsyukov)

Пароль по словам: разбор идеи о многошаговой авторизации

denis@evsyukov.org (Denis Evsyukov) — Mon, 25 May 2026 15:25:00 +0300

Обычный вход устроен просто до примитивности. Есть поле для имени и поле для пароля, вы заполняете оба, нажимаете кнопку — и за один запрос отправляете на сервер всё сразу. Сервер сверяет и тут же отвечает: пустили или нет. Одна попытка — один ответ, мгновенно.

Именно эта мгновенность и не даёт покоя. Раз каждая попытка возвращает сразу понятный результат, её можно повторять машинально, тысячами в секунду. Так и работает перебор: берём словарь, скармливаем его форме входа, ждём, когда сервер скажет «да». Чем быстрее цикл «отправил — получил ответ», тем дешевле атака.

Отсюда напрашивается идея, которую я и хочу разобрать. А что если не отправлять пароль одним куском?

Суть предложения

Пусть пароль — это не строка, а несколько отдельных «слов». Каждое слово вводится и уходит на сервер само по себе, отдельным шагом. Вход превращается в цепочку: слово, потом ещё слово, потом ещё. А ответ — пустили или нет — приходит только в самом конце, на заранее условленном шаге. Скажем, после третьего слова. Или после восьмого.

От имени пользователя при этом, возможно, можно вообще отказаться и опознавать человека только по самой цепочке.

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

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

Что в этой идее угадано верно

Не говорить, где именно ошибся. Это не выдумка, а давний принцип. Хорошо сделанный вход уже сейчас не сообщает, что неверно — имя или пароль. Он отвечает одинаково расплывчато в обоих случаях, потому что любая подсказка сужает переборщику пространство поиска. Больше того: грамотная проверка пароля сравнивает строки за постоянное время, не прерываясь на первом несовпавшем символе. Иначе появляется тонкая лазейка — атака по времени ответа: по тому, насколько быстро сервер сказал «нет», можно угадывать пароль по одному символу¹. Так что «не выдавать, где ошибка» — это правильный инстинкт. Запомним его, он ещё пригодится.

Секретная последовательность как условие доступа. Это тоже не новость — это буквально существует и называется port knocking, «стук в порты». Сервис прячется за наглухо закрытым межсетевым экраном и открывает порт только тому, кто постучал в заранее условленную последовательность портов. Пока вся последовательность не пройдена правильно, снаружи всё выглядит закрытым, и — ключевой момент — сервер ничего не подтверждает на промежуточных шагах, он вообще не отвечает². Есть и более зрелый вариант, single packet authorization, где весь «стук» упакован в один зашифрованный пакет с подписью и меткой времени³. То есть идея «пройди скрытую цепочку, и только тогда получишь доступ» в мире существует и работает.

Пароль из нескольких слов. И это давно живёт под именем «парольная фраза». Современные рекомендации, в том числе NIST, прямо советуют делать ставку на длину, а не на вычурный набор символов, и не навязывать пользователю обязательные спецсимволы — длинная фраза из обычных слов стойче к перебору и при этом легче запоминается⁴.

Так что на прямой вопрос «делает ли кто-то подобное» честный ответ: по духу — да, по частям. Скрытая последовательность без обратной связи — это port knocking. Пароль из слов — это парольная фраза. Есть и более экзотика: в патентах попадаются «многоуровневые матричные пароли» и схемы последовательной аутентификации, где итоговый вердикт выносится только после всех шагов⁵. Идея витает в воздухе.

Вопрос в другом: складывается ли из этих верных кусочков работающая защита от перебора. И вот тут начинаются проблемы.

Где идея ломается

Несколько шагов не добавляют ни бита стойкости. Это главное. Пароль «ёлка кофе мост», проверенный только в самом конце, ничем не отличается от одной строки «ёлкакофемост», по которой выносят единственный вердикт «да/нет». Стойкость к перебору определяется размером пространства, которое нужно прочесать, — а оно зависит от того, сколько и каких слов вы выбрали, а не от того, в скольких запросах их отправили. Разбили вы фразу на три пакета или послали одним — пространство поиска то же самое. Если слова слабые, слабой будет и вся комбинация, в один запрос её отправили или в восемь.

«Не понять, где ошибся» — это и так поведение нормальной системы. Мы только что про это говорили: правильный вход и без всякой многошаговости отвечает одним битом на весь пароль и не показывает, какой символ не сошёлся. Получается, многошаговая схема не добавляет это свойство — она лишь заново, дороже и сложнее, воспроизводит то, что и так есть по умолчанию.

Перебор тормозит совсем другое. Не число запросов. Атакующий не сидит за формой входа руками — он гоняет запросы скриптом, может слать их пачками, не дожидаясь ответа. Лишние шаги для скрипта почти ничего не стоят. По-настоящему перебор душат три вещи: ограничение числа попыток с растущей задержкой, блокировка после серии неудач и намеренно медленный хеш пароля — bcrypt, Argon2, — когда каждая проверка стоит атакующему ощутимых вычислений. NIST, к слову, рекомендует именно ограничение попыток как основную меру против перебора⁴. Многошаговый вход ни одну из этих трёх вещей не усиливает.

Серверу теперь надо помнить незаконченные попытки. Чтобы проверять слова по одному и молчать до конца, сервер обязан хранить состояние каждой начатой цепочки — в том числе брошенной на полпути или заведомо неверной. Это новая поверхность для атаки. Достаточно начинать миллионы цепочек и не доводить их до конца, чтобы засыпать сервер мусорным состоянием, — отказ в обслуживании получается почти бесплатно. У обычного пароля, который проверяется одним запросом без всякой памяти о попытке, этой проблемы просто нет.

Отказ от имени делает хуже, а не лучше. Имя пользователя — это не секрет, это указатель, по которому система находит нужную учётную запись. Уберите его — и пропадёт сама возможность считать попытки на конкретный аккаунт, заблокировать его, предупредить владельца о подозрительной активности. А ведь ограничение попыток на учётную запись — это и есть главная защита от перебора. Вдобавок появляется риск столкновений: если две цепочки слов совпали, второй человек войдёт в чужой аккаунт. Так что опознавание «только по паролю» не усиливает защиту, а выбивает из-под неё опору.

«Слова можно попроще» — самая опасная мысль во всей идее. Стойкость по-прежнему равна суммарной энтропии вашего секрета. Разбиение на шаги не выдаёт скидку на сложность — её просто неоткуда взять. Хуже того: вводить восемь слов подряд муторно, и пользователь под этим давлением выберет слова покороче и попроще, то есть собственными руками уменьшит ту самую энтропию, на которой всё держится.

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

Что решает ту же задачу

Если отбросить механику и оставить намерение — «сделать каждую догадку дороже и не дать атакующему обратной связи», — то у отрасли давно есть инструменты, которые бьют точно в цель:

Медленный хеш — bcrypt, Argon2. Делает каждую проверку пароля вычислительно дорогой. Для одного честного входа это незаметно, для перебора миллионов вариантов — стена.
Ограничение попыток и растущая задержка. После нескольких неудач аккаунт начинает отвечать всё медленнее или временно закрывается. Бьёт ровно по скорости цикла перебора.
Второй фактор — одноразовые коды (TOTP). Добавляет к секрету ещё и привязку ко времени, которую не подберёшь словарём.
Passkeys и WebAuthn. Самое радикальное: вместо общего секрета — пара ключей, и перебирать становится просто нечего.

Все они дают то, чего хотела многошаговая идея, — и без хранимого состояния, без отказа в обслуживании и без мучений на входе.

Вывод

Идея «пароль по словам» ценна не как готовая схема, а как способ самому, с нуля, вывести принципы, на которых стоит современная аутентификация: не выдавать, где ошибка; прятать сервис за секретной последовательностью; делать секрет длинным, а не вычурным. Всё это — настоящие, рабочие вещи, и приятно, что интуиция к ним выводит.

Но как замена паролю она не складывается. Число шагов не двигает ту единственную величину, которая определяет стойкость к перебору, — энтропию. А то, что она двигает — количество запросов, — перебор всё равно не останавливает: его останавливают медленный хеш и ограничение попыток. Там же, где скрытая последовательность действительно живёт в дикой природе, в port knocking, её используют не как пароль, а как дополнительный слой маскировки сервиса, да ещё и в связке с криптографией, а не вместо неё.

Timing attack — Wikipedia. https://en.wikipedia.org/wiki/Timing_attack ; разбор на примере имени пользователя: Brendan Long, «Timing attacks and usernames». https://www.brendanlong.com/timing-attacks-and-usernames.html ↩︎
Port knocking — Wikipedia. https://en.wikipedia.org/wiki/Port_knocking ↩︎
Single Packet Authorization. https://portguard.net/ ; Michael Rash, «Port Knocking and Single Packet Authorization». https://www.cipherdyne.org/ ↩︎
NIST Special Publication 800-63B, Digital Identity Guidelines. https://pages.nist.gov/800-63-4/sp800-63b.html ↩︎ ↩︎
Примеры из патентных заявок: «Multi-level matrix passwords» и «Sequential authentication using error rates». https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/10395015 ↩︎
Keith et al., «The usability of passphrases for authentication: An empirical field study». https://www.sciencedirect.com/science/article/abs/pii/S1071581906001236 ↩︎

Читайте оригинал на странице: Пароль по словам: разбор идеи о многошаговой авторизации (Denis Evsyukov)

nebula-mesh: панель управления для Nebula, которую я собрал сам

denis@evsyukov.org (Denis Evsyukov) — Mon, 25 May 2026 13:30:00 +0300

Пару месяцев назад я перевёл инфраструктуру с Tailscale на Nebula¹. Открытая лицензия, своя PKI, никакой зависимости от чужих координационных серверов — всё то, чего мне не хватало раньше. Сеть заработала и работает до сих пор.

А потом начались будни. Добавить сервер — выпусти сертификат руками, скопируй конфиг, перезапусти. Сертификат скоро протухнет — вспомни про это до того, как узел отвалится. Поменялось правило firewall — пройдись по всем хостам. Через месяц такой ручной возни я понял, что мне нужна панель управления. А готовой, которая бы меня устроила, не нашлось. Так появился nebula-mesh².

Что такое Nebula, если коротко

Nebula — overlay-сеть, которую сделали инженеры Slack и открыли под MIT-лицензией в 2019 году. Подробно я разбирал её в прошлой статье¹, тут повторю только суть.

Это виртуальная сеть поверх обычного интернета. Узлы соединяются между собой напрямую (P2P), а не гоняют трафик через один центральный VPN-сервер. Несколько узлов работают как lighthouse — «маяки», к которым обращаются остальные, чтобы найти друг друга и пробить путь сквозь NAT. Шифрование — на основе Noise, того же, что в WireGuard и Signal.

Главное для нашего разговора: у Nebula нет облака. Доверие в сети держится на сертификатах. Вы заводите собственный центр сертификации (CA), храните его у себя, и каждый узел получает сертификат, подписанный этим CA. В сертификате записаны имя хоста, его адрес в виртуальной сети, группы и срок действия. Никаких сторонних серверов в этой схеме нет — и это же её слабое место, когда узлов становится много.

Как это настраивается руками

Базовая настройка выглядит так. Сначала создаёте центр сертификации:

nebula-cert ca -name "Моя сеть"

Получаете два файла: ca.key — закрытый ключ, который нельзя терять и нельзя показывать никому, и ca.crt — публичный сертификат, который поедет на все узлы.

Дальше на каждый хост выпускаете свой сертификат с уникальным адресом:

nebula-cert sign -name "server-1" -ip "192.168.100.1/24" -groups "servers"

Потом пишете для каждого узла YAML-конфиг: где лежат ключи, по какому адресу искать lighthouse, какие правила firewall. Копируете конфиг и сертификаты на сервер. Запускаете. И так для каждого узла.

Для трёх машин это десять минут. Проблема в том, что машин обычно не три.

Где это начинает болеть

Чем больше сеть, тем заметнее, что Nebula не даёт инструментов управления — только утилиту для выпуска сертификатов и сам бинарник узла. Всё остальное на вас.

Сертификаты живут год. По умолчанию CA выпускается на год, хостовые сертификаты — тоже. Срок подходит — нужно выпустить новые на всех узлах и перезапустить Nebula везде. Забыли про один сервер — он молча выпадает из сети.
Конфиги разъезжаются. Поменяли правило — обходите хосты руками или поднимаете Ansible. Для десятка узлов Ansible — уже почти обязателен, и это отдельная история со своей сложностью.
Нет ни кнопки, ни картинки. Какие узлы сейчас в сети, у кого скоро истекает сертификат, кто не выходил на связь — всё это надо собирать по логам. Веб-интерфейса нет.
Масштаб умножает рутину. Сто новых серверов — это сто запусков nebula-cert sign и сто копирований файлов.

Создатели Nebula это прекрасно понимают. Поэтому у них есть платный продукт, который всю эту рутину закрывает.

Готовое решение: Defined Networking

Те же люди, что написали Nebula, основали компанию Defined Networking и сделали Managed Nebula³ — облачную панель управления. Регистрируете узел через веб-интерфейс или их агент, сертификат и конфиг прилетают сами, есть единый вход, мобильные приложения, автоматическая ротация. До 100 хостов бесплатно, дальше доллар за хост в месяц.

Решение хорошее. Я честно его рассматривал. Не подошло по одной причине: это чужое облако.

Панель управления живёт на серверах в США. А значит, между мной и моей сетью встаёт всё то, что сейчас встаёт между Россией и зарубежными сервисами: блокировки Роскомнадзора, санкции, ограничения на облачные услуги. Доступ к defined.net может пропасть не из-за их сбоя, а из-за того, что где-то по дороге закрыли очередной диапазон адресов. Строить на этом инфраструктуру, ради которой я и уходил от Tailscale за независимостью, смысла нет. Если уж self-host — то self-host до конца.

А что с готовым self-host

Я искал. Зрелых открытых панелей для Nebula почти нет — экосистема намного беднее, чем у того же Tailscale, где есть Headscale⁴.

Самое заметное, что нашлось, — Supernova⁵. Это control plane для Nebula: веб-панель, регистрация по токенам, выдача сертификатов. Но проект завязан на инфраструктуру AWS (DynamoDB, Lambda), давно не обновлялся и выглядит скорее как доказательство концепции, чем как то, на что можно положиться. Остальное, что попадалось, — демки и заброшенные репозитории.

Ничего, что я мог бы поставить на свой сервер и спокойно эксплуатировать, не нашлось. Поэтому решил написать сам.

Что получилось

nebula-mesh — это панель управления для Nebula, которая целиком живёт на вашем сервере. Никакого облака. Ставится на самую дешёвую виртуалку, хранит данные в SQLite, не тянет за собой внешних зависимостей.

Состоит из двух частей:

nebula-mgmt — сервер управления. Веб-интерфейс, API, центр сертификации, журнал действий. Запускается в одном экземпляре.
nebula-agent — лёгкий агент, который ставится на каждый узел сети. Сам регистрируется, сам забирает обновления конфига и сертификата, сам перезапускает Nebula, когда нужно.

Написано на Go. Веб-интерфейс — на htmx, без тяжёлого фронтенда.

Что умеет

Управление сертификатами от начала до конца. Выпуск, ротация, отзыв. Закрытый ключ CA лежит в базе зашифрованным (AES-256-GCM); мастер-ключ для расшифровки передаётся при старте и на диск не пишется. Сертификаты обновляются автоматически в фоне, до того как протухнут.
Регистрация узлов по одноразовым токенам. Создаёте токен в панели, агент на новом сервере его предъявляет и получает всё необходимое. Закрытый ключ узла при этом никогда не покидает сам узел.
Телефоны через QR-код. Для iOS и Android конфиг отдаётся QR-кодом — отсканировал в приложении Nebula и готово.
Несколько администраторов. У каждого свой изолированный CA. Можно заходить локальной учёткой или через OIDC (Keycloak, Authentik и подобные), есть двухфакторная аутентификация по TOTP с резервными кодами.
Правила firewall на уровне сети — задаются в панели, разъезжаются по узлам сами.
Журнал всех действий — кто, что и когда поменял. Плюс метрики для Prometheus и health-эндпоинты для мониторинга.

Как пользоваться

На управляющем сервере ставите nebula-mgmt (есть пакеты .deb и .rpm, бинарники под Linux, macOS, FreeBSD, Windows и Docker-образы), задаёте мастер-ключ и инициализируете:

export NEBULA_MGMT_MASTER_KEY=$(openssl rand -base64 32)
sudo -E nebula-mgmt init --config /etc/nebula-mgmt/server.yml
sudo systemctl enable --now nebula-mgmt

Дальше открываете панель на http://<сервер>:8080/ui/, заводите оператора и сеть. Чтобы подключить узел, создаёте для него токен, ставите на него nebula-agent и скармливаете токен. Агент сам зарегистрируется, заберёт сертификат с конфигом и поднимет Nebula. После этого он будет тихо опрашивать сервер на предмет обновлений и применять их без вашего участия. Точные команды и актуальную версию смотрите в README² — проект ещё активно развивается, и я не хочу, чтобы статья устарела вместе с номером релиза.

Текущее состояние, честно

Проект совсем молодой — я запустил его в этом месяце. Звёзд на GitHub пока немного, и это нормально для репозитория, которому несколько недель. Статус — beta: основные сценарии (инициализация, регистрация, опрос, ротация, отзыв, журнал, несколько CA) покрыты тестами с детектором гонок, но API ещё может меняться до версии 1.0.

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

Лицензия — MIT. Если вам тоже нужна mesh-сеть на Nebula, которую можно держать целиком у себя, без оглядки на чужое облако и чужие блокировки, — посмотрите nebula-mesh . Баг-репорты, идеи и pull request’ы приветствуются.

Nebula: mesh-сеть поверх интернета и мост в Tailscale — предыдущая статья, где Nebula разобрана подробно. ↩︎ ↩︎
github.com/juev/nebula-mesh — репозиторий проекта, там же README с командами установки. ↩︎ ↩︎
Defined Networking и их тарифы . ↩︎
Headscale — открытый координационный сервер для Tailscale. ↩︎
losfair/supernova — control plane для Nebula на инфраструктуре AWS. ↩︎

Читайте оригинал на странице: nebula-mesh: панель управления для Nebula, которую я собрал сам (Denis Evsyukov)

Ссылки #391

denis@evsyukov.org (Denis Evsyukov) — Sat, 23 May 2026 10:18:31 +0300

За прошедшую неделю собрал 22 ссылки.

🤖 AI

Kappaemme-git/codex-complexity-optimizer Codex skill для безопасного анализа сложности кодовой базы и отчётов по оптимизации производительности.

Ambient Associative Memory Тим Келлог размышляет об ambient associative memory — модели памяти, где ассоциации возникают из окружающего контекста, а не из явного извлечения.

Imbad0202/academic-research-skills Набор skills для Claude Code, выстраивающий академический цикл: research → write → review → revise → finalize.

📝 Продуктивность

Handwriting, journaling, and LLMs Чад Кохалик о том, как рукописный journaling уживается с LLM — где они помогают мышлению, а где мешают рукописной рефлексии.

На этой неделе — от Codex-скилла для анализа сложности и идеи ambient-памяти до академического пайплайна на Claude Code и размышлений о рукописном journaling в эпоху LLM.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #391 (Denis Evsyukov)