Эндрю Триджелл: rsync и возмущение

3 июня 2026 года Эндрю Триджелл, один из авторов rsync (и создатель Samba), написал пост, перевод которого предлагается ниже. Поводом стала волна негодования (показательный тикет, обсуждение на Hacker News) после релиза rsync 3.4.3, в котором закрыли шесть уязвимостей: пользователи начали сообщать о регрессиях, из‑за которых ломались уже работающие конфигурации и сценарии, годами считавшиеся привычными, надежными, рутинными.

Можно было бы сказать «бывает», но масла в огонь подливал тот факт, что незадолго до этого в истории коммитов rsync появилось около пятидесяти изменений, подготовленных с помощью Claude. На этом фоне любые сбои почти автоматически стали читаться как «в важный инфраструктурный проект пустили ИИ, и он нагенерировал плохие исправления» — сами понимаете, как к такому сейчас относится ИТ‑сообщество.

В списке того, что поломалось, были и инкрементальные бэкапы с несколькими --compare-dest, и сборка на старых ядрах Linux и старых версиях macOS, и поведение --link-dest, и другие привычные сценарии. Триджелл ответил не тредом в комментариях, а отдельной заметкой в своём блоге на Medium — местами раздраженной, местами ехидной, но ценной именно тем, что это взгляд опытного инженера, который сейчас реально держит на себе проект.

Ниже перевод поста, считаю, что текст стоит читать «как есть»:

rsync и возмущение

Я давно забросил блог (если не считать редких заметок про ArduPilot). Обычно я просто пишу код и надеюсь, что он окажется людям полезен, поэтому мне немного непривычно писать этот текст. Но, учитывая, сколько яростных постов в последнее время прилетело в мой адрес, я подумал, что, может быть, все‑таки стоит что‑то написать.

Как мейнтейнера rsync, меня в последнее время — как и многих разработчиков open source‑пакетов — накрыло волной сообщений о проблемах безопасности. Многие из этих сообщений сгенерированы ИИ (хотя не все; среди них есть заметные исключения — с очень тщательным и качественным ручным анализом).

Когда эта волна стала нарастать, я понял, что оборону rsync нужно серьезно усиливать: нам нужны были куда более тщательные наборы тестов, анализ покрытия кода, CI‑тестирование на гораздо большем числе платформ, целенаправленный и тщательный поиск возможных проблем безопасности (чтобы хотя бы часть из них я находил раньше других людей!) и целый ворох приемов усиления защиты по принципу defense‑in‑depth. Все это огромный объем работы. Я на пенсии (хотя жена, возможно, со мной поспорит!), и я бы куда охотнее ходил под парусом, чем занимался проблемами безопасности rsync, поэтому я обратился к нескольким ИИ‑инструментам за помощью с этой работой. Я совершенно об этом не жалею, хотя по буре анти‑ИИ‑ярости видно, что многие считают: уже за одну мысль об этом меня надо выпороть батогами.

Разбирать все обвинения, которые мне предъявляют с пеной у рта, было бы слишком долго, поэтому ограничусь несколькими:

— Я переписал набор тестов rsync на Python вместо старой схемы на shell‑скриптах. Архитектуру этого набора я спроектировал сам (и, честно говоря, вполне ею доволен), но черную работу сделал с помощью Claude, перепроверяя результат через Codex и Gemini. Это не было простым вайбкодингом в духе «convert test suite to python». Я инженер‑программист с 40-летним опытом (да, я СТАРЫЙ!), поэтому сначала продумал дизайн и составил план, как все это проверить. Я использовал ИИ‑инструменты для черной работы, потому что они для нее хороши. Я сам просмотрел каждую часть и потратил уйму времени в CI, доводя все до ума (с тех пор я перешел на набор локальных VM, чтобы большую часть тестов гонять у себя и меньше ждать CI). То, что вы видите в истории коммитов приписку «co‑authored by Claude», — это лишь верхушка пресловутого айсберга программной инженерии.

— тем, кто говорит что‑то вроде «я получил PhD в xyz uni, и я говорю вам: ваши LLM — это просто стохастические инструменты, которые все выдумывают, и мир развалится, если ими пользоваться», скажу прямо: вы отстали от времени. За последние несколько месяцев программная инженерия изменилась радикально. А IT‑безопасность и сопровождение ПО под напором этого потока сообщений буквально за последние несколько недель изменились полностью и бесповоротно. Все, что вы узнали об этом в прошлом году, теперь будто с другой планеты. Ах да, кстати, у меня тоже PhD по компьютерным наукам; и да, я действительно довольно много работал с нейронными сетями; и да, все мои знания того периода жизни тоже безнадежно устарели. Кроме того, никто на самом деле не знает, не сводится ли человеческий интеллект к такому же стохастическому предсказанию, только более тонкозернистому. Может быть, однажды мы с этим разберемся, а может быть, и нет. Суть в том, что я знаю (ну, примерно!), как работают LLM, но от этого они не становятся бесполезными. Да, это значит, что с ними нужно быть осторожным; но я и осторожен — или настолько осторожен, насколько могу быть, учитывая, что мне хочется ходить под парусом, а не разгребать поток мусора от так называемых интернет‑экспертов.

— да, в релизе rsync 3.4.3 в некоторых сценариях использования появились регрессии. В этом релизе я вполне сознательно решил: если уж ошибаться, то в сторону исправления проблем безопасности, и из‑за изменений оказались задеты некоторые вполне корректные (но необычные) сценарии. Ни один из этих случаев не покрывался ни существующим набором тестов rsync, ни всем ручным тестированием, которое я проводил (да, я пользуюсь rsync, а не только разрабатываю его). Я разбираюсь с этими регрессиями и благодарен всем, кто сообщил о них в GitHub‑репозитории — в issues или PRs. Я читаю эти сообщения, даже если не на все быстро отвечаю. Прошу прощения, если эти регрессии задели ваш сценарий использования rsync. Если риск безопасности вас не смущает, вы, конечно, можете пользоваться более старым релизом.

— тем, кто говорит: «боже мой, он не использовал pytest, он вообще хоть что‑нибудь понимает!». Я много пользовался pytest в других проектах. Здесь он плохо подходит. В этом наборе тестов мне нужно делать вещи, которые в pytest было бы очень трудно сделать (по крайней мере, судя по моему опыту с ним), поэтому я спроектировал правильный подход для конкретной задачи. Так я делал всю жизнь: я часто в итоге создаю новые подходы, потому что существующий оказывается не совсем тем, что нужно. Лично я считаю, что это хорошо.

Теперь о будущем, потому что до конца нам еще очень далеко. Сообщения о проблемах безопасности продолжают валиться. Прямо сейчас я работаю над целой пачкой CVE. К счастью, к работе подключились еще несколько очень хороших разработчиков с отличными навыками системной разработки и знаниями в области безопасности. Отчасти я узнал о некоторых из них именно из‑за всей нынешней ярости, так что, пожалуй, и от бури ярости бывает польза. В следующем релизе появятся благодарности нескольким отличным новым разработчикам rsync.

Сейчас я выбираю между релизом 3.4.4, который смягчит часть регрессий, и переходом сразу к 3.5.0, который я планировал с гораздо более крупными изменениями. Релиз 3.5 очень сильно поднимет планку безопасности rsync, но это огромный объем изменений. Именно масштаб нужных правок серьезно подтолкнул меня к переписыванию набора тестов — нельзя быстро вносить масштабные изменения в программу вроде rsync без по‑настоящему всеобъемлющего набора тестов. Я думал, что будет хорошей идеей сначала публично, в master, сделать основу нового набора тестов; но, учитывая всю ярость, которую это вызвало, возможно, идея была неудачной. Как бы то ни было, новый набор тестов очень помог, и у меня есть большая куча дополнительных тестов по проблемам безопасности; когда выйдет 3.5, вы все сможете насладиться их чтением.

Я надеюсь (возможно, наивно), что нынешним рывком мне удастся вырваться вперед, и поток превратится в ручеек, а затем иссякнет. Мечтать не вредно.

Если кто‑нибудь из тех, кто сейчас публикует яростные посты, и правда захочет просмотреть какой‑нибудь опубликованный мной код и высказать конструктивные замечания, это было бы замечательно! Если же вы просто хотите еще немного побушевать, уверен, вы найдете какой‑нибудь уголок интернета, где этому будут рады.

Что до всех, кто говорит: «я сделаю пакет openrsync для платформы XXX, и мы будем использовать его!». Меня это скорее веселит. Если вы все‑таки решите пойти этим путем, я бы посоветовал вам попробовать новый набор тестов rsync на openrsync — если сможете переварить что‑то, в написании чего помог ИИ. Я попробовал сегодня: сейчас openrsync проваливает 85 тестов из 98, так что уверен, вам не понадобится много времени, чтобы довести его до нужного уровня. Запускается это так: «./runtests.py — rsync‑bin=../openrsync/openrsync — use‑tcp». Надо признать, многие провалы — это просто функции, которых в openrsync нет, но все равно результат так себе.

В завершение: я от души посмеялся, когда на днях наткнулся на эту страницу https://www.tridge.com/ — выходит, может быть, я и правда всю жизнь был роботом; может быть, поэтому ненависти к ИИ‑инструментам у меня меньше, чем у других.

От себя добавлю: в этой истории очень легко зацепиться за слово «ИИ» и дальше уже не смотреть ни на что. Но из текста Триджелла видно, что для него Claude, Codex и Gemini были не заменой инженерной ответственности, а инструментами для черной работы: дизайн, проверку, ревью и решение о рисках он оставляет за собой. Спор от этого, конечно, не исчезает, но лично для меня вопрос поворачивается иначе: не «можно ли вообще пользоваться ИИ», а «какие тесты, ревью и правила процесса нужны, если им пользуешься».

С другой стороны, регрессии реальны. Если после исправления уязвимостей ломаются редкие, но корректные сценарии, значит, проекту не хватало покрытия именно там, где пользователи ожидали стабильности. Но ровно то же самое могло бы сломаться и без всякого ИИ, если бы похожие изменения внес человек: проблема не магически появляется из-за Claude, она появляется там, где нет тестов на важное поведение. Поэтому важной для меня частью ответа Триджелла было не оправдание ИИ, а информация про работу над новой тестовой системой (testsuite, runtests.py), про покрытие кода, про CI на разных платформах, про version-mixing-тесты, про fleettest.py и про большой набор security-тестов для будущего rsync 3.5 — например, chdir-symlink-race, chmod-symlink-race, secure-relpath-validation, link-dest-relative-basis и link-dest-module-escape.

Пожалуй, самый полезный вывод здесь не в том, чтобы выбрать сторону в очередной войне «ИИ против людей». Rsync — инфраструктурная утилита из той категории, которую все считают само собой разумеющейся, пока она не ломается. Если из этой бури получится больше тестов, больше ревью и несколько новых сильных мейнтейнеров, это станет куда ценнее, чем еще один круг взаимных обвинений.