Un archivo de 313 MB que nadie pidió enviar

Z.ai publicó el lunes el código fuente de ZCode, su agente de programación, tres días después de que un suscriptor de pago demostrara que la herramienta empaquetaba espacios de trabajo enteros y los subía a la nube de Alibaba sin preguntar.

El desarrollador, que publica como ferstar, documentó el comportamiento el 18 de septiembre. Lo descubrió al liberar espacio en un MacBook Air y notar que el directorio ~/.zcode había superado los 700 MB. Dentro había una instantánea de un proyecto comercial: 345 MB de archivos comprimidos en un paquete cifrado de 313 MB, con 42.411 ficheros de sus espacios de trabajo.

Casi todo era historial de Git

Alrededor del 87% de la carga era el directorio .git. Según el desglose de ferstar, el componente mayor eran 196,1 MB de caché de LFS, seguidos de 102,2 MB de objetos de commit y 0,6 MB de reflogs. Eso no es una instantánea del código en el que trabaja un desarrollador. Es la historia del proyecto, con cada rama y cada estado borrado que el repositorio todavía recuerda.

Cables de red conectados a los puertos de un conmutador
Los paquetes se enviaban al almacenamiento de objetos de Alibaba. Imagen ilustrativa. Vladimir Srajber · pexels · Pexels License

El archivo se cifró antes de la subida con cifrado de sobre —una clave de contenido AES-256-CTR envuelta con RSA-OAEP-SHA256— y se envió a Aliyun OSS tras negociar credenciales con los servidores de Z.ai. La clave privada nunca llegó a la máquina del usuario. La consecuencia práctica es que el desarrollador no podía abrir su propio repositorio subido, ni tampoco el cliente que lo había creado.

Los ajustes no servían

ZCode ofrecía dos ajustes que parecían gobernar esto: “Optimize Experience” y “Repo Snapshot Indexing”. Desactivarlos no detenía la captura, porque la cadena se ejecutaba incondicionalmente una vez iniciada la sesión en la aplicación. Borrar el paquete pendiente tampoco ayudaba: en media hora se construía un nuevo archivo de 313 MB. Una instantánea había acumulado 564 intentos fallidos de subida antes de que alguien lo notara.

La corrección, y lo que no puede demostrar

Discos duros colocados sobre una superficie de trabajo clara
Una instantánea abarcaba 42.411 ficheros de los espacios del desarrollador. Imagen ilustrativa. Marta Branco · pexels · Pexels License

Z.ai dice haber solucionado el problema. Su consejero delegado, Zhang Peng, afirmó que la empresa había completado la corrección necesaria, según RuntimeWire, y a continuación la compañía publicó el código.

El repositorio en github.com/zai-org/ZCode está bajo licencia Apache-2.0 y cubre la aplicación de escritorio, la interfaz de navegador, el agente de terminal, los servicios de backend, la interfaz compartida y el entorno de ejecución de agentes. Se creó el 20 de septiembre y abrió con dos commits: un volcado consolidado, no el historial de desarrollo que permitiría auditar cómo se escribió la ruta de subida o cuándo cambió.

El propio aviso de Z.ai admite el límite: el procesamiento interno realizado después de que las solicitudes lleguen a su pasarela queda fuera del alcance verificado por el repositorio del cliente. Publicar el cliente dice lo que el software hace ahora. No dice qué pasó con los repositorios ya subidos, si se borraron ni quién dentro de la empresa podía leerlos.

Qué vigilar

El repositorio no lleva SECURITY.md ni avisos publicados. Quienes usaron ZCode no tienen forma de confirmar qué se conservó, ni de verificar que los binarios distribuidos coinciden con el código publicado sin compilarlos y compararlos. Si Z.ai responde a alguna de las dos preguntas será la prueba de si abrir el código fue corrección o publicidad.