Используйте GitHub Private vulnerability reporting / Security Advisory. Не публикуйте рабочий exploit, router backup или recovery snapshot в обычном Issue. Мы постараемся подтвердить получение отчёта в течение 7 дней. Если private reporting временно недоступен, запросите приватный контакт у владельца через его GitHub-профиль, не раскрывая детали публично.

В отчёте достаточно:

• версии nfqws2-watchdog и nfqws2-keenetic;
• модели/ветки прошивки без серийного номера;
• минимальных шагов воспроизведения;
• результата nfqws2-doctor full;
• ожидаемого и фактического поведения.

Удалите пароли, ключи, токены, MAC/IP клиентов, публичные endpoints и любые платёжные данные. Проект никогда не просит номер карты, срок действия или CVV.

• package update ограничен именем nfqws2-keenetic и предварительным dry-run;
• recovery archive использует whitelist, строгий manifest schema/scope и фиксированный staging;
• tar/list streams и физический входной архив ограничены по размеру;
• каждый tar/gzip/member stream дополнительно зажат текущим местом выше защищаемого 8 МиБ остатка, поэтому низкий запас не ослабляет archive caps;
• новые snapshot получают обязательный adjacent SHA-256; verify проверяет его по замороженной копии, но checksum обеспечивает integrity, а не authentication;
• restore атомарно заменяет каждый отдельный файл; обычные ошибки и перехватываемые SIGHUP/SIGINT/SIGTERM запускают best-effort rollback;
• restore транзакционно фиксирует существование и точные metadata /opt/etc/nfqws2, fail-closed проверяет его parent и нормализует рабочий каталог в root:root 0755; rollback возвращает прежние metadata каталога только после восстановления всех дочерних путей;
• watchdog, init и recovery сериализуются kernel flock; PID проверяется вместе с argv и временем старта процесса;
• recovery staging находится под отдельным root:root 0700 /opt/var/lib/nfqws2-watchdog/recovery-work, файлы — 0600;
• статические nfqws list-файлы после restore получают root:<service> 0440, изменяемый auto.list — <service>:<service> 0600, каталог списков — 0750, а родительский каталог nfqws2 — root:root 0755;
• watchdog-конфиг разбирается как данные по whitelist, а не исполняется через shell;
• автоматическое пакетное обновление выключено по умолчанию; exact package name ограничивает scope, но не доказывает provenance настроенных feeds;
• daemon не принимает сетевые соединения;
• doctor и логи не выводят клиентские идентификаторы и endpoints.

Per-file atomic replacement не делает весь multi-file restore crash-atomic. Recovery не ведёт persistent transaction journal и не устанавливает fsync barriers для всего набора файлов, каталогов и состояния служб. Поэтому rollback покрывает обычную ошибку или сигнал только пока процесс способен выполнить exit-trap.

SIGKILL, потеря питания и внезапный unmount/отказ накопителя не могут быть перехвачены. После них возможны mixed old/new files, неполные metadata и остановленные либо частично восстановленные службы. Проект не обещает durability завершённого restore через такой crash.

После повторного mount сначала сохраните и вручную исследуйте уцелевшие portable pre-restore backup из /opt/var/backups/nfqws2-recovery и приватный rollback work из /opt/var/lib/nfqws2-watchdog/recovery-work. Затем восстановите согласованный набор только из доверенной копии и запустите nfqws2-doctor full; точный порядок описан в recovery guide. Backup/work сами могли не сохраниться полностью, поскольку journal/fsync guarantee отсутствует.

Snapshot содержит nfqws2.conf, который upstream использует как shell-конфиг, а также доменные и IP-списки. Поэтому команда verify подтверждает только безопасную структуру архива — не его автора и не смысл custom-конфигурации. Выполняйте restore только для собственного snapshot из доверенного хранилища. Не скачивайте recovery-архивы из Issue, чатов или чужих релизов.

Новые snapshot создаются только в приватном каталоге /opt/var/backups/nfqws2-recovery с mode 0700; это исключает небезопасные временные файлы в произвольном общедоступном каталоге.