Hacker News Digest

Вышли PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 с исправлениями двух критических уязвимостей, позволяющих неаутентифицированному атакующему выполнять код на сервере. Первая (CVE-2026-109618) — повреждение памяти при достижении memory_limit в неудачный момент: на Apache с mod_php запрос срабатывает ещё до кода приложения, и полный удалённый запуск кода подтверждён на настройках по умолчанию; на PHP-FPM — через код приложения. Вторая (CVE-2026-109619) — устаревшее состояние: фатальная ошибка оставляла внутренние указатели на память прошлого запроса, что давало use-after-free и запуск кода в реальном приложении на Apache с mod_php. Обе уязвимости лежат в управлении памятью и обработке ошибок — в частях, которые затрагивает почти каждый запрос, поэтому исправление грозило потерей совместимости, падением производительности или поломкой сторонних расширений.

Первый за годы внешний аудит 2024 года профинансировало Sovereign Tech Agency, организовал OSTIF, провёл Quarkslab. При исправлении его находок разработчик и заметил первые признаки проблемы с нехваткой памяти; в 2024-м эксплойт лишь теоретизировали. Команда безопасности перебирала конкурирующие подходы, решения принимались консенсусом, и работа месяцами то замирала, то возобновлялась — авторы прямо называют задержку структурным провалом из-за процесса принятия решений и нехватки ресурсов. Теперь решения принимаются большинством голосов, а компромиссы поощряются.

Главный дефицит — опытные инженеры, знающие всю кодовую базу PHP. Фонд PHP просит финансирования у компаний на PHP, хостингов, облаков и дистрибутивов, а также государств: пример — поддержка немецкого агентства, оплатившего аудит.

Обсуждение дополняет статью сведениями о роли AI (Anthropic, OpenAI, Qwen и др.) в автоматизации атак на основе новых CVE. Пользователи критикуют управление безопасностью в PHP: модель принятия решений на основе консенсуса привела к задержкам в исправлении проблем после аудита 2024 года. В ходе спора @jooops1 и @redox99 назвали PHP фундаментально небезопасным из-за использования C и призвали перейти на memory-safe языки (например, Rust), тогда как другие обсуждали лишь конкретные ошибки. @jongjong отметил, что малый объем кода (LOC) и минимум зависимостей ускоряют анализ и закрытие брешей. Также осуждена компания Chainguard за одностороннее нарушение эмбарго и публикацию исправленных образов до официального релиза. Из практических советов: @dofm рекомендует блокировать multipart-загрузки в Nginx как временную меру защиты от данной RCE. Отдельно отмечены задержки в обновлении зеркал Ubuntu у провайдера Hetzner, из-за чего пользователям пришлось применять патчи вручную.

В статье рассматриваются альтернативы MinIO для локального S3-хранилища в однозузовом режиме, с акцентом на простоту замены в Docker Compose и минимальные изменения кода. Автор тестирует несколько решений, сохраняя клиент mc для совместимости.

S3Proxy — лёгкий вариант на Java с Apache 2.0 лицензией, Docker-образом (5M+ загрузок) и хорошей S3-совместимостью. Конфигурация простая, но зависит от jclouds, который был перемещён в Apache Attic в mid-2025 — хотя для локального использования это, вероятно, не критично.

RustFS — проект на Rust с GUI, Docker-образом (100k+ загрузок) и Apache 2.0 лицензией. Однако недавно обнаружен серьёзный уязвимость (GHSA-h956-rh7x-ppgj), что вызывает осторожность. Проект находится в альфа-стадии, интерфейс выглядит полированным, но некоторые ссылки ведут на одну страницу — «свежая покраска». Подходит для демо, если легко заменить.

SeaweedFS — зрелый OSS-проект с S3-поддержкой с 2018 года (release 0.91), Docker-образом (5M+ загрузок) и Apache 2.0 лицензией. Требует отдельного конфига для аутентификации, но проект обещает упростить это. Имеет базовый UI, хотя сайт выглядит как enterprise-продукт без явной ссылки на GitHub — что может ввести в заблуждение. Простой переход, минимальные правки.

Garage — упоминается как сложный в настройке из-за строгой валидации ключей (например, ключ должен начинаться с GK и содержать 12 hex-байт), что избыточно для локальных демо и создаёт барьер входа. Не подходит как «drop-in» замена.

Apache Ozone и Ceph Object Gateway — отвергнуты как слишком тяжёлые: Ozone требует минимум четырех узлов для работы, Ceph — избыточен для локального стека. Оба имеют Hadoop-наследие и не подходят для лёгкой интеграции в Docker Compose для демонстраций.

Итого: для простой замены MinIO в локальном режиме лучшие варианты — S3Proxy и SeaweedFS; RustFS — рискован из-за уязвимости и альфа-статуса; остальные — избыточны.

Обсуждение подтверждает потерю доверия к MinIO из-за смены лицензии и выделяет альтернативы с опытом эксплуатации в продакшене: * **Garage**: стабилен в одноузловом режиме (до 10 ТБ), но требует NVMe для метаданных. Не поддерживает перебуферизацию, политики хранения на уровне бакета и строгую согласованность, что делает его непригодным для Iceberg. * **SeaweedFS**: надежная замена с поддержкой IAM, OIDC и Iceberg, но требует больше настроек; ранее были проблемы с API удаления пользователей и отсутствием S3 expiry rules. * **RustFS**: подходит для архивирования, но CVE в прошлом подорвали доверие к надежности. * **S3Proxy**: легкий, популярен (5M+ загрузок), рекомендуется для локальной разработки и тестирования. * **pgsty/minio**: форк MinIO, используется в end-to-end тестах как быстрый локальный симулятор. * **VersityGW**: поддерживает POSIX-бэкенд, сохраняя multipart-загрузки как реальные файлы, что упрощает отладку. * **LocalStack**: простое решение для разработки, особенно при необходимости других AWS-сервисов. * **JuiceFS** (китайский проект) и **Scality S3 (Zenko)** (требует актуальный Docker-репозиторий) — рабочие решения. * **Incus**: имеет встроенный S3-сервер для пользователей LXD-экосистемы (совместимость с S3 API не детализирована). * **S2** и **Filestash** с S3-шлюзом упомянуты без деталей опыта использования. Для Iceberg критична поддержка conditional GET/PUT/DELETE и ETag (строгая согласованность), поэтому SeaweedFS предпочтительнее Garage. В дискуссиях отметили, что альтернативы часто являются компромиссом по функционалу. Для простых локальных задач предлагают s3fs или прямой файловый доступ вместо перегруженного MinIO, хотя другие настаивают на необходимости S3-совместимости для интеграции. Также упомянуто, что для сценариев «good enough» AI-инструменты (например, Claude) позволяют быстро создать простой S3-прокси.

Команда Rebble обвиняет Core Devices в нарушении соглашения и попытке присвоить их работу. После банкротства Pebble Technology Corporation девять лет назад Rebble и сообщество приложили огромные усилия, чтобы сохранить экосистему часов, потратив сотни тысяч долларов на хостинг и поддержку. Интересно, что текущий магазин приложений Pebble от Core на самом деле работает на инфраструктуре Rebble, а данные в нём на 100% принадлежат Rebble. Как отмечает команда: "Данные за магазином приложений Pebble на 100% от Rebble".

Core требует неограниченного доступа к архивам данных, чтобы делать с ними что угодно, включая создание закрытого магазина приложений. Несмотря на устные обещания, Эрик отказывается закреплять это в письменном соглашении и даже нарушил предыдущее договорённость, скопировав магазин приложений Rebble. Команда подчёркивает: "Мы бы предпочли сотрудничать с ними для создания чего-то великого вместе, но мы достигли тупика".

• Rebble обвиняет Core Devices в попытке получить полный доступ к их базе данных без компенсации, угрожая существованию сообщества.
• Многие пользователи угрожают отменить предзаказы часов Core из-за недоверия и поддержки Rebble.
• Обсуждаются лицензионные вопросы (Apache/AGPL) и этика использования открытого кода и данных.
• Предлагаются альтернативы: партнерство с другими производителями или создание собственных часов сообществом.
• Подчеркивается историческое недоверие к Pebble после продажи компании Fitbit.

Debian 13 «trixie» вышел 9 августа 2025 года после 2 лет разработки.
Поддержка — 5 лет (Security + LTS).

Десктопы: GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1, Xfce 4.20.
Пакетов: 69 830 (+14 100 новых, –8 840 устаревших, 44 326 обновлённых).
Размер: 403 ГБ, 1,46 млрд строк кода.
Ядро: 6.12 LTS; первый релиз с официальной поддержкой riscv64.
Архитектуры: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x.
i386 больше не поддерживается; armel последний релиз.

Ключевые обновления: Apache 2.4.64, Bash 5.2.37, BIND 9.20, GCC 14.2, LibreOffice 25.2, MariaDB 11.8, Nginx 1.26, OpenJDK 21, PHP 8.4, PostgreSQL 17, Python 3.13, Rust 1.85, systemd 257 и др.

Облако: образы для EC2, Azure, OpenStack, PlainVM, NoCloud с cloud-init и оптимизированным загрузчиком.
Live-образы: amd64/arm64, GNOME/KDE и др.; установка через Calamares или стандартный установщик.

• Debian 13 «Trixie» вышла: 63 % пакетов обновлены, поддержка 7 архитектур, включая RISC-V.
• i386 теперь только как «amd32»-совместимый, официального ядра/инсталлятора нет.
• Появился новый формат APT-репозиториев debian.sources, старый sources.list пока работает.
• 95 % пакетов достигают bit-for-bit воспроизводимости на amd64/arm64/riscv64.
• /tmp теперь tmpfs по умолчанию (до 50 % ОЗУ), но можно вернуть старое поведение.
• Пользователи хвалят стабильность, скорость обновления «stable→stable» и отсутствие snap.