尧图网站建设 
普通开发者现在该做什么在等待官方开源和第三方审查结果之前普通开发者可以先做三件事确认自己的机器是否受影响并决定要不要采取防护措施。检查本机缓存目录查看~/.zcode/v2/checkpoints目录的大小与内容。如果发现存在体积异常大的加密归档文件说明工作区快照可能已被打包上传可结合目录内状态文件确认上传次数与最近一次上传时间。监控网络连接用lsof -p ZCode进程PID | grep TCP或 Wireshark 抓包观察 ZCode 进程是否有到阿里云 OSS 域名的异常流量。若在未主动触发任何操作时仍出现持续上传说明后台上传行为仍在发生。锁定 checkpoints 目录如有顾虑可在文件系统层面锁定该目录macOS 用chflags uchgLinux 用chattr i。需要说明的是这样做的代价是检查点回滚功能会失效请根据自身对回滚功能的依赖程度权衡后再操作。智谱 ZCode 默认开启的「代码库索引」功能会在后台将整个工作区打包加密上传至阿里云 OSS其中 .git 目录占载荷的 86.6%。用户无法解密自己的数据设置开关也拦不住上传。官方已致歉并承诺开源代码库、接受第三方审查。事件时间线9 月 18 日开发者 ferstar 发布逆向分析智谱Z.ai旗下的 AI 编程桌面应用 ZCode只要用户处于登录状态就会在后台把整个工作区打包、加密直接上传到阿里云对象存储内容包括完整的 Git 提交历史、大文件缓存和本地操作痕迹。帖子 13 小时内浏览量超过 27 万截至 9 月 19 日数据仍在变化。当晚 17 时 44 分ZCode 在用户群发出致歉声明承认问题出在默认开启的「代码库索引」功能称已修复并承诺近期开源代码库、接受第三方审查。道歉来得很快。但把官方说法和研究者的证据放在一起有几件事仍然对不上。起点是一个 313MB 的加密文件ferstar 最初只是清理磁盘发现 ZCode 的数据目录占了 700MB 以上。在 checkpoints 目录里他找到一个 313MB 的加密归档旁边的状态文件显示它来自一个正在开发中的商业项目原始工作区 345MB已累计 564 次上传失败等待下一次重试。他拆开客户端的 app.asar还原了上传流程客户端向 ZCode 服务器请求上传凭证服务器下发签名和一把 RSA 公钥本地把工作区打成 tar.gz用 AES-256-CTR 加密后绕过应用服务器直接上传到阿里云 OSS。八成六是 Git 历史快照的文件清单以明文存在本地。在一个包含 42,411 个文件的快照里.git 目录占整个载荷的 86.6%具体构成如下内容类型占比说明大文件缓存56.8%Git LFS 等大文件对象完整提交历史对象29.6%自仓库创建以来的全部提交源代码与文档13.4%真正的项目文件也就是说云端拿到的是仓库自第一天起的完整谱系而不只是你正在编辑的文件后续提交里已删除的 API 密钥、暴露未发布计划的本地分支名、.git/config 里的内部主机名和仓库路径。用户解不开自己的数据也关不掉上传两个细节让事件从「可疑」升级为「丑闻」。其一加密采用信封加密RSA 公钥由服务器在协商时下发私钥只存在云端。ferstar 用本地所有私钥尝试解封全部失败。硬盘上那 313MB 密文用户自己打不开客户端也打不开。如果目的是给用户做备份回滚密钥理应留在本地一把只有服务器能用的钥匙服务对象很难说是用户。其二设置里的两个开关都拦不住上传。「优化体验」只控制数据是否授权用于训练「仓库快照索引」只控制云端是否建立索引。据研究者对代码的交叉验证捕获和上传组件在启动时无条件实例化唯一的条件是登录令牌有效。手动删除本地加密包也没用半小时内客户端重新打了一个新包重试计数从 564 跳到 565。而翻遍 ZCode 的隐私政策、FAQ 和更新日志只有「收集对话期间提交的文本、文件和代码」这一常规表述没有任何一处提到会打包上传整个工作区和 Git 历史。官方说法与证据之间的落差ZCode 的致歉声明把问题归因于「代码库索引」功能该功能用于在本地生成仓库索引支撑会话断点恢复、历史版本回退和 Repo Wiki代码仓库知识库其中 Repo Wiki 在云端生成页面时可能触发仓库数据上传上传的数据随后立即销毁、不会保存。功能上线初期默认开启波及部分用户。官方同时宣布问题已修复近期开源代码库邀请第三方审查并向全体用户额外补偿一次周额度重置。对照研究者的发现有三处值得追问。第一触发机制的描述不一致。官方说上传由 Repo Wiki 生成触发而研究者从代码和日志里看到的捕获点是「每次提示词之前」以及任务完成时单个活跃会话产生了 62 次捕获事件。两种说法如何统一声明没有解释。第二「立即销毁」无法验证。销毁发生在云端外界没有手段确认声明也未提供技术细节。真正能自证清白的是开源代码库和第三方审查的结果而这两项目前都还是承诺。第三为什么生成 Wiki 页面需要完整 Git 历史。生成知识库页面理论上只需要当前代码结构快照里却是 86.6% 的版本历史。声明确认了上传事实但没有解释范围为什么是全量。这件事的边界在哪里AI 编程工具在推理时上传代码上下文是常态用户对此有基本预期。这次事件的特殊之处在于范围整个仓库加全部历史和方式未经同意、加密到只有厂商能读、开关无效、隐私政策未披露。类似的事两个月前刚发生过一次7 月xAI 的编码工具 Grok Build 被发现默认上传完整 Git 提交历史到 Google Cloud。区别在意图Grok 的上传是公开、未加密的写在自己的日志里事后补了开关ZCode 这次加密方向是防着自己的用户。「防着自己的用户」是研究者的判断是否成立要看开源和审查给出的答案。把两起事件放在一起对比差异会更直观对比维度ZCodeGrok Build上传范围整个工作区打包加密上传其中 .git 目录占载荷的 86.6%包含完整 Git 提交历史、大文件缓存和本地操作痕迹默认上传完整 Git 提交历史到 Google Cloud是否加密是采用信封加密AES-256-CTR 加密载荷RSA 公钥由服务器下发私钥仅存云端用户自己无法解密否上传是公开、未加密的直接写在日志里是否默认开启是功能上线初期默认开启波及部分用户是被发现时即为默认行为用户是否知情不知情隐私政策、FAQ 和更新日志均未提及会打包上传整个工作区和 Git 历史不知情上传行为写在自己的日志里但用户并未被明确告知开关是否有效无效「优化体验」和「仓库快照索引」两个开关都拦不住上传捕获和上传组件在启动时无条件实例化事后补了开关但被发现时用户无法关闭隐私政策披露情况未披露仅有「收集对话期间提交的文本、文件和代码」这一常规表述未披露上传行为仅记录在日志中事后补救措施致歉声明、修复问题、承诺近期开源代码库、邀请第三方审查、补偿一次周额度重置事后补了开关允许用户关闭上传两起事件最本质的区别在意图Grok 的上传是公开、未加密的事后补了开关ZCode 这次加密方向是防着自己的用户。对普通开发者两件事现在就能做一是检查本机的 ~/.zcode/v2/checkpoints 目录如有顾虑可在文件系统层面锁定该目录macOS 用 chflags uchgLinux 用 chattr i代价是检查点回滚功能失效二是默认模型之外的一切都在信任范围内模型开源不等于工具开源权重开放不等于桌面应用不往外传数据。智谱承诺的开源与第三方审查是这件事后续最值得盯的两个节点。附录上传流程代码示意以下代码示意了研究者还原的加密上传流程伪代码仅用于说明数据流向import tarfile from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def upload_workspace(workspace_path, server_public_key): # 1. 请求上传凭证 creds request_upload_credentials() # 2. 打包工作区 with tarfile.open(workspace.tar.gz, w:gz) as tar: tar.add(workspace_path, recursiveTrue) # 3. 用服务器下发的 RSA 公钥做信封加密 aes_key generate_aes_key() encrypted_aes_key server_public_key.encrypt(aes_key) # 4. AES-256-CTR 加密压缩包 cipher Cipher(algorithms.AES(aes_key), modes.CTR(iv)) encrypted_data cipher.encryptor().update(open(workspace.tar.gz, rb).read()) # 5. 绕过应用服务器直传阿里云 OSS upload_to_oss(creds.oss_url, encrypted_data, encrypted_aes_key) ZCode 事件全解析：默认开启的代码库索引，如何把整个工作区加密上传到云端
普通开发者现在该做什么在等待官方开源和第三方审查结果之前普通开发者可以先做三件事确认自己的机器是否受影响并决定要不要采取防护措施。检查本机缓存目录查看~/.zcode/v2/checkpoints目录的大小与内容。如果发现存在体积异常大的加密归档文件说明工作区快照可能已被打包上传可结合目录内状态文件确认上传次数与最近一次上传时间。监控网络连接用lsof -p ZCode进程PID | grep TCP或 Wireshark 抓包观察 ZCode 进程是否有到阿里云 OSS 域名的异常流量。若在未主动触发任何操作时仍出现持续上传说明后台上传行为仍在发生。锁定 checkpoints 目录如有顾虑可在文件系统层面锁定该目录macOS 用chflags uchgLinux 用chattr i。需要说明的是这样做的代价是检查点回滚功能会失效请根据自身对回滚功能的依赖程度权衡后再操作。智谱 ZCode 默认开启的「代码库索引」功能会在后台将整个工作区打包加密上传至阿里云 OSS其中 .git 目录占载荷的 86.6%。用户无法解密自己的数据设置开关也拦不住上传。官方已致歉并承诺开源代码库、接受第三方审查。事件时间线9 月 18 日开发者 ferstar 发布逆向分析智谱Z.ai旗下的 AI 编程桌面应用 ZCode只要用户处于登录状态就会在后台把整个工作区打包、加密直接上传到阿里云对象存储内容包括完整的 Git 提交历史、大文件缓存和本地操作痕迹。帖子 13 小时内浏览量超过 27 万截至 9 月 19 日数据仍在变化。当晚 17 时 44 分ZCode 在用户群发出致歉声明承认问题出在默认开启的「代码库索引」功能称已修复并承诺近期开源代码库、接受第三方审查。道歉来得很快。但把官方说法和研究者的证据放在一起有几件事仍然对不上。起点是一个 313MB 的加密文件ferstar 最初只是清理磁盘发现 ZCode 的数据目录占了 700MB 以上。在 checkpoints 目录里他找到一个 313MB 的加密归档旁边的状态文件显示它来自一个正在开发中的商业项目原始工作区 345MB已累计 564 次上传失败等待下一次重试。他拆开客户端的 app.asar还原了上传流程客户端向 ZCode 服务器请求上传凭证服务器下发签名和一把 RSA 公钥本地把工作区打成 tar.gz用 AES-256-CTR 加密后绕过应用服务器直接上传到阿里云 OSS。八成六是 Git 历史快照的文件清单以明文存在本地。在一个包含 42,411 个文件的快照里.git 目录占整个载荷的 86.6%具体构成如下内容类型占比说明大文件缓存56.8%Git LFS 等大文件对象完整提交历史对象29.6%自仓库创建以来的全部提交源代码与文档13.4%真正的项目文件也就是说云端拿到的是仓库自第一天起的完整谱系而不只是你正在编辑的文件后续提交里已删除的 API 密钥、暴露未发布计划的本地分支名、.git/config 里的内部主机名和仓库路径。用户解不开自己的数据也关不掉上传两个细节让事件从「可疑」升级为「丑闻」。其一加密采用信封加密RSA 公钥由服务器在协商时下发私钥只存在云端。ferstar 用本地所有私钥尝试解封全部失败。硬盘上那 313MB 密文用户自己打不开客户端也打不开。如果目的是给用户做备份回滚密钥理应留在本地一把只有服务器能用的钥匙服务对象很难说是用户。其二设置里的两个开关都拦不住上传。「优化体验」只控制数据是否授权用于训练「仓库快照索引」只控制云端是否建立索引。据研究者对代码的交叉验证捕获和上传组件在启动时无条件实例化唯一的条件是登录令牌有效。手动删除本地加密包也没用半小时内客户端重新打了一个新包重试计数从 564 跳到 565。而翻遍 ZCode 的隐私政策、FAQ 和更新日志只有「收集对话期间提交的文本、文件和代码」这一常规表述没有任何一处提到会打包上传整个工作区和 Git 历史。官方说法与证据之间的落差ZCode 的致歉声明把问题归因于「代码库索引」功能该功能用于在本地生成仓库索引支撑会话断点恢复、历史版本回退和 Repo Wiki代码仓库知识库其中 Repo Wiki 在云端生成页面时可能触发仓库数据上传上传的数据随后立即销毁、不会保存。功能上线初期默认开启波及部分用户。官方同时宣布问题已修复近期开源代码库邀请第三方审查并向全体用户额外补偿一次周额度重置。对照研究者的发现有三处值得追问。第一触发机制的描述不一致。官方说上传由 Repo Wiki 生成触发而研究者从代码和日志里看到的捕获点是「每次提示词之前」以及任务完成时单个活跃会话产生了 62 次捕获事件。两种说法如何统一声明没有解释。第二「立即销毁」无法验证。销毁发生在云端外界没有手段确认声明也未提供技术细节。真正能自证清白的是开源代码库和第三方审查的结果而这两项目前都还是承诺。第三为什么生成 Wiki 页面需要完整 Git 历史。生成知识库页面理论上只需要当前代码结构快照里却是 86.6% 的版本历史。声明确认了上传事实但没有解释范围为什么是全量。这件事的边界在哪里AI 编程工具在推理时上传代码上下文是常态用户对此有基本预期。这次事件的特殊之处在于范围整个仓库加全部历史和方式未经同意、加密到只有厂商能读、开关无效、隐私政策未披露。类似的事两个月前刚发生过一次7 月xAI 的编码工具 Grok Build 被发现默认上传完整 Git 提交历史到 Google Cloud。区别在意图Grok 的上传是公开、未加密的写在自己的日志里事后补了开关ZCode 这次加密方向是防着自己的用户。「防着自己的用户」是研究者的判断是否成立要看开源和审查给出的答案。把两起事件放在一起对比差异会更直观对比维度ZCodeGrok Build上传范围整个工作区打包加密上传其中 .git 目录占载荷的 86.6%包含完整 Git 提交历史、大文件缓存和本地操作痕迹默认上传完整 Git 提交历史到 Google Cloud是否加密是采用信封加密AES-256-CTR 加密载荷RSA 公钥由服务器下发私钥仅存云端用户自己无法解密否上传是公开、未加密的直接写在日志里是否默认开启是功能上线初期默认开启波及部分用户是被发现时即为默认行为用户是否知情不知情隐私政策、FAQ 和更新日志均未提及会打包上传整个工作区和 Git 历史不知情上传行为写在自己的日志里但用户并未被明确告知开关是否有效无效「优化体验」和「仓库快照索引」两个开关都拦不住上传捕获和上传组件在启动时无条件实例化事后补了开关但被发现时用户无法关闭隐私政策披露情况未披露仅有「收集对话期间提交的文本、文件和代码」这一常规表述未披露上传行为仅记录在日志中事后补救措施致歉声明、修复问题、承诺近期开源代码库、邀请第三方审查、补偿一次周额度重置事后补了开关允许用户关闭上传两起事件最本质的区别在意图Grok 的上传是公开、未加密的事后补了开关ZCode 这次加密方向是防着自己的用户。对普通开发者两件事现在就能做一是检查本机的 ~/.zcode/v2/checkpoints 目录如有顾虑可在文件系统层面锁定该目录macOS 用 chflags uchgLinux 用 chattr i代价是检查点回滚功能失效二是默认模型之外的一切都在信任范围内模型开源不等于工具开源权重开放不等于桌面应用不往外传数据。智谱承诺的开源与第三方审查是这件事后续最值得盯的两个节点。附录上传流程代码示意以下代码示意了研究者还原的加密上传流程伪代码仅用于说明数据流向import tarfile from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def upload_workspace(workspace_path, server_public_key): # 1. 请求上传凭证 creds request_upload_credentials() # 2. 打包工作区 with tarfile.open(workspace.tar.gz, w:gz) as tar: tar.add(workspace_path, recursiveTrue) # 3. 用服务器下发的 RSA 公钥做信封加密 aes_key generate_aes_key() encrypted_aes_key server_public_key.encrypt(aes_key) # 4. AES-256-CTR 加密压缩包 cipher Cipher(algorithms.AES(aes_key), modes.CTR(iv)) encrypted_data cipher.encryptor().update(open(workspace.tar.gz, rb).read()) # 5. 绕过应用服务器直传阿里云 OSS upload_to_oss(creds.oss_url, encrypted_data, encrypted_aes_key)