1. Откройте issue в этом репозитории и опишите проблему без деталей эксплойта: версия/файл, условия воспроизведения «в общих чертах», ожидаемый и фактический результат. Подробности раскрывайте по запросу в том же треде или в приватном канале, если он будет указан сопровождающим.
2. Не публикуйте в issue рабочие эксплойты, готовые конфиги для обхода защиты, а также любые ключи, токены или адреса реальных узлов — даже своих.
3. Пожалуйста, дайте сопровождающему разумное время (до 90 дней) на выпуск исправления, прежде чем публиковать технические детали самостоятельно.

Приоритет внимания: утечка секретов из установщиков и рендеров конфигов, повреждение/подмена загружаемых файлов (sing-box, rule-set'ы), инъекция команд через env-переменные, поведение TUN-режима, затрагивающее соседние хосты в сети.

• Предполагаемая функциональность, а не дефект: маскировка трафика, обход сетевых блокировок, скрытие протоколов от DPI — это заявленное назначение инструмента.
• Блокировка адреса вашего VPS/домена, деградация или полная остановка лестницы средствами сетевого цензора. Комплект снижает вероятность, но не гарантирует неуязвимость; архитектурные ограничения (например, CGNAT на Пути Б) тоже не дефект.
• Компрометация узла при утечке ваших секретов (node.env, server.env, keys.txt, токены), произошедшей по вашей вине: публикация в git-истории, пересылка в мессенджерах, хранение в облаке без шифрования.
• Проблемы сторонних компонентов (sing-box, Cloudflare, rule-set'ы SagerNet) — сообщайте в соответствующие апстрим-проекты; здесь они фиксируются только тогда, когда дефект воспроизводится через конфиги или скрипты этого репозитория.
• Отсутствие функции, не заявленной в README, и «недостаточная обфускация» как общее пожелание без конкретного способа детектирования.

Код предоставляется «как есть» по лицензии MIT (см. LICENSE). Используйте только на своей инфраструктуре и в соответствии с законами своей юрисдикции.

Расширение «Антицензор» намеренно использует высокий риск-профиль:

• host_permissions: <all_urls> — движок прокси (DNR + PAC) должен уметь перехватывать запросы к любому сайту, иначе обход блокировок неполон. Это осознанный компромисс, а не недосмотр.

• Поддержка внешнего PAC по URL — supply-chain риск: файл политик, полученный по ссылке, исполняется как правила маршрутизации. Правила:

  1. указывать URL только своего узла (sovereign-node) или источников, которым доверяешь как себе;
  2. только HTTPS;
  3. при смене источника — сверять содержимое PAC перед включением.

Сужение host_permissions возможно отдельным тактом (перечень доменов в rules/), но сломает прокси на произвольных сайтах — решение за владельцем (PID 1).