ZCode пытался отправить 313 МБ проекта 564 раза, но эта история оказалась еще неприятнее

В истории с ZCode легко зацепиться за самые громкие цифры: 313 МБ данных и 564 попытки передачи. Именно они разошлись по публикациям о китайском ИИ-сервисе Z.ai. Но после уточнений автора исходного технического разбора картина стала точнее. Большой архив коммерческого проекта остался в локальной очереди pending. По данным разработчика ferstar, его маршрутизатор не зафиксировал успешной передачи этих данных за пределы домашней сети.
Это не снимает вопрос к самому механизму. ZCode автоматически сформировал полный снимок рабочего пространства объемом около 345 МБ и после сжатия и шифрования получил файл размером 313 070 842 байта. В него попали 42 411 файлов. Около 86,6% содержимого приходилось на каталог .git, включая объекты Git, кеш Git LFS и reflog. Иными словами, речь шла не только о текущих файлах проекта. В архив могла попасть история разработки и данные, которые разработчик уже не видел в рабочем дереве.
564 неудачные попытки особенно хорошо описывают характер проблемы. Клиент не ограничился одной ошибкой передачи, а сохранял архив в очереди и продолжал повторять запрос. При этом исследователь не обнаружил в изученной версии нормального пользовательского выключателя для этого механизма. Отключение настроек, которые по названию могли показаться связанными со сбором данных, упаковку рабочей области не прекращало.

Фото: ZCode home page)

И все же утверждать, что именно 313 МБ коммерческого кода оказались в облаке, нельзя. Ferstar позднее отдельно это уточнил. Зато он проверил механизм на небольшом публичном репозитории из 538 файлов: зашифрованный архив размером около 15 КБ был принят сервером. Это уже подтверждает, что цепочка не ограничивалась созданием локальных резервных копий.
Технически перед отправкой ZCode получал от серверной части параметры доступа к объектному хранилищу и открытый RSA-ключ. Содержимое рабочего пространства упаковывалось и шифровалось, после чего клиент пытался загрузить полученный файл в облачное хранилище Alibaba Cloud. Закрытого ключа на машине пользователя не было, поэтому локально расшифровать созданный архив исследователь не мог.

Фото: ZCode home page)

На этом фоне особенно заметно расхождение с формулировками политики конфиденциальности ZCode. В ней говорится о сборе текста, файлов и кода, которые пользователь передает сервису для работы функций ZCode. Автоматическое создание снимка практически всего рабочего пространства вместе с историей Git там явно не описано. Для корпоративного репозитория разница принципиальная: разработчик может сознательно отправить модели отдельный файл, но совсем не рассчитывать на передачу всей истории проекта.

Фото: ZCode home page)

Z.ai признала проблему и принесла извинения. В журнале изменений ZCode версия 3.14.0 от 19 сентября содержит исправление «аномальных загрузок» функции Repository Wiki. Компания также заявила об удалении ранее загруженных данных и намерении открыть исходный код ZCode для внешней проверки. Сам факт исправления подтвержден официальным журналом версий, а вот уничтожение уже полученных сервером данных независимо проверить по доступной информации нельзя.
Эта история поэтому не сводится к одной неудачной передаче 313 МБ. Самый неприятный факт в том, что ИИ-инструмент для программирования мог самостоятельно сформировать зашифрованную копию рабочего пространства, включив туда историю Git, и запустить облачную отправку без отдельного понятного подтверждения пользователя. Большой архив в описанном случае остался на компьютере, но работоспособность механизма передачи была подтверждена на меньшем репозитории. Для инструмента, которому разработчик дает доступ к коммерческому исходному коду, это уже достаточная причина требовать прозрачного управления тем, какие именно файлы покидают компьютер.