Hacker News Digest

Сервис pwn.watch отслеживает актуальные инциденты безопасности: сейчас в ленте 36 активных случаев, из них 15 критических, а 18 уязвимостей ещё не закрыты полностью. Самая тревожная новость — банки США (Morgan Stanley, Bank of America, JPMorgan, Wells Fargo, Citi) фиксируют сторонних ИИ-агентов внутри клиентских счетов: агенты входят под учётными данными самих клиентов, что нарушает банковские правила, а руководители признают, что не всегда отличают человека от агента и авторизованного агента от вредоносного. Потерь и захватов счетов пока не зафиксировано, но Morgan Stanley уже блокирует таких агентов, а JPMorgan, Bank of America и Citi их ограничивают.

Среди других громких случаев — критическая уязвимость GitLab CVE-2026-110264 с оценкой CVSS 10.0: переполнение целых чисел в компиляторе регулярных выражений Onigmo позволяет неаутентифицированному атакующему выполнить код на самостоятельно размещённом GitLab; уязвимы все версии CE/EE с 2014 года, и одной октябрьской заплатки недостаточно. Trend Micro случайно отправила неисправленные отчёты об уязвимостях ядра Linux в публичные списки рассылки, раскрыв детали двух RCE в ksmbd с оценкой CVSS 9.0. Также скомпрометирован релизный конвейер LiteLLM: вредоносная версия 1.107.0 провисела на PyPI около двух часов и крала учётные данные при каждом запуске Python.

Обсуждение подтверждает рост числа инцидентов: данные Identity Theft Resource Center фиксируют увеличение компрометаций в США с 1 099 в 2016 году до более 3 300 в 2025 году, с резким скачком после 2022 года. Пользователь pixl97 связывает это с «безумным» темпом обнаружения уязвимостей из-за прежнего пренебрежения безопасностью. Участники (xbar, Kevin_Flynn) предсказывают, что LLM станут драйвером крупнейшей волны инцидентов в истории. WarmWash добавляет геополитический риск: китайские модели ИИ могут быть использованы в кибератаках. Возник спор о юридической ответственности за ошибки AI-агентов в банках: mahboi и stickfigure отмечают, что клиенты сами предоставляют им доступ. В качестве альтернативы для контроля средств без посредников рекомендуют самокастоди криптовалют. По сайту и данным предложены следующие улучшения: — заменить тепловую карту линейным графиком для наглядности динамики; — уточнить классификацию инцидентов, так как статусы «Live» и «Ongoing» остаются после патчей; — исправить ошибки 404 по кнопкам RSS и JSON; — изменить темную «AI-aesthetic» тему, которая ухудшает читаемость, особенно для людей с астигматизмом.

Вышли внеплановые критические патчи GitLab для Community и Enterprise Edition: версии 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 и 18.11.13. Всем, кто разворачивает GitLab самостоятельно, настоятельно рекомендуют немедленно обновиться. Облачный GitLab.com уже работает на исправленной версии, а арендаторы GitLab Dedicated на 19.3.5-internal0 и 19.4.2-internal0 и новее защищены и могут ничего не делать.

Патч закрывает несколько уязвимостей. Самая серьёзная — критическое целочисленное переполнение в компиляторе регулярных выражений. Далее идут уязвимости высокой степени риска: некорректная аутентификация при автосвязывании учётных записей через OmniAuth и LDAP по email, а также отравление кэша в эндпоинтах обнаружения OAuth/OIDC. Средний уровень риска — неправильный контроль доступа к полю email в GraphQL для рабочих элементов, неполное применение блокировки членства SAML/LDAP на уровне инстанса, позволяющее несанкционированно добавлять участников, и раскрытие внутренних учётных данных в заголовках ответов. Детали уязвимостей раскроют через 90 дней после выпуска.

Патч содержит миграции базы данных: на одноузловых установках обновление пройдёт с простоем, а на многоузловых при соблюдении процедур обновления без простоя — без него. Обычные миграции входят в 19.4.3 и 19.3.6, пост-развёртываемые — в 19.4.3.

Обсуждение дополняет новость о критических патчах GitLab. Пользователи @molf и @zahlman пояснили, что уязвимость вызвана ошибкой в движке регулярных выражений Ruby (onigmo), а не в самом GitLab. @miduil сообщил о еще одной проблеме с regex, позволяющей неавторизованно обращаться к эндпоинту, однако @dvdkon уточнил, что для этого нужна аутентификация и загрузка вредоносного org-mode файла. @artooro, @merb и @mqus отметили, что встроенный проверщик обновлений GitLab часто ошибочно требует обновления даже после установки последней версии, а его отключение занимает много времени. Для быстрой проверки версии на узлах @beaconflint рекомендует команду `gitlab-rake gitlab:env:info`. @yoyohello13 и @131hn заметили, что из-за еженедельных патчей ручное обновление стало невозможным, поэтому советуют использовать AI-агентов или автоматические CI-процессы. @minraws в связи с рисками самохостинга рекомендует строго фильтровать исходящий трафик (например, через Tailscale). @tptacek указал, что оценка CVSS 10.0 без контекста не отражает реальный уровень риска. В то же время @hobofan и @choilive поспорили о влиянии ИИ на безопасность: первый считает текущую ситуацию худшей в истории ИТ из-за массовых уязвимостей, второй — началом «золотого века» с ростом инвестиций в автоматизированные сканеры.

Go позволяет использовать путь импорта как адрес для загрузки кода, что упрощает распространение библиотек без централизованного репозитория. Однако привязка импорта к конкретному хостингу вроде GitHub создаёт жёсткую зависимость: при миграции на GitLab или другой сервис приходится менять все импорты в коде, что становится непрактичным и дорогостоящим. Автор приводит пример компании, которая вынуждена была одновременно платить за три хостинга, потому что изменение путей импорта требовало слишком много усилий.

Решение — использовать собственный домен (например, go.iain.rocks) для пространства имён Go. На этом домене настраивается веб-сервер, который при запросе с параметром ?go-get=1 отдаёт HTML-файл с мета-тегами go-import и go-source, указывающими на реальный репозиторий. Для обычных посетителей настроен редирект на GitHub. Таким образом, импорт вида go.iain.rocks/boneclone остаётся неизменным независимо от того, где фактически расположен код. Автор предоставляет готовые конфиги Nginx и HTML-файл для быстрого старта и рекомендует этот подход всем командам, использующих Go в продакшене.

Привязка импортов к GitHub — уязвимость, но кастомные домены лишь переносят риск на управление доменами, не решая фундаментальной проблемы надёжности именования в распределённых системах. jerf: любая система именования — человеческое построение, может сломаться; замена GitHub на другой домен не решает проблему, а смещает точку отказа. thih9: коммерческим командам следует использовать кастомные домены для внутренних пакетов независимо от языка, так как даже ссылки в комментариях ломаются при миграции. p4bl0: кастомный домен может быть уничтожен регистратором (как VeriSign), поэтому стратегия не менее рискованна. SenHeng: GitHub надёжнее кастомного домена, так как у открытых разработчиков выше шанс перестать платить за домен, чем GitHub исчезнет. st3fan: при выходе компании из бизнеса её домен может быть перехвачен третьей стороной, что приведёт к захвату зависимостей — уже происходило в других экосистемах. rot256: Go смешивает 'что' и 'где' — фундаментальный недостаток, усугублённый отсутствием изначальной поддержки версионирования и блокировки зависимостей. gumby: следует использовать URN вместо URL для импортов, чтобы отделить идентификатор от места хранения и поддерживать несколько резолверов с подписями. nirui: GitHub-URL — достоверный идентификатор, кастомный домен — нет; система привыкла к GitHub как к стандарту, поэтому домен лучше использовать для брендинга, а не идентификации. deanc: если автор пакета умрёт или домен истечёт — зависимости станут недоступными без восстановления. hk1337: даже при отказе от GitHub пакеты будут ссылаться на GitLab, Codeberg или локальные серверы — проблема не исчезает, только смещается. pidgeon_lover: модель динамической загрузки зависимостей вредна, как stub-установщики; через десятилетия такие импорты могут быть скомпрометированы. okanat: единственный надёжный барьер в Go — сетевой; домен с DNS — минимально необходимый уровень абстракции для безопасного разделения. shieldagent: после переименования организации replace в go.mod покрыл прямые зависимости, но транзитивные импорты старого пути сломали сборку. lewo: следует использовать Software Heritage как резервный архив для исходного кода — Nix и Guix уже реализуют подобный механизм, хотя Go mod не поддерживает SHA-проверку. imhoguy: предлагается использовать IPNS (IPFS) или распределённый реестр вместо доменов, чтобы избежать централизованных точек отказа при идентификации пакетов.

Valve открыла исходный код экрана e‑ink для Steam Machine, назвав его «Inkterface», и разместила всё на GitLab под лицензией MIT, позволяя любому собрать собственный передний дисплей. Для сборки требуется набор компонентов: один Adafruit ESP32 Feather с 2 МБ PSRAM, один breakout‑friend для e‑ink, 5,83‑дюймовый монохромный панельный модуль, 13 болтов M2.5 × 5 мм и четыре магнитных шарика SB443‑OUT. Valve заявляет, что не будет выпускать собственный экран, а лишь открывает доступ к дизайну и коду, что делает проект полностью открытым для сообщества, а также разместила инструкцию и видео‑демонстрацию сборки, чтобы упростить процесс. Лицензия MIT гарантирует свободное использование, модификацию и распространение кода без ограничений.

Таким образом, энтузиасты могут не только собрать, но и модифицировать интерфейс под свои нужды, что расширяет возможности кастомизации, а интерес со стороны других производителей, например JSAUX, который объявил о планах выпускать готовые панели с встроенными экранами, может привести к появлению коммерческих решений в ближайшем будущем. Этот шаг открывает путь к кастомизации интерфейса Steam Machine и демонстрирует, как открытый софт стимулирует инновации в игровом оборудовании.

• Интерес к использованию открытых e‑ink панелей (например, Adafruit 5.83") в качестве статусных элементов для Steam Machine и других устройств.
• Обсуждение потенциальных выгод от открытости Valve: создание экосистемы, привлечение сообщества, возможность кастомизации без полной закрытости.
• Технические детали: необходимость Bluetooth‑модуля (ESP32), питание, refresh‑rate и совместимость с HDMI/USB‑C.
• Ограничения и опасения: надёжность e‑ink‑дисплея, необходимость дополнительного пространства для охлаждения, конкуренция с другими технологиями.

Современные CI-платформы стали мощнее, но и сложнее. GitHub Actions, GitLab и др. предлагают YAML-конфиги с шаблонами, условиями, секретами, кешем, артефактами, экосистемой actions — в итоге CI превращается в полноценную систему сборки.

Базовые примитивы (задачи, зависимости, шаги) не отличаются от Makefile-ов, а добавление распределённого запуска и кеша делает CI почти идентичным современным билд-системам вроде Bazel.

Сложность растёт:

• YAML становится языком программирования.
• Пользователи копируют чужие конфиги, не понимая, что происходит.
• Платформы закрываются на собственных экосистемах, создавая vendor lock-in.

Итог: вместо простого «удалённого запуска тестов» мы получили громоздкую систему, где границы между CI и build-системой стёрлись.

• Участники сходятся во мнении, что современные CI-системы слишком сложны и слишком «далеко» от разработчика, превращаясь в гибрид билд-системы и платформы.
• Многие предлагают упрощение: локально-переносимые скрипты (Bash, Justfile, build.bash), контейнеры или минималистичные движки вроде builds.sr.ht, Drone OSS, Buildbot, Linci.
• Критика YAML-конфигураций и SaaS-зависимости: GitHub Actions «застрял», GitLab CI мощнее, но всё равно требует «платформы».
• Идея «CI должен быть просто расширением билд-системы» (Bazel, Nix, Dagger) звучит, но требует единого «Steve Jobs билд-систем», а не новых технологий.
• Итог: пока нет серебряной пули; кто хочет простоты — пишет ./build.sh и запускает где угодно, кто хочет мощности — мирится с уровнем сложности текущих CI.

• Edka Digital — упростите Kubernetes и выкатывайте всё, что нужно, за 2 минуты.
• Сэкономьте до 70 % на облаке: кластеры k3s в вашем аккаунте Hetzner без потери контроля.
• Первый кластер бесплатно — попробовать.

---

Ваш собственный платформенный слой

• Мгновенное развёртывание — production-ready кластер за минуты.
• GitOps — CI/CD из GitHub/GitLab, превью на PR.
• Дополнения в один клик — БД, ingress, мониторинг.
• Мониторинг и аналитика в реальном времени.
• Резервные копии (скоро) — S3 одним кликом.
• Открытые стандарты CNCF — без вендор-лока.

---

Цены

• Оплата по прайсу Hetzner + фикс. подписка за кластер.
• Уходите в любой момент — ресурсы остаются вашими.

---

Кейсы

• Aicole — 64 % экономии, 20 деплойментов в день.
• TROI Ticketing — 72 % экономии, 6 k DAU.

---

Готовые приложения и адд-оны

Cert Manager, CloudNative PG, Keel и другие — смотреть все.

• Проект Edka взлетел на HN, но столкнулся с rate-limit от GitHub и частичным аутейджем Hetzner, из-за чего новые кластеры зависали в статусе «creating».
• Пользователи сравнивают Edka с kops, kube-hetzner/terraform, Syself и Linode, спрашивают про bare-metal, root-серверы, масштабирование, безопасность, обновления, сторедж, GitLab-реестр и другие провайдеры.
• Недоверие вызывает отсутствие импринта, юр. данных и реального адреса компании (упоминается «Edka Digital S.L.»).
• Некоторые просто ставят microk8s/Proxmox на bare-metal Hetzner и считают это надёжнее.
• Автор обещает улучшать платформу и благодарит за интерес к сайд-проекту.

Репозиторий FFmpeg

• 120 755 коммитов, 38 веток, 408 тегов, размер 271 МиБ
• Языки: C 90 %, Assembly 8 %, Makefile 1 %, остальное <1 %

Ветка master

• Последний коммит: a2cfaf1 — avformat/mov: передавать индекс потока в sanity_checks для HEIF
• CI: все проверки успешны (linux-amd64, linux-aarch64, Windows, lint)

Ссылки

• ZIP | TAR.GZ | BUNDLE

Последние изменения

• libavformat: передача индекса потока в sanity_checks для HEIF (James Almer)
• libavcodec: очистка pu_info в rv60dec
• fftools/ffmpeg_mux_init: 64-битные вычисления score
• libswscale: выравнивание на 8 строк для planarCopyWrapper
• doc/examples: замена sleep на av_usleep
• presets: удалены устаревшие пресеты iPod

• FFmpeg ушёл с GitHub на самостоятельный Forgejo, отказавшись от рассылок и ускорив навигацию по файлам.
• Пользователи жалуются на защиту Anubis с «аниме-девочкой»: ошибки «Invalid Response», пропадающий CSS, проблемы на Android.
• Критика мотива «не Microsoft» и вопросы: почему именно Forgejo, а не GitLab/Gitea.
• Сторонники отмечают суверенитет и удобство, противники — нестабильность и «нелепый» брендинг.

Modos Paper Monitor — открытый e-paper монитор 75 Гц и dev-kit.
Собрано $61 611 из $110 000, 37 дней до конца кампании.

В комплекте

• Плата на FPGA (Caster, 60 Гц, открытая прошивка).
• 6" и 13" монохромные панели; контроллер подходит и к другим экранам 6–13,3".
• HDMI/USB, Linux/macOS/Windows.
• Корпус-чертежи и ПО на GitHub.

Почему это важно

• Закрытые драйверы и высокие цены тормозят e-paper.
• Мы даём инженерам и энтузиастам свободу экспериментировать и формировать стандарты (Discord, Mastodon, Matrix, Bluesky).

Возможности

• Низкая задержка: независимые области обновления, отмена прежних пикселей.
• Гибкие режимы: бинарный для скорости + гибридный серый для деталей.
• C API: полный контроль режимов и обновлений.

Цены

$199–$599, 6 вариантов комплектации.

GitHub-список совместимых экранов

• Проект Glider — полностью открытый: исходники, Verilog, документация и файлы платы на GitHub/GitLab.
• NLnet и ЕС профинансировали разработку; обсуждаются условия грантов и гражданство авторов.
• Контроллер на низкобюджетном FPGA выдаёт HDMI/USB-C, но пока не предлагает LVDS/eDP для моддинга ноутбуков.
• Демо показывает высокую скорость обновления при заметном «ghosting»; блики — особенность дешёвой панели, не самой платы.
• Участники хотят 21–24″ монохромный 30 Гц дисплей дешевле $500, сенсорный слой и драйверы X11/Wayland.
• Упомянуты альтернативы: Inkplate, TRMNL, Boox, а также DIY-кибердеки и ноутбуки ThinkPad T480 с e-ink.