Gemini CLI build ფაილების შეცვლამდე ახლა ნებართვას ითხოვს

Google-მა Gemini CLI-ის ახალი ვერსია, 0.61.0, ოთხშაბათს გამოუშვა. აგენტი ამიერიდან ცალკე დადასტურებას ითხოვს მანამ, სანამ build კონფიგურაციის ფაილებს შეცვლის, ასეთი ცვლილების შემდეგ build-ის ან ტესტების ბრძანებას გაუშვებს, ან იმ shell ბრძანებას შეასრულებს, რომლის არგუმენტებიც არასანდო გარე კონტენტიდან მოდის. იმავე გამოშვებაში sandbox-იც გამაგრდა — ჰოსტის მონაცემები მის შიგნით მომუშავე პროცესებისთვის მიუწვდომელი ხდება.

build ფაილები, როგორც შეტევის ვექტორი

package.json-ში, Makefile-ში, pyproject.toml-ში ან Bazel-ის BUILD ფაილში ერთი ცვლილებაც კმარა, რომ ახალი დამოკიდებულება მოზიდოს ან სკრიპტი გაეშვას. Gemini CLI ასეთ რედაქტირებას ვებ-ძიებიდან მიღებული ინფორმაციით ახორციელებს, შემდეგ კი shell ბრძანებებს უშვებს. თუ ბაგის გასწორებისას წაკითხულ დოკუმენტაციაში დამალული ინსტრუქცია აღმოჩნდა, აგენტს შეუძლია postinstall სკრიპტი დაამატოს და მავნე კოდი შეასრულოს — დეველოპერი ბრძანებას არ აკრეფს.

სწორედ ამ სცენარს ეხება pull request #29250. build ფაილების რედაქტირება ახლა დადასტურებას მოითხოვს, CLI კი თვალს ადევნებს, რომელი ფაილები შეიცვალა სესიის განმავლობაში — ამის შემდეგ npm run, make ან cargo ცალკე ნებართვის გარეშე აღარ შესრულდება. დადასტურების ფანჯარა სრულ diff-ს აჩვენებს.

უცხო არგუმენტები — ცალკე თანხმობა

მეორე შემოწმება ბრძანებების არგუმენტებს ეხება. ვებ-გვერდებიდან, MCP სერვერების პასუხებიდან, Google Docs-იდან და Buganizer-იდან (Google-ის შიდა ბაგების ტრეკერი) მიღებული კონტენტი ახლა არასანდოდ ითვლება, და CLI დადასტურებას ითხოვს, თუ shell ბრძანების დროშები ან არგუმენტები ამ კონტენტის ტოკენებს ემთხვევა. დიალოგში მუდმივი თანხმობის ვარიანტი არ არის — „ყოველთვის დაუშვი“ აქ არ მუშაობს.

შემოწმებები restricted workspace mode-ს უკავშირდება — უსაფრთხო რეჟიმს, რომელსაც CLI იმ საქაღალდეებზე რთავს, რომლებიც მომხმარებელს სანდოდ არ აქვს მონიშნული. pull request არ აზუსტებს ქცევას სანდო საქაღალდეში ან ავტომატური დადასტურებისას. ტოკენების შედარება მნიშვნელობების წარმომავლობას არ ადევნებს თვალს; ბრჭყალებში ჩასმული არგუმენტები, გარემოს ცვლადების პრეფიქსები, shell-ის გადამისამართების სამიზნეები და Windows-ის ბილიკები 11 სექტემბრამდე გამოსწორდა.

sandbox-ი API გასაღებებს იცავს

მეორე pull request (#29214) sandbox-ს ამაგრებს. Docker-ის, Podman-ის, LXC-ის ან macOS Seatbelt-ის შემთხვევაში ჰოსტის .gemini საქაღალდე შიგნით აღარ მაუნტდება; CLI მას API გასაღებებისა და hooks-ებისგან გაწმენდილ ასლს გადასცემს. sandbox-ი მგრძნობიარე ადგილებში ვერ გაეშვება, ხოლო ახალი Seatbelt წესები OAuth-ის მონაცემებზე და .env ფაილებზე წვდომას კრძალავს.

Google-ის დოკუმენტაცია sandbox-ს AI ოპერაციებსა და ჰოსტ სისტემას შორის უსაფრთხოების ბარიერს უწოდებს, თუმცა ხაზს უსვამს, რომ ის რისკს ამცირებს და არ აღმოფხვრის. არსი ასე ჩანს: sandbox-ს პროექტის საქაღალდე მაუნტირებული აქვს, ამიტომ შიგნით დაწერილი „მოწამლული“ package.json რეპოზიტორში რჩება, როცა CI build-ს გარეთ უშვებს.

ღია კოდის ხელსაწყო 18 ივნისიდან ძირითადად კორპორატიულ კლიენტებსა და ფასიანი API გასაღების მქონე დეველოპერებს ემსახურება — Google-მა მაისში განაცხადა, რომ Pro, Ultra და უფასო პაკეტის მომხმარებლები დახურულ Antigravity CLI-ზე გადადიან. უსაფრთხოების სამუშაოები კვლავ საჯაროდ მიმდინარეობს.