सार:
ZCode, Zhipu का AI प्रोग्रामिंग टूल, इसकी पृष्ठभूमि पैकेजिंग और उपयोगकर्ता परियोजनाओं को अपलोड करने के लिए पूछताछ की गई है।
डेवलपर्स ने पाया कि न केवल वर्तमान कोड पैक किया गया था, बल्कि Git इतिहास भी था जिसने पिछले संशोधनों को सहेजा था। 18 सितंबर को, डेवलपर फ़र्स्टार ने अपने समस्या निवारण परिणामों का खुलासा किया: ZCode ने इस मशीन पर प्रोजेक्ट की एक प्रति तैयार की और बार-बार इसे अपलोड करने का प्रयास किया। इसके बाद, अन्य उपयोगकर्ताओं ने भी समीक्षा रिकॉर्ड प्रदान किए। कुछ ने पाया कि प्रोजेक्ट की प्रतिलिपि सर्वर द्वारा स्वीकार कर ली गई थी, और कुछ ने सवाल किया कि क्या वेयरहाउस इंडेक्स स्विच अपलोड को रोक सकता है। उपयोगकर्ताओं ने इसलिए पूछा: सॉफ़्टवेयर इस सामग्री को क्यों एकत्र करता है, और इसे अपलोड होने से कैसे रोका जाए?
ZCode ने उस दिन माफ़ी मांगी और समस्या के लिए "कोड बेस इंडेक्स" संबंधित फ़ंक्शंस को जिम्मेदार ठहराया जो शुरुआती दिनों में डिफ़ॉल्ट रूप से चालू थे। कंपनी ने कहा कि रेपो विकी क्लाउड में वेयरहाउस इनसाइक्लोपीडिया बनाते समय डेटा अपलोड को ट्रिगर कर सकता है, और प्रासंगिक डेटा पीढ़ी के तुरंत बाद नष्ट हो जाएगा। इसने क्लाइंट के लिए स्रोत खोलने और तृतीय-पक्ष समीक्षा शुरू करने का भी वादा किया।
19 सितंबर को, ZCode ने 3.14.0 जारी किया, और अपडेट लॉग में कहा गया: "वेयरहाउस इनसाइक्लोपीडिया के असामान्य अपलोड की समस्या को ठीक कर दिया गया।" फ़र्स्टार ने समीक्षा परिणामों को पूरक करते हुए कहा कि नए संस्करण में प्रासंगिक अपलोड कोड हटा दिया गया है।
ओपन सोर्स होने के बाद, बाहरी लोग यह जांच सकते हैं कि सॉफ़्टवेयर क्यों अपलोड किया गया था और इस बार क्या बदलाव किए गए थे। हालाँकि, कंपनी को अभी भी रसीद और प्रसंस्करण रिकॉर्ड प्रदान करने की आवश्यकता है कि सर्वर को पहले कौन सी फ़ाइलें प्राप्त हुई हैं और क्या उन्हें वादे के अनुसार हटा दिया गया है।
यदि तृतीय-पक्ष समीक्षा केवल क्लाइंट को देखती है, तो वह ऐतिहासिक डेटा के इस बैच के बारे में उपयोगकर्ताओं के सवालों का जवाब देने में सक्षम नहीं होगी।
1. डिस्क साफ़ करें और प्रोजेक्ट की एक प्रति मिली
फ़रस्टार प्रारंभ में अपलोड व्यवहार की जाँच नहीं कर रहा था। जब वह अपने कंप्यूटर डिस्क को साफ़ कर रहा था, तो उसने पाया कि ZCode की डेटा निर्देशिका ने बहुत अधिक जगह ले ली है, और नीचे खोदने के बाद, उसे एक 313MB एन्क्रिप्टेड फ़ाइल मिली। यह प्रोजेक्ट के लिए सॉफ़्टवेयर द्वारा उत्पन्न एक स्नैपशॉट है, जो प्रोजेक्ट फ़ाइलों के एक बैच को एक कॉपी में पैकेजिंग करने के बराबर है।
स्नैपशॉट के साथ सहेजी गई सूची में 42411 फ़ाइलें सूचीबद्ध हैं। फ़ाइल वॉल्यूम द्वारा गणना की गई, उनमें से लगभग 86.6% .git निर्देशिका से आते हैं जो Git ऐतिहासिक ऑब्जेक्ट, ऑपरेशन लॉग और LFS बड़ी फ़ाइल कैश सहित संस्करण रिकॉर्ड सहेजता है।
ये दस्तावेज़ कहाँ भेजे जा रहे हैं? फ़र्स्टार ने क्लाइंट कोड की जांच करना जारी रखा और एक अपलोड प्रक्रिया पाई: सॉफ़्टवेयर ने पहले ZCode सर्वर पर अपलोड प्रमाणपत्र के लिए आवेदन किया, फिर फ़ाइल को पैक और एन्क्रिप्ट किया, फ़ाइल को अलीबाबा क्लाउड की OSS क्लाउड स्टोरेज सेवा में भेजा, और अंत में क्लाउड ने ZCode सर्वर को पंजीकरण करने और परिणाम प्राप्त करने के लिए सूचित किया।
हालाँकि, 313एमबी फ़ाइल को 564 बार अपलोड करने का प्रयास किया गया था, लेकिन हर बार विफल रहा और पुनः प्रयास की प्रतीक्षा में स्थानीय मशीन पर बना रहा।
फ़र्स्टार ने 19 सितंबर को अपडेट में इसे विशेष रूप से स्पष्ट किया, और यह भी जोड़ा: उनके अन्य छोटे सार्वजनिक वेयरहाउस स्नैपशॉट, स्थिति से पता चला है कि सर्वर ने इसे स्वीकार कर लिया है।डेवलपर वोनंग ने ZCode 3.12.3 के macOS संस्करण पर इसकी समीक्षा की। उन्हें सामान्य कार्यक्षेत्र का एक स्नैपशॉट मिला जिसमें .git शामिल नहीं था, और रिकॉर्ड से पता चला कि इसे सर्वर द्वारा स्वीकार कर लिया गया था; अन्य दो स्नैपशॉट में, .git कुल फ़ाइल वॉल्यूम का 93.9% और 98.5% था। क्लाइंट ने अपलोड क्रेडेंशियल प्राप्त कर लिया था, लेकिन सार्वजनिक रिकॉर्ड यह पुष्टि नहीं कर सके कि उन्होंने अपलोड पूरा कर लिया है या नहीं।
ZCode को GitHub पर फीडबैक क्षेत्र में प्रासंगिक रिपोर्ट भी प्राप्त हुई है। अंक #707 के प्रस्तुतकर्ता ने कहा कि उसे सर्वर द्वारा स्वीकृत स्नैपशॉट की एक सूची मिली, जिसमें दो हजार से अधिक .git पथ शामिल थे। उन्होंने यह भी दर्शाया कि स्नैपशॉट वैश्विक कॉन्फ़िगरेशन जैसे कनेक्शन जानकारी, स्वचालित निष्पादन स्क्रिप्ट और एआई टूल के लिए उपयोगकर्ता द्वारा निर्धारित कमांड फ़ाइलों के साथ आएगा। उनका निर्णय स्थानीय रिकॉर्ड पर आधारित है, और सत्यापित करने के लिए कोई सर्वर-साइड ऑडिट परिणाम नहीं हैं।
2. हटाए गए कोड का भी पालन किया जा सकता है
इन सूचियों में बार-बार आने वाला Git इतिहास उपयोगकर्ताओं को चिंतित करता है।
Git डेवलपर्स को कोड के पुराने संस्करण पुनः प्राप्त करने की अनुमति देता है, जिसका अर्थ यह भी है कि आज हटाई गई सामग्री गोदाम से गायब नहीं हुई होगी।
गलती से सबमिट की गई कुंजियाँ, कॉन्फ़िगरेशन फ़ाइलें या आंतरिक पते ऐतिहासिक वस्तुओं में बनाए रखे जा सकते हैं।
GitHub का सुरक्षा दस्तावेज़ यह भी याद दिलाता है कि केवल कोड के नवीनतम संस्करण में संवेदनशील जानकारी हटाने से Git इतिहास की प्रतिलिपि साफ़ नहीं होगी।
अभी भी ऐसे स्थानीय सबमिशन हो सकते हैं जिन्हें अभी तक Git में पुश नहीं किया गया है। सबमिशन रिकॉर्ड में लेखक का ईमेल पता होता है, और बड़ी फ़ाइल कैश उन सामग्रियों को बरकरार रख सकती है जो पहले प्रोजेक्ट में उपयोग की गई हैं। ZCode को यह समझाने की आवश्यकता है कि उपयोगकर्ताओं को कार्य पूरा करने में मदद करने के लिए उसे इस सामग्री को अपलोड करने की आवश्यकता क्यों है।
उपरोक्त नमूने यह साबित नहीं कर सकते कि असली कुंजी लीक हो गई है।
जिन लोगों ने ZCode में आंतरिक गोदाम खोला है, उन्हें यह जानना होगा कि कौन से संस्करण और समयावधि प्रभावित हुए हैं ताकि वे वापस जा सकें और पैक की गई ऐतिहासिक सामग्री की जांच कर सकें।ZCode की गोपनीयता नीति में कहा गया है कि सामग्री निर्माण और AI-सहायता प्राप्त संचालन प्रदान करने के लिए, बातचीत में उपयोगकर्ताओं द्वारा "प्रस्तुत और निर्दिष्ट" फ़ाइलें और कोड एकत्र किए जाएंगे। हालाँकि, जब सॉफ़्टवेयर पृष्ठभूमि में Git इतिहास को पैकेज करता है, तो मौजूदा उत्पाद विवरण यह स्पष्ट नहीं करता है कि उपयोगकर्ता जानता है और सहमत है या नहीं।
भले ही फ़ाइल एन्क्रिप्टेड हो, उपयोगकर्ताओं के पास पूछने के कारण हैं: अपलोड करने से पहले, स्पष्ट रूप से बताएं कि क्या अपलोड किया जाएगा, और फिर उन्हें निर्णय लेने दें कि सहमत होना है या नहीं।
इस बात के लिए कि क्या फ़ाइलों का उपयोग मॉडल को प्रशिक्षित करने के लिए किया जाता है, वही नीति बताती है कि "ऑप्टिमाइज़ेशन योजना" डिफ़ॉल्ट रूप से बंद है, और इनपुट, जेनरेट की गई सामग्री या उत्पाद उपयोग डेटा का उपयोग उत्पाद और मॉडल प्रशिक्षण और अनुकूलन के लिए तब तक नहीं किया जाएगा जब तक उपयोगकर्ता सक्रिय रूप से शामिल नहीं हो जाते।
मौजूदा सार्वजनिक सामग्री यह नहीं दिखाती है कि ये वेयरहाउस डेटा प्रशिक्षण प्रक्रिया में शामिल हुआ था।
लेकिन कंपनियों के लिए, केवल प्रशिक्षण के लिए कोड का उपयोग न करने का वादा करना इस चुनौती का जवाब देने के लिए पर्याप्त नहीं है। अपलोड होने के बाद फ़ाइलों के भंडारण, पहुंच और विनाश के लिए प्रसंस्करण रिकॉर्ड की भी आवश्यकता होती है जिसे उपयोगकर्ताओं द्वारा सत्यापित किया जा सकता है।
3. अनुक्रमण बंद करें, क्या आप अपलोड करना बंद कर सकते हैं
यदि उपयोगकर्ता नहीं चाहता कि ये पृष्ठभूमि स्नैपशॉट कंप्यूटर से बाहर जाएं, तो यह जानना पर्याप्त नहीं है कि "ऑप्टिमाइज़ेशन योजना" डिफ़ॉल्ट रूप से बंद है। उन्हें अपलोड को नियंत्रित करने के लिए एक विकल्प की भी आवश्यकता है।
ZCode के परिचय के अनुसार, अपलोड व्यवहार "कोड बेस इंडेक्स" से संबंधित है। इस सुविधा का उपयोग स्थानीय रूप से वेयरहाउस इंडेक्स उत्पन्न करने के लिए किया जाता है और सत्र चेकपॉइंट रिकवरी, ऐतिहासिक संस्करण रोलबैक और रेपो विकी का समर्थन करता है। पहले दो आइटम उपयोगकर्ताओं को परियोजना की स्थिति को बहाल करने में मदद करते हैं, जबकि वेयरहाउस इनसाइक्लोपीडिया परियोजना संरचना का विश्लेषण करने और दस्तावेज़ तैयार करने के लिए जिम्मेदार है।
डेवलपर बहाली प्रक्रिया से देखते हुए, ZCode में मूल रूप से एक वेयरहाउस अपलोड फ़ंक्शन था। 18 सितंबर के विवरण में समस्या के लिए संबंधित कार्यों को जिम्मेदार ठहराया गया था जो प्रारंभिक चरण में डिफ़ॉल्ट रूप से चालू थे, लेकिन इस बारे में विस्तार से नहीं बताया गया कि क्या इस फिक्स ने अपलोड शर्तों, फ़ाइल संग्रह सीमा, या सेटिंग स्विच के नियंत्रण तर्क को समायोजित किया है। यह स्पष्ट नहीं है कि कई कार्यों के लिए कौन से डेटा की आवश्यकता है: कौन सी फ़ाइलें केवल स्थानीय पुनर्प्राप्ति के लिए उपयोग की जाती हैं और कौन सी क्लाउड में स्थानांतरित की जाती हैं। उपयोगकर्ताओं द्वारा प्रतिबिंबित Git इतिहास, बड़ी फ़ाइल कैश और वैश्विक कॉन्फ़िगरेशन क्यों शामिल हैं?
फ़रस्टार ने कहा कि 3.12.3 संस्करण में उन्होंने जाँच की, "ऑप्टिमाइज़ एक्सपीरियंस" और "वेयरहाउस स्नैपशॉट इंडेक्स" को बंद करने के बाद भी, पृष्ठभूमि अभी भी पैकेज होगी और अपलोड करने का प्रयास करेगी।
अंक #707 के प्रस्तुतकर्ता ने कहा कि वेयरहाउस स्नैपशॉट इंडेक्स को बंद करने के बाद, उसे अपनी स्थानीय मशीन पर स्नैपशॉट स्वीकार करने वाले सर्वर का एक रिकॉर्ड मिला। यह जाँचने की आवश्यकता है कि अपलोड ऑफ स्विच से पहले होता है या बाद में।
क्या यह विकल्प स्थानीय अनुक्रमण या क्लाउड अपलोड को नियंत्रित करता है, इसके लिए ZCode के स्पष्टीकरण की आवश्यकता है।
सामुदायिक डेवलपर्स ने क्लाइंट पर प्रतिबंध भी लगाए हैं। प्रोजेक्ट zcode-webui आधिकारिक रनटाइम के दौरान सुरक्षा की चार परतें जोड़ता है, जो क्रमशः स्नैपशॉट क्रेडेंशियल एप्लिकेशन को रोकता है, अपलोड करता है, पढ़ता है और स्थानीय रूप से सहेजता है। ये अवरोधन आगे के अपलोड को रोकने के लिए हैं। अतीत में क्या प्रसारित किया गया है और सर्वर ने क्या किया है, इसकी अभी भी अलग से जांच करने की आवश्यकता है।
जब फ़र्स्टार ने संस्करण 3.14.0 की समीक्षा की, तो उसने कहा कि अपलोड करने के लिए जिम्मेदार कोड और पृष्ठभूमि घटकों को हटा दिया गया था, और स्थानीय चौकियों को अभी भी बरकरार रखा गया था; अपलोड क्रेडेंशियल के लिए आवेदन करने का इंटरफ़ेस भी 404 लौटा।
उन्होंने उपरोक्त संस्करण और इंटरफ़ेस की जाँच की। क्या अन्य प्लेटफ़ॉर्म की भी मरम्मत की गई है, क्या पुराने क्लाइंट अपलोड करना जारी रख सकते हैं, और सर्वर पर मरम्मत कब प्रभावी होगी, इसके लिए अभी भी आधिकारिक स्पष्टीकरण की आवश्यकता है।
4. मरम्मत के बाद और क्या जांच की जानी चाहिए
मरम्मत संस्करण लॉन्च होने के बाद, उपयोगकर्ता सबसे अधिक पुष्टि करना चाहते हैं कि क्या उनकी परियोजनाएं स्थानांतरित की गई हैं। ZCode की गोपनीयता नीति ने व्यक्तिगत जानकारी पूछने और हटाने के लिए एक ईमेल पता प्रदान किया है। हमें उम्मीद है कि कंपनी स्पष्ट करेगी कि क्या यह चैनल इस असामान्य अपलोड के बारे में पूछताछ संभाल सकता है, ताकि उपयोगकर्ता विशिष्ट प्रभावित वस्तुओं का पता लगा सकें। कौन से संस्करण और समय अवधि प्रभावित हैं, यह भी बताया जाना चाहिए।
कंपनी ने कहा है कि अपलोड किया गया डेटा विकी जेनरेट होने के तुरंत बाद नष्ट कर दिया जाएगा। लेकिन यदि बिल्ड विफल हो जाता है, रद्द हो जाता है, या समय समाप्त हो जाता है तो फ़ाइल का क्या होगा? क्या अपलोड की गई फ़ाइलें डिक्रिप्ट की गई हैं, उन्हें किसने एक्सेस किया है, और क्या विलोपन क्लाउड स्नैपशॉट और बैकअप को कवर करेगा, इसके लिए और अधिक स्पष्टीकरण की आवश्यकता है। उम्मीद है कि कंपनी प्रभावित उपयोगकर्ताओं को विशिष्ट प्रसंस्करण रिकॉर्ड प्रदान कर सकती है ताकि उपयोगकर्ता जांच सकें कि क्या उनकी फ़ाइलें वादे के अनुसार हटा दी गई हैं।
20 सितंबर तक, ZCode के ओपन सोर्स होने के वादे के लगभग दो दिन बाद, Z.ai के सार्वजनिक गोदाम में क्लाइंट सोर्स कोड अभी तक नहीं मिला है।
जब भविष्य में इसे खुला स्रोत बनाया जाता है, तो बाहरी दुनिया को संबंधित संस्करण या संबंधित संशोधन रिकॉर्ड देखने की आवश्यकता होती है।
केवल मरम्मत किए गए कोड को देखकर, यह स्पष्ट नहीं है कि अपलोड पहले क्यों ट्रिगर किया गया था और कौन सी फ़ाइलें एकत्र की गई थीं।
ZCode तीसरे पक्ष की समीक्षा शुरू करने का भी वादा करता है। समीक्षा दल, कार्यक्षेत्र और समय-सारिणी को और अधिक स्पष्टीकरण की आवश्यकता है।
उम्मीद है कि यह समीक्षा क्लाइंट कोड और सर्वर लॉगिंग दोनों की जांच करेगी। प्रासंगिक प्रसंस्करण, पहुंच और विलोपन रिकॉर्ड को उपयोगकर्ता कोड का खुलासा किए बिना निरीक्षण के लिए समीक्षक को सौंपा जा सकता है; समीक्षा के परिणामों को प्रभावित उपयोगकर्ताओं को सूचित किया जाना चाहिए।
टिप्पणियाँ