Широко используемая библиотека fsnotify, предоставляющая уведомления об изменениях в файловой системе для Windows, Linux, macOS и других платформ, на прошлой неделе оказалась в центре спора о правах доступа. Ситуация, когда один из мейнтейнеров лишился доступа к репозиторию, а публичный пост об этом был удалён, заставила многих разработчиков задуматься: не является ли это признаком компрометации проекта. Пока нет никаких доказательств того, что релизы fsnotify были скомпрометированы. Проблема оказалась более прозаичной и знакомой: когда у популярного проекта нечётко определены роли ответственных за сопровождение, правила публикации и порядок проверки кода, сторонние пользователи не могут легко отличить обычный конфликт внутри сообщества от ранних признаков захвата управления.
Библиотека fsnotify, написанная на языке Go, насчитывает 10,7 тысячи звёзд на GitHub, 969 форков и более 321 тысячи зависимых проектов. При таком масштабе неопределённость относительно того, кто может объединять и выпускать код, мгновенно становится проблемой для всех, кто использует библиотеку. Опасения были связаны с её местом в стеке: это низкоуровневый код для отслеживания файлов, который задействован в инструментах разработчика, командной строке, серверах разработки и инфраструктурных процессах.
Тревогу поднял разработчик Go по имени Ясухиро Мацумото, известный под псевдонимом mattn. Он сообщил в X (ранее Twitter), что его удалили из организации fsnotify на GitHub. В удалённом посте на японском языке он написал, что ранее проект искал мейнтейнеров, он присоединился из-за своего опыта, но когда попытался начать вносить вклад, его раскритиковали за "самодеятельность". Он также заявил, что другой участник "похоже, зарвался и удалил даже оригинального автора fsnotify из организации, что пугает".
Пост был удалён, но его содержание стало центральной темой горячего обсуждения в GitHub Issue. Там пользователи попросили мейнтейнера Мартина Турнуа (arp242) объяснить удаление других разработчиков. Инженер из Grafana Оси Ямагути, открывший тему, отметил, что fsnotify широко используется крупными open source-проектами и что потребители библиотеки нуждаются в дополнительном контексте для оценки происходящего.
Ситуация выглядела рискованной из-за сочетания сигналов: популярная зависимость, недавние релизы, изменение прав доступа, удалённый публичный пост и неопределённость относительно того, кто имеет полномочия проверять и публиковать изменения. Именно это заставило людей задавать вопросы о безопасности цепочки поставок. В апреле пользователь спросил, сможет ли fsnotify выпустить новый релиз, после того как автоматические сканеры начали помечать проект как не сопровождаемый. "Автоматические сканеры кода считают этот проект неподдерживаемым, если новый релиз не появляется в течение 12 месяцев, - говорилось в issue. - Этот порог был пройден 4 апреля 2026 года". Этот случай показывает, как инструменты безопасности могут создавать давление на зрелые инфраструктурные библиотеки, которые обычно обновляются всплесками.
Вскоре после этого Мацумото выпустил версию v1.10.0, а затем v1.10.1. Последний релиз исправлял поведение inotify - механизма уведомлений в Linux, где вложенные наблюдатели, имеющие общий префикс пути, могли ошибочно удаляться или переименовываться.
Мейнтейнер Турнуа в обсуждении на GitHub утверждает, что удалённые аккаунты имели права на коммиты по историческим причинам, а не потому, что их владельцы были активными мейнтейнерами. Он заявил, что недавние изменения были объединены слишком быстро, без достаточного обсуждения, и требовали доработки. "Это не случай, когда один мейнтейнер удаляет других, потому что они никогда не поддерживали проект в каком-либо осмысленном смысле, пока не назначили себя таковыми без обсуждения и не начали коммитить сомнительного качества код", - пояснил Турнуа. Он также опроверг предположения о враждебном захвате. "Рассказ о том, что arp242 злонамеренно захватил проект, просто неверен, - написал он, указав на историю коммитов. - Взгляните на лог коммитов - это не секрет".
Он объяснил, что недавние работы продвигались слишком быстро, не получили достаточного тестирования на всех поддерживаемых платформах и рисковали вернуть ту неконсистентность, которую Турнуа годами устранял. Кроме того, он назвал финансовый вопрос главной причиной удаления доступа. Мацумото закоммитил изменение файла FUNDING.yml (для получения спонсорских средств) напрямую в главную ветку без обсуждения, что Турнуа расценил как неуважение. Мацумото в ответ признал, что часть его удалённого поста была ошибочной - в частности, утверждение, что доступ отозвали у оригинальных мейнтейнеров, - и извинился. Он также назвал обновление FUNDING.yml ошибкой, но сказал, что его недавняя активность была реакцией на отсутствие релизов более года.
Дополнительную двусмысленность внёс перевод. Один из комментаторов в GitHub Issue отметил, что в японском языке часто опускается подлежащее, и машинный перевод на английский может его вставить, чтобы сделать предложение грамматически верным. Часть удалённого поста была переведена как "мы наняли мейнтейнера", хотя, по словам комментатора, Мацумото "на самом деле не говорил 'мы'". Сам Мацумото позже сообщил, что не является носителем английского и использует машинный перевод для комментариев в коде.
Беспокойство дошло и до Kubernetes. В issue под названием "fsnotify/fsnotify - Healthy or not?" говорилось, что за проектом нужно внимательно следить и, при необходимости, Kubernetes должен рассмотреть форки или сделать собственный. Там упоминалась отдельная реализация gofsnotify/fsnotify, которую Мацумото создал после потери доступа к оригинальной организации. Хаотичный характер инцидента показал практическую цену неопределённости в управлении. Даже без доказательств вредоносного кода внезапное изменение того, кто контролирует зависимость, заставляет пользователей переходить в режим проверки.
"Такие зависимости, как fsnotify, находятся достаточно низко в стеке, чтобы о них 'забывали', - прокомментировал в обсуждении Себастьян ван Стайн, principal software engineer в Docker и мейнтейнер проектов Moby, containerd и runc. - Атаки на цепочку поставок - реальность, и Dependabot позволяет проектам 'просто обновить зависимость', не задумываясь". Ранние стадии реальной компрометации цепочки поставок и ранние стадии спора мейнтейнеров извне могут выглядеть одинаково. И то и другое может включать неожиданные релизы, неясные полномочия, изменение доступа и противоречивые публичные заявления.
После инцидента с xz-utils, где вредоносный код был внедрён через долгосрочную социальную инженерию, многие мейнтейнеры всё ещё остаются в напряжении. Пользователи теперь относятся к необычной активности в критических зависимостях с гораздо большим подозрением, чем несколько лет назад. Основная проблема безопасности fsnotify заключается в том, что пользователи имели ограниченную видимость того, как назначались, отзывались и проверялись права мейнтейнеров.
Для широко используемых пактов с открытым исходным кодом доступ мейнтейнеров перестаёт быть внутренним делом, когда пользователи не могут понять, кто на самом деле контролирует конвейер релизов. Инцидент с fsnotify показывает, как мало двусмысленности требуется, чтобы запустить такую проверку. Один спор об управлении доступом в низкоуровневой зависимости заставил пользователей проверять историю релизов, следить за форками и спрашивать, безопасны ли ещё обычные обновления. Чёткое определение ролей и прав на выпуск не предотвратит все споры, но позволит легче верифицировать изменения в доступе до того, как место фактов займут догадки.
