Hacker News Digest

VSCode при подключении по SSH не просто использует удалённый доступ — он разворачивает полноценный агент на целевом сервере: скачивает бинарник Node.js, запускает веб-сокет-соединение обратно к локальному интерфейсу и получает полный контроль над файловой системой, процессами и настройками удалённой машины. Это не просто редактирование файлов — это полноценное проникновение с возможностью постоянной установки, что в корне отличается от элегантного и пассивного подхода Emacs Tramp, который работает исключительно через команды shell. Такой механизм выглядит как угроза безопасности: агент может случайно или намеренно изменить конфигурацию сервера, особенно опасно это в продакшене или при работе с чувствительными системами.

Хотя автор не предлагает отказаться от VSCode, он подчёркивает, что подобное поведение неприемлемо для сред, где важна изоляция — например, при использовании LLM-агентов, которые итеративно тестируют код и могут «запутать» систему. Вместо этого он предлагает использовать чистые, временные Linux-инстансы (например, Fly Machines), где даже такой агент не навредит. Суть в том, что удобство VSCode не должно оправдывать риски: инструмент, который сам устанавливает себе бэкдор на удалённой машине, не должен быть доверенным в инфраструктуре, где безопасность важнее скорости разработки.

VSCode SSH работает без проблем в некоторых командах, но имеет серьёзные недостатки: не переиспользует сессии, создаёт десятки открытых соединений, не выводит MotD, увеличивает поверхность атаки за счёт установки Node и vscode-server, позволяет удалённому хосту управлять локальной машиной через протокол, потребляет много памяти и несовместим с VSCodium. Архитектура надёжна, но есть баги с переподключением. Удалённый агент имеет доступ к полному файловому дереву без ограничения на рабочую директорию и может отправлять команды обратно в локальный VSCode, что создаёт риск обратного контроля. Установка на продакшн увеличивает уязвимости и является ответственностью пользователя. Альтернативы вроде TRAMP избегают установки дополнительного ПО и снижают риски. VSCode SSH считается анти‐паттерном, противоречащим лёгкости IDE, несмотря на удобство интегрированного SSH‐клиента. Remote‐SSH и devcontainers полезны для больших команд, но AI‐агент расширяет опасности безопасности. Передача бинарника через SSH‐туннель — естественное решение, но не устраняет системных проблем.

SAML — протокол аутентификации на основе XML, созданный в 2002 году комитетом OASIS из четырёх конкурирующих стандартов — стал основой индустрии единого входа (SSO). Он успешно решал задачу централизованной аутентификации в эпоху роста SaaS, особенно в академии и корпоративной IT, но его сложность оказалась катастрофической: XML-подписи, требующие проверки через непрозрачные библиотеки вроде libxmlsec, стали источником уязвимостей, которые большинство реализаций просто игнорируют. Дизайн «по комитету» привёл к избыточности, а архитектура — к хрупкости, несовместимости и трудностям в поддержке.

Современные альтернативы, особенно OpenID Connect (OIDC) на основе JSON и OAuth 2.0, значительно проще, безопаснее и легче интегрируются. Ведущие компании вроде Fly.io и Tailscale уже отказались от SAML, доказав, что даже для крупных корпоративных клиентов OIDC — жизнеспособный выбор. Для провайдеров идентичности путь отказа от SAML долгий, но пошаговый: остановить новые SAML-интеграции, перевести клиентов на OIDC, назначить дату отключения. SAML заслужил своё место в истории как катализатор SSO, но его пора заменить — как и XML, как и устаревшие подходы, которые больше не оправдывают свою цену.

SAML остается актуальным в корпоративной среде из-за поддержки IdP-инициированных потоков и устойчивости в закрытых сетях, несмотря на свою сложность, а OIDC не решает всех проблем, особенно в условиях изоляции от публичных провайдеров.

• Совет: Для интеграции SAML в JVM-приложения рекомендуется использовать pac4j — он упрощает работу с различными фреймворками и скрывает сложность низкоуровневых деталей.

• SAML и OIDC оба страдают от сложных реализаций: SAML — из-за XMLDSIG и канонизации, OIDC — из-за уязвимостей JWT (none-алгоритм, отсутствие проверки audience).

• Спор: Некоторые утверждают, что SAML уязвим из-за XML-подписей, но другие отмечают, что OIDC с JWT имеет не менее опасные уязвимости, включая возможность смены алгоритма подписи на 'none'.

• Проблема SAML не в XML как таковом — в 2002 году XML был логичным выбором, а альтернативы (ASN.1, кастомный формат) были не проще и не безопаснее.

• Совет: Для enterprise-продуктов поддержка SAML обязательна, так как корпоративные клиенты требуют совместимости с их существующими IdP, и отказ от SAML делает продукт невосприимчивым к рынку.

• SAML поддерживает IdP-инициированные потоки, что критично для корпоративных SSO, тогда как OIDC требует инициации от SP, что не всегда возможно в закрытых сетях.

• Спор: Одни считают, что SAML безопасен благодаря встроенной подписи, защищающей от MITM, другие возражают, что уязвимости в реализациях (например, проверка подписи по HMAC из атакуемого документа) делают его ненадежным.

• Реализации SAML часто ошибочно доверяют всему документу после проверки подписи, а не только подписанной части, что позволяет атакующему вставлять произвольные данные.

• Совет: Для снижения сложности SAML можно поддерживать только дайджесты топ-10 провайдеров и игнорировать нишевые реализации — это уменьшает объем поддержки без потери функциональности.

• Проблемы SAML не в стандарте, а в его реализациях: библиотеки libxml2 и другие неправильно обрабатывают XML-ноды, что позволяет обходить аутентификацию через MITM.

• Совет: Индивидуальные решения вроде IndieAuth и новых паттернов на базе OAuth, FedCM и DIDs обещают децентрализованную аутентификацию, но пока не получили широкой поддержки.

• OIDC не может работать с приватными IdP без публичного доступа, тогда как SAML поддерживает интеграцию в изолированных корпоративных сетях без внешних зависимостей.

• Комитетная разработка SAML привела к 'кухонному ракетостроению' — избыточным функциям, которые усложняют реализацию, в отличие от фокусированных решений вроде WireGuard.

• Совет: При интеграции SAML всегда проверяйте, что подпись применяется только к конкретной части документа, а не ко всему телу — это частая ошибка в реализациях.

• Большинство компаний не хотят поддерживать децентрализованную аутентификацию, потому что предпочитают монетизировать SSO через дополнительные услуги: анти-спам, восстановление паролей, контроль создания аккаунтов.

Выпуск Litestream v0.5.0 знаменует переход от простого резервного копирования к эффективному восстановлению на определённый момент времени (PITR). Ключевое нововведение — формат LTX, позаимствованный из проекта LiteFS. Вместо потоковой передачи отдельных страниц базы данных Litestream теперь группирует изменения в рамках транзакций, что значительно ускоряет восстановление после сбоя.

Формат LTX решает проблему "горячих страниц" — например, при частых вставках в таблицу с автоинкрементным ключом, когда изменения концентрируются на ограниченном числе страниц. Раньше Litestream обрабатывал каждую страницу отдельно, что замедляло процесс. Теперь транзакции записываются целиком, сокращая количество операций ввода-вывода и ускоряя восстановление. Это делает SQLite ещё более надёжным решением для полноценных приложений.

• Пользователи обсуждают сложности развертывания SQLite-приложений на Fly.io, включая проблемы с инициализацией и миграцией баз данных.
• Litestream получает положительные отзывы за простоту использования, низкую стоимость репликации в S3 и надежность как инструмента для резервного копирования и репликации.
• Обсуждаются технические детали Litestream: поддержка S3-совместимых хранилищ, условные записи для реализации временных lease и планы по реализации read-replicas через VFS.
• Участники сравнивают Litestream с другими решениями (LiteFS, rsync, управляемые БД), отмечая его операционную простоту и отсутствие необходимости в отдельном сервере.
• Поднимаются вопросы о практическом применении SQLite и Litestream: восстановление после сбоев, работа с нестабильным интернетом, целесообразность использования против PostgreSQL/MySQL для разных сценариев.