Controvérsia sobre upload de ZCode: a versão reparada está aqui, contas antigas ainda precisam ser verificadas

📅 2026-09-20

Resumo:

ZCode, a ferramenta de programação de IA da Zhipu, foi questionada por seu empacotamento em segundo plano e upload de projetos de usuários.

Os desenvolvedores descobriram que não apenas o código atual foi empacotado, mas também o histórico do Git que salvou as modificações anteriores. Em 18 de setembro, o desenvolvedor ferstar divulgou os resultados da solução de problemas: ZCode gerou uma cópia do projeto nesta máquina e tentou carregá-lo repetidamente. Posteriormente, outros usuários também forneceram registros de revisão. Alguns descobriram que a cópia do projeto havia sido aceita pelo servidor e alguns questionaram se a troca do índice do warehouse poderia impedir o upload. Os usuários perguntaram: Por que o software coleta esse conteúdo e como evitar que ele seja carregado?

ZCode pediu desculpas naquele dia e atribuiu o problema às funções relacionadas ao "índice base de código" que estavam ativadas por padrão nos primeiros dias. A empresa disse que o Repo Wiki pode acionar o upload de dados ao gerar uma enciclopédia de armazém na nuvem, e os dados relevantes serão destruídos imediatamente após a geração. Também prometeu abrir o código-fonte do cliente e introduzir análises de terceiros.


Em 19 de setembro, o ZCode lançou a versão 3.14.0 e o log de atualização dizia: "Corrigido o problema de upload anormal da enciclopédia do warehouse." Ferstar também complementou os resultados da revisão, dizendo que o código de upload relevante foi removido na nova versão.

Depois de ter o código aberto, pessoas de fora podem verificar por que o software foi carregado e quais alterações foram feitas desta vez. No entanto, a empresa ainda precisa fornecer registros de recebimento e processamento de quais arquivos o servidor recebeu anteriormente e se eles foram excluídos conforme prometido.

Se a análise de terceiros analisar apenas o cliente, ela não conseguirá responder às perguntas dos usuários sobre esse lote de dados históricos.

1. Limpe o disco e encontre uma cópia do projeto

ferstar inicialmente não estava verificando o comportamento do upload. Quando ele estava limpando o disco do computador, descobriu que o diretório de dados do ZCode ocupava muito espaço e, depois de pesquisar, encontrou um arquivo criptografado de 313 MB. É um instantâneo gerado pelo software para o projeto, o que equivale a empacotar um lote de arquivos do projeto em uma cópia.

A lista salva com o instantâneo lista 42.411 arquivos. Calculado pelo volume de arquivos, aproximadamente 86,6% deles vêm do diretório .git que salva registros de versão, incluindo objetos históricos do Git, logs de operação e cache de arquivos grandes do LFS.

Para onde esses documentos serão enviados? ferstar continuou a verificar o código do cliente e encontrou um processo de upload: o software primeiro solicitou um certificado de upload para o servidor ZCode, depois empacotou e criptografou o arquivo, enviou o arquivo para o serviço de armazenamento em nuvem OSS do Alibaba Cloud e, finalmente, a nuvem notificou o servidor ZCode para registrar e receber o resultado.

No entanto, o upload do arquivo de 313 MB foi tentado 564 vezes, mas falhou em todas as vezes e permaneceu na máquina local aguardando uma nova tentativa.

Ferstar esclareceu isso especificamente na atualização de 19 de setembro e também acrescentou: Seu outro instantâneo menor de armazém público, o status mostrou que o servidor o aceitou.

O desenvolvedor Vonng revisou-o na versão macOS do ZCode 3.12.3. Ele encontrou um instantâneo do espaço de trabalho comum que não continha .git, e o registro mostrou que ele havia sido aceito pelo servidor; nos outros dois snapshots, .git representou 93,9% e 98,5% do volume total do arquivo. O cliente obteve as credenciais de upload, mas os registros públicos não puderam confirmar se o upload foi concluído.

ZCode também recebeu relatórios relevantes na área de feedback do GitHub. O remetente da edição nº 707 disse que encontrou uma lista de snapshots aceitos pelo servidor, que continha mais de dois mil caminhos .git. Ele também refletiu que o snapshot virá com configurações globais como informações de conexão, scripts de execução automática e arquivos de comando definidos pelo usuário para a ferramenta de IA. Seu julgamento é baseado em registros locais e não há resultados de auditoria no servidor para verificar.

2. O código excluído também pode ser seguido

O histórico recorrente do Git nessas listas é o que preocupa os usuários.

O Git permite que os desenvolvedores recuperem versões antigas do código, o que também significa que o conteúdo excluído hoje pode não ter desaparecido do warehouse.

Chaves, arquivos de configuração ou endereços internos que foram enviados por engano podem ser retidos em objetos históricos.

A documentação de segurança do GitHub também lembra que apenas a exclusão de informações confidenciais na versão mais recente do código não limpará a cópia do histórico do Git.

Ainda pode haver envios locais que ainda não foram enviados no Git. O registro de envio contém o endereço de e-mail do autor, e o grande cache de arquivos pode reter materiais que já foram usados ​​no projeto anteriormente. ZCode precisa explicar por que precisa carregar esse conteúdo para ajudar os usuários a concluir a tarefa em questão.

Os exemplos acima não podem provar que a chave real vazou.

Para quem abriu o warehouse interno no ZCode, precisa saber quais versões e períodos de tempo foram afetados para poder voltar e verificar o conteúdo histórico que pode ter sido empacotado.

A política de privacidade da ZCode afirma que, para fornecer geração de conteúdo e operações assistidas por IA, serão coletados arquivos e códigos “enviados e especificados” pelos usuários nas conversas. No entanto, quando o software empacota o histórico do Git em segundo plano, a descrição do produto existente não deixa claro se o usuário sabe e concorda.

Mesmo que o arquivo esteja criptografado, os usuários têm motivos para perguntar: antes de enviar, explique claramente o que será enviado e deixe-os decidir se concordam.

Quanto aos arquivos serem usados ​​para treinar modelos, a mesma política afirma que o "Plano de otimização" está desativado por padrão e a entrada, o conteúdo gerado ou os dados de uso do produto não serão usados ​​para treinamento e otimização de produtos e modelos até que os usuários participem ativamente.

Os materiais públicos existentes não mostram que esses dados do warehouse entraram no processo de treinamento.

Mas para as empresas, apenas prometer não usar código para treinamento não é suficiente para responder a esse desafio. O armazenamento, acesso e destruição de arquivos após seu upload também exigem registros de processamento que podem ser verificados pelos usuários.

3. Fechar a indexação. Você pode desativar o upload?

Se o usuário não deseja que esses instantâneos de fundo saiam do computador, não basta saber que o "Plano de Otimização" está desativado por padrão. Eles também precisam de uma opção para controlar o upload.

De acordo com a introdução do ZCode, o comportamento de upload está relacionado ao "índice base do código". Este recurso é usado para gerar índices de warehouse localmente e oferece suporte à recuperação de pontos de verificação de sessão, reversão de versão histórica e Repo Wiki. Os dois primeiros itens auxiliam os usuários a restaurar o status do projeto, enquanto a Warehouse Encyclopedia é responsável por analisar a estrutura do projeto e gerar a documentação.

A julgar pelo processo de restauração do desenvolvedor, o ZCode originalmente tinha uma função de upload de armazém. A descrição de 18 de setembro atribuiu o problema a funções relacionadas que foram ativadas por padrão no estágio inicial, mas não detalhou se essa correção ajustava as condições de upload, o intervalo de coleta de arquivos ou a lógica de controle das opções de configuração. Não está claro quais dados são necessários para diversas funções: quais arquivos são usados ​​apenas para recuperação local e quais são transferidos para a nuvem. Por que o histórico do Git, o cache de arquivos grandes e a configuração global são refletidos pelos usuários?

ferstar disse que na versão 3.12.3 que ele verificou, após desligar "Optimize Experience" e "Warehouse Snapshot Index", o background ainda será empacotado e tentará fazer upload.

O remetente da edição nº 707 disse que após fechar o índice de snapshots do warehouse, ele encontrou um registro do servidor aceitando snapshots em sua máquina local. É necessário verificar se o upload ocorre antes ou depois do botão de desligamento.

Se esta opção controla a indexação local ou o upload na nuvem, requer explicação do ZCode.

Os desenvolvedores da comunidade também impuseram restrições ao cliente. O projeto zcode-webui adiciona quatro camadas de proteção durante o tempo de execução oficial, que respectivamente interceptam o aplicativo de credenciais de snapshot, carregam, leem e salvam localmente. Essas interceptações são para evitar novos uploads. O que foi transmitido no passado e o que o servidor fez ainda precisam ser investigados separadamente.

Quando a ferstar revisou a versão 3.14.0, ela disse que o código e os componentes de segundo plano responsáveis ​​pelo upload foram removidos e os pontos de verificação locais ainda foram mantidos; a interface para solicitar credenciais de upload também retornou 404.

Ele verificou a versão e a interface acima. Se outras plataformas também foram reparadas, se clientes antigos podem continuar a fazer upload e quando o reparo no servidor entrará em vigor ainda requer explicação oficial.

4. O que mais precisa ser investigado após o reparo

Após o lançamento da versão de reparo, o que os usuários mais desejam confirmar é se seus projetos foram transferidos. A política de privacidade da ZCode fornece um endereço de e-mail para consulta e exclusão de informações pessoais. Esperamos que a empresa esclareça se este canal pode lidar com dúvidas sobre esse upload anormal, para que os usuários possam descobrir os itens afetados específicos. Quais versões e períodos de tempo são afetados também devem ser indicados.

A empresa declarou que os dados enviados serão destruídos imediatamente após a geração do Wiki. Mas o que acontece com o arquivo se a compilação falhar, for cancelada ou expirar? Se os arquivos carregados foram descriptografados, quem os acessou e se a exclusão cobrirá os instantâneos e backups da nuvem precisam de mais explicações. Espera-se que a empresa possa fornecer registros de processamento específicos aos usuários afetados, para que possam verificar se seus arquivos foram excluídos conforme prometido.

Em 20 de setembro, cerca de dois dias após o ZCode ter prometido ser de código aberto, o código-fonte do cliente ainda não havia sido encontrado no armazém público do Z.ai.

Quando o código-fonte for aberto no futuro, o mundo exterior precisará ver a versão em questão ou os registros de modificação correspondentes.

Apenas olhando para o código reparado, não fica claro por que o upload foi acionado antes e quais arquivos foram coletados.

ZCode também promete introduzir análises de terceiros. A parte da revisão, o âmbito e o calendário necessitam de mais explicações.

Esperamos que esta revisão verifique o código do cliente e o registro do servidor. Registros relevantes de processamento, acesso e exclusão podem ser entregues ao revisor para inspeção sem divulgação do código do usuário; os resultados da revisão devem ser notificados aos usuários afetados.

Tags relacionadas

Artigos relacionados

Comentários

0/500
Captcha (click to refresh)
Sem comentários