요약:
Zhipu의 AI 프로그래밍 도구인 ZCode는 백그라운드 패키징 및 사용자 프로젝트 업로드에 대해 질문을 받았습니다.
개발자들은 현재 코드뿐만 아니라 이전 수정 사항을 저장한 Git 기록도 패키징되어 있음을 발견했습니다. 9월 18일, 개발자 ferstar는 자신의 문제 해결 결과를 공개했습니다. ZCode는 이 시스템에서 프로젝트 사본을 생성하고 반복적으로 업로드를 시도했습니다. 이후 다른 사용자들도 리뷰 기록을 제공했습니다. 일부는 프로젝트 사본이 서버에서 승인되었음을 발견했으며 일부는 웨어하우스 인덱스 스위치로 인해 업로드가 차단될 수 있는지 의문을 제기했습니다. 따라서 사용자는 다음과 같이 질문했습니다. 소프트웨어가 이 콘텐츠를 수집하는 이유와 콘텐츠 업로드를 방지하는 방법은 무엇입니까?
ZCode는 이날 사과하며 초기에 기본적으로 켜져 있던 '코드 베이스 인덱스' 관련 기능에 문제가 있었다고 밝혔습니다. 회사 측은 레포위키가 클라우드에서 창고백과사전을 생성할 때 데이터 업로드가 발생할 수 있으며, 해당 데이터는 생성 후 즉시 파기된다고 밝혔습니다. 또한 클라이언트를 오픈소스화하고 제3자 리뷰를 도입하겠다고 약속했습니다.
9월 19일 ZCode는 3.14.0을 출시했으며 업데이트 로그에는 "웨어하우스 백과사전의 비정상적인 업로드 문제를 수정했습니다."라고 명시되어 있습니다. 페르스타 역시 새 버전에서는 해당 업로드 코드가 삭제됐다며 리뷰 결과를 보완했다.
오픈소스로 공개되면 소프트웨어가 왜 업로드됐는지, 이번에는 어떤 변화가 있었는지 외부인도 확인할 수 있다. 다만, 회사는 서버가 이전에 어떤 파일을 수신했는지, 해당 파일이 약속대로 삭제되었는지에 대한 수신 및 처리 기록을 제공해야 합니다.
제3자 리뷰가 고객만을 검토하는 경우 이 일련의 과거 데이터에 대한 사용자 질문에 답변할 수 없습니다.
1. 디스크를 청소하고 프로젝트 사본을 찾았습니다
ferstar는 처음에 업로드 동작을 확인하지 않았습니다. 그는 컴퓨터 디스크를 정리하던 중 ZCode의 데이터 디렉터리가 많은 공간을 차지하고 있음을 발견했고, 자세히 살펴보니 313MB의 암호화된 파일을 발견했습니다. 이는 프로젝트용 소프트웨어에 의해 생성된 스냅샷으로, 프로젝트 파일 배치를 복사본으로 패키징하는 것과 같습니다.
스냅샷과 함께 저장된 목록에는 42411개의 파일이 나열되어 있습니다. 파일 볼륨으로 계산하면 그 중 약 86.6%가 Git 기록 개체, 작업 로그 및 LFS 대용량 파일 캐시를 포함하여 버전 기록을 저장하는 .git 디렉터리에서 나옵니다.
이 문서는 어디로 보내지나요? ferstar는 클라이언트 코드를 계속 확인하고 업로드 프로세스를 찾았습니다. 소프트웨어는 먼저 ZCode 서버에 업로드 인증서를 신청한 다음 파일을 패키지하고 암호화하고 해당 파일을 Alibaba Cloud의 OSS 클라우드 스토리지 서비스로 보냈으며 마지막으로 클라우드는 ZCode 서버에 등록하고 결과를 받도록 알렸습니다.
그러나 313MB 파일은 564번의 업로드 시도가 있었지만 매번 실패했고 로컬 머신에 남아 재시도를 기다리고 있었습니다.
Ferstar는 9월 19일 업데이트에서 이를 구체적으로 설명하고 다음과 같이 덧붙였습니다. 그의 또 다른 소규모 공용 창고 스냅샷의 상태는 서버가 이를 수락한 것으로 표시됩니다.개발자 Vonng는 ZCode 3.12.3의 macOS 버전에서 이를 검토했습니다. 그는 .git이 포함되지 않은 일반 작업공간의 스냅샷을 발견했고, 기록에 따르면 서버에서 이를 승인한 것으로 나타났습니다. 다른 두 스냅샷에서는 .git이 전체 파일 볼륨의 93.9%와 98.5%를 차지했습니다. 클라이언트는 업로드 자격 증명을 얻었지만 공개 기록에서는 업로드를 완료했는지 확인할 수 없었습니다.
ZCode는 GitHub의 피드백 영역에서도 관련 보고서를 받았습니다. 문제 #707의 제출자는 서버에서 허용하는 스냅샷 목록을 찾았으며 여기에는 2,000개 이상의 .git 경로가 포함되어 있다고 말했습니다. 또한 스냅샷에는 AI 도구에 대해 사용자가 설정한 연결 정보, 자동 실행 스크립트, 명령 파일 등 글로벌 구성이 함께 제공될 것이라고 밝혔습니다. 그의 판단은 현지 기록에 근거하며 확인할 서버 측 감사 결과는 없습니다.
2. 삭제된 코드도 따라갈 수 있습니다
이 목록에 반복적으로 나타나는 Git 기록이 사용자를 걱정하게 합니다.
Git을 사용하면 개발자가 이전 버전의 코드를 검색할 수 있습니다. 이는 오늘 삭제된 콘텐츠가 웨어하우스에서 사라지지 않을 수도 있음을 의미합니다.
실수로 제출된 키, 구성 파일 또는 내부 주소는 기록 개체에 보관될 수 있습니다.
GitHub의 보안 문서에는 최신 버전의 코드에서 중요한 정보를 삭제하는 것만으로는 Git 기록의 복사본이 지워지지 않는다는 점을 상기시켜 줍니다.
아직 Git에 푸시되지 않은 로컬 제출물이 있을 수 있습니다. 제출 기록에는 작성자의 이메일 주소가 포함되며 대용량 파일 캐시에는 이전에 프로젝트에 사용된 자료가 보관될 수 있습니다. ZCode는 사용자가 당면한 작업을 완료할 수 있도록 이 콘텐츠를 업로드해야 하는 이유를 설명해야 합니다.
위 샘플로는 실제 키가 유출되었음을 증명할 수 없습니다.
ZCode에서 내부 창고를 연 사람들은 어떤 버전과 기간이 영향을 받았는지 알아야 돌아가서 패키징되었을 수 있는 기록 콘텐츠를 확인할 수 있습니다.ZCode의 개인정보 보호정책에는 콘텐츠 생성 및 AI 지원 작업을 제공하기 위해 대화에서 사용자가 "제출하고 지정한" 파일 및 코드가 수집된다고 명시되어 있습니다. 그러나 소프트웨어가 백그라운드에서 Git 기록을 패키징하는 경우 기존 제품 설명에서는 사용자가 알고 동의하는지 여부가 명확하지 않습니다.
파일이 암호화되어 있더라도 사용자가 질문할 이유가 있습니다. 업로드하기 전에 업로드할 내용을 명확하게 설명한 다음 동의할지 여부를 결정하도록 하세요.
모델 교육에 파일이 사용되는지 여부와 관련하여 동일한 정책에 따르면 '최적화 계획'은 기본적으로 꺼져 있으며 입력, 생성된 콘텐츠 또는 제품 사용 데이터는 사용자가 적극적으로 참여할 때까지 제품 및 모델 교육 및 최적화에 사용되지 않습니다.
기존 공개 자료에는 이러한 창고 데이터가 교육 과정에 입력되었음을 표시하지 않습니다.
그러나 기업의 경우 단순히 교육에 코드를 사용하지 않겠다고 약속하는 것만으로는 이러한 문제에 대응하기에 충분하지 않습니다. 업로드된 파일의 저장, 접근 및 파기에도 사용자가 확인할 수 있는 처리 기록이 필요합니다.
3. 색인 생성을 닫습니다. 업로드를 끌 수 있나요
사용자가 이러한 배경 스냅샷이 컴퓨터를 떠나는 것을 원하지 않는 경우 "최적화 계획"이 기본적으로 꺼져 있다는 사실을 아는 것만으로는 충분하지 않습니다. 또한 업로드를 제어하는 옵션도 필요합니다.
ZCode 소개에 따르면 업로드 동작은 "코드 베이스 인덱스"와 관련이 있습니다. 이 기능은 로컬에서 웨어하우스 인덱스를 생성하는 데 사용되며 세션 체크포인트 복구, 기록 버전 롤백 및 Repo Wiki를 지원합니다. 처음 두 항목은 사용자가 프로젝트 상태를 복원하는 데 도움이 되는 반면 Warehouse Encyclopedia는 프로젝트 구조 분석 및 문서 생성을 담당합니다.
개발자 복원 과정으로 볼 때 ZCode에는 원래 웨어하우스 업로드 기능이 있었습니다. 9월 18일자 설명에서는 초기에 기본으로 켜져 있던 관련 기능에 문제가 있다고 밝혔으나, 이번 수정으로 업로드 조건이나 파일 수집 범위, 설정 스위치의 제어 로직이 조정되었는지에 대해서는 자세히 설명하지 않았습니다. 여러 기능에 어떤 데이터가 필요한지 명확하지 않습니다. 어떤 파일이 로컬 복구에만 사용되는지, 어떤 파일이 클라우드로 전송되는지는 확실하지 않습니다. Git 히스토리, 대용량 파일 캐시, 사용자가 반영하는 글로벌 구성이 왜 포함되나요?
ferstar는 자신이 확인한 3.12.3 버전에서 "경험 최적화"와 "창고 스냅샷 색인"을 끈 후에도 배경이 여전히 패키지되어 업로드를 시도한다고 말했습니다.
문제 #707의 제출자는 창고 스냅샷 색인을 닫은 후 서버가 자신의 로컬 컴퓨터에서 스냅샷을 수락하는 기록을 발견했다고 말했습니다. 스위치를 끄기 전이나 후에 업로드가 발생하는지 확인해야 합니다.
이 옵션이 로컬 색인 생성을 제어하는지 아니면 클라우드 업로드를 제어하는지에 대해서는 ZCode의 설명이 필요합니다.
커뮤니티 개발자들도 클라이언트에 제한을 두었습니다. 프로젝트 zcode-webui는 공식 런타임 동안 스냅샷 자격 증명 적용을 각각 가로채고 로컬로 업로드하고 읽고 저장하는 4개의 보호 계층을 추가합니다. 이러한 차단은 추가 업로드를 방지하기 위한 것입니다. 과거에 전송된 내용과 서버에서 수행한 내용은 아직 별도로 조사해야 합니다.
ferstar가 버전 3.14.0을 검토했을 때 업로드를 담당하는 코드와 배경 구성 요소가 제거되었으며 로컬 체크포인트가 여전히 유지되었다고 밝혔습니다. 업로드 자격 증명을 신청하기 위한 인터페이스도 404를 반환했습니다.
위 버전과 인터페이스를 확인했습니다. 다른 플랫폼도 복구되었는지, 기존 클라이언트는 계속 업로드할 수 있는지, 서버 복구가 언제 적용되는지는 아직 공식적인 설명이 필요합니다.
4. 수리 후 추가로 조사해야 할 사항
수리 버전이 출시된 후 사용자들이 가장 확인하고 싶은 것은 프로젝트가 전송되었는지 여부입니다. ZCode의 개인정보 보호정책은 개인정보 조회 및 삭제를 위한 이메일 주소를 제공하고 있습니다. 당사는 이번 비정상적인 업로드에 대한 문의를 본 채널에서 처리할 수 있는지 여부를 명확히 밝혀, 이용자들이 구체적인 영향을 받는 항목을 확인할 수 있기를 바랍니다. 영향을 받는 버전과 기간도 명시되어야 합니다.
회사에서는 업로드된 데이터는 위키 생성 후 즉시 파기된다고 밝혔습니다. 하지만 빌드가 실패하거나 취소되거나 시간 초과되면 파일은 어떻게 되나요? 업로드된 파일의 암호가 해독되었는지 여부, 해당 파일에 액세스한 사람, 삭제 범위에 클라우드 스냅샷 및 백업이 포함되는지 여부에 대한 추가 설명이 필요합니다. 회사는 피해를 입은 사용자에게 구체적인 처리 기록을 제공하여 사용자가 약속대로 파일이 삭제되었는지 확인할 수 있기를 바랍니다.
ZCode가 오픈 소스를 약속한 지 약 이틀 후인 9월 20일 현재, Z.ai의 공개 창고에서는 클라이언트 소스 코드가 아직 발견되지 않았습니다.
향후 오픈 소스로 공개되면 외부 세계에서 문제의 버전이나 해당 수정 기록을 볼 수 있어야 합니다.
수정된 코드만 보면 이전에 왜 업로드가 실행되었는지, 어떤 파일이 수집되었는지 명확하지 않습니다.
ZCode에서는 제3자 리뷰도 도입할 것을 약속합니다. 심사 대상, 범위, 일정 등에 대해서는 추가 설명이 필요합니다.
이 검토를 통해 클라이언트 코드와 서버 로깅을 모두 확인할 수 있기를 바랍니다. 사용자 코드를 공개하지 않고 관련 처리, 접근 및 삭제 기록을 검토자에게 넘겨 검사할 수 있습니다. 검토 결과는 영향을 받은 사용자에게 통보되어야 합니다.
댓글