by @ssrjkk

Каждый тег публикует Raven.exe вместе с Raven.exe.sha256 и attest-документом о сборке:

sha256sum --check Raven.exe.sha256     # Windows: certutil -hashfile Raven.exe SHA256
gh attestation verify Raven.exe --repo ssrjkk/raven

Контрольная сумма отвечает на вопрос «целый ли файл», attest — «из этого репозитория, из этого коммита и этого запуска Build EXE». Ни то, ни другое не означает «безопасно запускать».

Мы серьёзно относимся к безопасности Raven AI. Если вы нашли уязвимость, сообщите нам как можно скорее.

Не создавайте публичные GitHub issues для отчётов об уязвимостях.

Вместо этого напишите на ray013lefe@gmail.com или в Telegram @ssrjkk.

Вы получите ответ в течение 48 часов. Если ответа нет — напишите повторно.

• Тип уязвимости (напр., SQL-инъекция, XSS, подбор ключей)
• Полные пути к исходным файлам, связанным с проблемой
• Где находится уязвимый код (тег/ветка/коммит или прямая ссылка)
• Особая конфигурация, необходимая для воспроизведения
• Пошаговая инструкция для воспроизведения
• PoC-код (если возможно)
• Влияние: что злоумышленник может сделать

По умолчанию Raven использует парную политику:

• Неизвестные отправители получают код привязки
• Бот не обрабатывает сообщение, пока код не подтверждён
• Подтверждение: raven pairing approve <channel> <code>

Доступные политики:

• pairing (по умолчанию) — код привязки для новых отправителей
• open — все сообщения обрабатываются (требуется настройка allowFrom)
• closed — только явно разрешённые отправители

• exec_security: deny (по умолчанию), ask или full — относится к exec-классу инструментов: shell, python, process_*, browser_*, mcp_*, node_*, chaos_*, db_query, http_post, email_send, git commit/push/pull/checkout, plugin_*. При deny агент отказывает им всем — этот режим действительно проверяется в Agent._execute_tool(), а не только задокументирован
• exec_ask_mode: off, on-miss (по умолчанию — always). Подтверждение, которое некому запросить, — это отказ, а не разрешение: без confirm_fn инструмент блокируется с указанием причины. В CLI спрос идёт в терминал и отказывает, если терминала нет; из 15 адаптеров каналов спросить умеют только Telegram и Discord, остальные (включая webchat) отказывают
• workspace_only: true (по умолчанию) — ограничивает пути, но требует WORKSPACE_PATH; без него ограничивать нечем, и raven doctor об этом сообщает
• роли инструментов: dangerous=True и allowed_roles исполняет ToolRegistry.call(role=…); вызов без субъекта получает наименьшие привилегии, пустой список ролей закрывает инструмент. Роль задачи указывает тот, кто её создал (веб-сессия, CLI = admin), а не планировщик
• sandbox_mode: non-main (по умолчанию) — изолированное выполнение
• sandbox_backend: subprocess (по умолчанию), docker или none
• изменения политик (POST /api/tools/policy) — только роль admin

Подробнее: docs/security/overview.md, а все внешние адреса, куда процесс может отправить данные, перечислены в docs/security/egress.md.

• all (по умолчанию) — полный контекст
• allowlist — только разрешённые домены
• allowlist_quote — разрешённые домены, цитаты как есть

• По умолчанию: 60 запросов в 60-секундное окно на IP
• Burst-множитель: 1.5×, после чего IP временно блокируется
• Заблокированные IP разблокируются через 2× окна

Запустите raven security audit для 23 стандартных и 8 глубоких проверок:

• Надёжность секретных ключей
• Конфигурация API-ключей
• Права доступа к файлам
• Конфигурация CORS
• Принудительный HTTPS
• Конфигурация sandbox
• Таймауты сессий
• Безопасность Docker
• Уязвимости зависимостей

Пожалуйста:

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

Мы благодарим исследователей безопасности, которые помогают нам защищать пользователей. За валидный отчёт мы укажем вас в release notes (если вы не предпочитаете анонимность).