ZCode-მა სამუშაო სივრცეები ატვირთა — გამორთვა მხოლოდ სკანდალს მოჰყვა

21 სექტემბერს Z.ai-მ, როგორც Reuters-ის ცნობაშია აღწერილი, ZCode-ის ზოგი ფუნქცია გათიშა და მისი კოდი საჯაროდ გამოაქვეყნა მას შემდეგ, რაც დეველოპერებმა ადგილობრივი რეპოზიტორიების უნებართვო ატვირთვა გამოავლინეს; კომპანიამ მიზეზად ნაგულისხმევად ჩართული Codebase Indexing დაასახელა, განაცხადა, რომ ღრუბელში მოთავსებული მონაცემები წაშლილია, და დასძინა: „We welcome developers to continue reviewing ZCode and reporting potential issues.“ ატვირთვის ფარგლები მომხმარებლის მიერ ასისტენტისთვის მიწოდებული კოდის ფრაგმენტით არ შემოიფარგლებოდა: ძველი კლიენტი სამუშაო სივრცის უფრო ფართო ასლს ამზადებდა.

18 სექტემბრის ტექნიკურ ჩანაწერში დეველოპერი ferstar აღწერს საკუთარ კომპიუტერზე შექმნილ 313 მბ-იან დაშიფრულ არქივს: კომერციული პროექტის ამ ასლის ატვირთვა 564-ჯერ უშედეგოდ სცადა, ხოლო ცალკე, საჯარო რეპოზიტორიის დაახლოებით 15 კბ-იანი ასლი სერვერმა მიიღო. დიდი არქივი ადგილობრივ რიგში დარჩა. მისი ზომა და მცდელობების რაოდენობა არც ღრუბელში მოხვედრილი კომერციული კოდის მოცულობაა და არც დაზარალებულ მომხმარებელთა რიცხვი.

ერთი არქივი ინციდენტის მასშტაბს ვერ აჩვენებს

დიდი კომერციული არქივის წარუმატებელი გადაგზავნა არ ნიშნავს, რომ ZCode-დან სამუშაო სივრცეები საერთოდ არ გასულა. იმავე დეველოპერის მცირე საჯარო რეპოზიტორიაზე მიღების ჩანაწერი არსებობს. ასეთი განსხვავება არსებითია: ადგილობრივ საქაღალდეში დარჩენილი დაშიფრული ფაილი ატვირთვის მცდელობას აჩვენებს, ხოლო სერვერის მიღების ჩანაწერი უკვე სხვა მდგომარეობაზე მიუთითებს.

სხვა მომხმარებელმა ZCode-ის GitHub-ზე გამოქვეყნებულ მიმართვაში აღწერა დაახლოებით 256 მბ-იანი დაშიფრული ასლი და ერთი სამუშაო სივრცისთვის სერვერის მიერ მიღების დამადასტურებელი ჩანაწერი; მან კიდევ სამ სამუშაო სივრცეზე ადრინდელი მიღების ჩანაწერებიც მიუთითა. ეს კონკრეტული მომხმარებლის წარმოდგენილი მტკიცებულებაა და მთელი სერვისის სტატისტიკად ვერ გადაიქცევა. შემთხვევა მაინც აჩვენებს, რატომ არ შეიძლება ერთი კომპიუტერის წარუმატებელი მცდელობებით ყველა ატვირთვის შედეგზე მსჯელობა.

საჯაროდ ცნობილი ჩანაწერები არ ადგენს, რამდენ ანგარიშს ან რეპოზიტორიას შეეხო მექანიზმი მთლიანობაში. მომხმარებლისთვის უფრო ზუსტი კითხვაა, რომელი სამუშაო სივრცეები გახსნა ძველ კლიენტში და რომელი მათგანის ასლის მიღება დადასტურდა. პროგრამის დაყენება თავისთავად კონკრეტული პროექტის გადაგზავნას არ ამტკიცებს, მაგრამ მხოლოდ დიდი არქივის ადგილობრივად დარჩენაც სხვა პროექტების მიღებას ვერ გამორიცხავს.

როგორ გასცდა ატვირთვა დავალების კონტექსტს

კოდირების ასისტენტს დავალების შესასრულებლად ფაილების წაკითხვა შეუძლია, თუმცა ZCode-ის ძველი მექანიზმი ცალკე მოქმედებდა: სამუშაო სივრცის ფაილებს არქივში აერთიანებდა, შიფრავდა და Alibaba Cloud-ის ობიექტურ საცავში გასაგზავნად ამზადებდა. კლიენტი ჯერ ZCode-ის სერვერიდან იღებდა ატვირთვის უფლებამოსილებასა და დაშიფვრის საჯარო გასაღებს, შემდეგ კი არქივს უშუალოდ საცავში გზავნიდა. ამიტომ ასლის საზღვარს მომხმარებლის მიერ გახსნილი ფაილი ან შეკითხვაში ჩასმული მონაკვეთი არ ადგენდა.

ტექნიკურ აღწერაში ასლის შექმნა დაკავშირებულია როგორც შეკითხვის გაგზავნამდე მოქმედებასთან, ისე Repo Wiki-ს განახლებასთან. Z.ai-მ პრობლემა კოდბაზის ინდექსაციას დაუკავშირა, მაგრამ ძველ კლიენტში ინტერფეისის შესაბამისი პარამეტრების გამორთვა არქივის შექმნისა და ატვირთვის გზას არ აჩერებდა. ინდექსაციის ან მონაცემის შემდგომი გამოყენების პარამეტრი ამიტომ არ იყო სანდო საზღვარი იმის დასადგენად, ტოვებდა თუ არა სრული რეპოზიტორია კომპიუტერს.

არქივი იშიფრებოდა სერვერიდან მიღებული საჯარო გასაღებით, ხოლო მის გასახსნელად საჭირო კერძო გასაღები მომხმარებლის კომპიუტერზე არ იყო. ეს ხსნის კიდევ ერთ პრაქტიკულ შეზღუდვას: ადგილობრივად დარჩენილი დაშიფრული ფაილის არსებობა ხილულია, მაგრამ მისი შიგთავსის უშუალოდ გახსნა და ღრუბელში მოხვედრილ ასლთან შედარება მომხმარებელს იმავე მექანიზმით არ შეუძლია. შიგთავსის შესაფასებლად განსაკუთრებით მნიშვნელოვანი ხდება შეფუთვისას შექმნილი ფაილების სია.

რა შეიძლებოდა აღმოჩენილიყო სამუშაო სივრცის ასლში

ferstar-ის აღწერილ დიდი არქივის სიაში მიმდინარე კოდთან და დოკუმენტაციასთან ერთად Git-ის ობიექტები, დიდი ფაილების ქეში და ადგილობრივი ცვლილებების ისტორია ჩანდა. Git-ის ობიექტები პროექტის მხოლოდ დღევანდელ მდგომარეობას არ ინახავს: მათში შეიძლება ძველი კომიტებიდან შემორჩენილი ფაილებიც იყოს. ამიტომ მიმდინარე საქაღალდის დათვალიერება ვერ პასუხობს კითხვას, რა შედიოდა შეფუთულ ისტორიაში.

ამავე მიზეზით, დღევანდელი .env ფაილის გამორიცხვა ძველი საიდუმლოს ბედს არ წყვეტს. ერთ-ერთ გამოქვეყნებულ მომხმარებლის ჩანაწერში მიმდინარე .env ფაილი შეფუთვიდან გამორიცხულადაა აღწერილი, მაგრამ მისი ადრინდელი ვერსია შესაძლოა Git-ის ობიექტებში დარჩენილიყო, თუ ოდესმე რეპოზიტორიაში შეიტანეს. ეს შესაძლებლობაა და არა მტკიცება, რომ ყველა მომხმარებლის გარემოს ცვლადები ან გასაღებები გაიგზავნა.

ანალოგიურად, Git LFS-ის ქეში შეიძლება შეიცავდეს ადრე ჩამოტვირთულ დიდ ფაილებს, ხოლო reflog ადგილობრივი განშტოებებისა და ცვლილებების კვალს ინახავს. ასეთ მასალას სამუშაო სივრცის მფლობელმა შეიძლება აღარ ხედავდეს ჩვეულებრივ ფაილთა სიაში. რისკის შეფასებისას გადამწყვეტია კონკრეტული ასლის ფაილთა სია და მიღების მდგომარეობა — მხოლოდ რეპოზიტორიის ამჟამინდელი ხედი მონაცემების მთელ შესაძლო ფარგლებს ვერ აჩვენებს.

რას ნიშნავს კოდის გახსნა და მონაცემების წაშლა

სკანდალის შემდეგ გამოქვეყნებულ ZCode-ის კოდში ძველი არქივის შექმნისა და ატვირთვის გზა აღარ ჩანს; განახლებულ კლიენტზე აღწერილი ადგილობრივი შემოწმებაც ახალი დაშიფრული ასლების შექმნას აღარ აჩვენებს. ეს მომავალი გადაგზავნის მექანიზმის შეფასებისთვის მნიშვნელოვანი ცვლილებაა. საჯაროდ გამოქვეყნებული კოდი, თუმცა, ძველი კლიენტით ადრე მიღებული თითოეული არქივის მოძრაობის ჟურნალს არ შეიცავს.

წაშლის შესახებ განცხადება და ატვირთვის შემდეგ საცავის შემოწმება მიმდინარე მდგომარეობას ეხება. მომხმარებელს საკუთარი ანგარიშისთვის მიღებული არქივების სრული ჩამონათვალი, მათი შენახვის ხანგრძლივობა და წაშლამდე შესაძლო წვდომის ისტორია საჯარო ინფორმაციით დამოუკიდებლად არ ეძლევა. ეს მოკლე, მაგრამ მნიშვნელოვანი ზღვარია კომპანიის მიერ გამოცხადებულ რეაგირებასა და კონკრეტული რეპოზიტორიის მფლობელისთვის გადამოწმებად გარანტიას შორის.

ასევე საჭიროა ძველი და განახლებული კლიენტის ერთმანეთისგან გამიჯვნა. ახალ ვერსიაში გადაგზავნის გზის არარსებობა ძველი ვერსიის ქცევას არ ცვლის; ძველი კლიენტის ადგილობრივი ასლები და მიღების ჩანაწერები ცალკე უნდა შეფასდეს. გამოქვეყნებული წყაროს დათვალიერება სასარგებლოა ახალი ფუნქციების გასაგებად, მაგრამ წარსულში მიღებული მონაცემის ბედს თავისთავად ვერ ადგენს.

რა უნდა გადაამოწმოს რეპოზიტორიის მფლობელმა

ორგანიზაციამ, რომელიც ინციდენტის პერიოდში ZCode-ს იყენებდა, შემოწმება გახსნილი სამუშაო სივრცეების ჩამონათვალით უნდა დაიწყოს. შემდეგ თითოეული სივრცისთვის ერთმანეთისგან უნდა გაიმიჯნოს არქივის შექმნა, წარუმატებელი გაგზავნა და სერვერის მიერ მიღება. ამ განსხვავების გარეშე ყველა ადგილობრივი ასლის კომპრომეტირებულად გამოცხადებაც ზედმეტია და ყველა მათგანის უვნებლად მიჩნევაც.

1. შეაგროვეთ ძველი კლიენტის ადგილობრივი ასლების მდგომარეობის ჩანაწერები და ფაილთა სიები. განსაკუთრებით მოძებნეთ, დარჩა თუ არა ასლი რიგში, თუ არსებობს მისი მიღების ჩანაწერი; შედეგები კონკრეტულ რეპოზიტორიებს დაუკავშირეთ.
2. შეამოწმეთ მიმდინარე ფაილები, Git-ის ისტორია და დიდი ფაილების ქეში. მოძებნეთ იქ მოხვედრილი .env ფაილების ძველი ვერსიები, კონფიგურაციები, API გასაღებები, ტოკენები, პაროლები და სერტიფიკატები; მხოლოდ დღევანდელ გამორიცხვის წესებს ნუ დაეყრდნობით.
3. თუ მიღებულ ასლში მოქმედი საიდუმლო შეიძლებოდა ყოფილიყო, გააუქმეთ ძველი მნიშვნელობა და შექმენით ახალი. შესაბამისი სერვისის წვდომის ჟურნალში გადაამოწმეთ საეჭვო გამოყენებაც: ფაილის რეპოზიტორიიდან წაშლა უკვე გაცემულ გასაღებს ძალას არ უკარგავს.
4. მსგავსი ასისტენტის გამოყენებისას ცალ-ცალკე გაარკვიეთ, რა იკითხება ადგილობრივად, რა იგზავნება მოდელთან და რა ინახება ინდექსაციის ან აღდგენის ფუნქციისთვის. ნაგულისხმევი პარამეტრი და ინტერფეისის გამორთვის ღილაკი მხოლოდ მაშინ არის საკმარისი, თუ მართლაც აჩერებს სრული ასლის შექმნასა და გაგზავნას.

შესაძლო გამჟღავნების ფარგლებს ყველაზე უკეთ კონკრეტული სამუშაო სივრცის ფაილთა სია და მიღების ჩანაწერი განსაზღვრავს. თუ ეს მონაცემები მომხმარებელს არ აქვს, მოქმედი საიდუმლოებების როტაცია იმ რეპოზიტორიებისთვის რჩება გონივრულ პასუხად, რომელთა ასლის მიღებაც დადასტურებულია ან გამორიცხული ვერ არის.

ასევე წაიკითხეთ:

• OpenAI-ის აგენტებმა 53 მომხმარებლის სურათი გარე საიტებზე ატვირთეს