AI oddaje ZIP. Odbierz zawartość, zanim go rozpakujesz

Paczka ma się rozpakować do jednego folderu, zawierać uzgodnione materiały i nie zastępować niczego poza nim. To brzmi skromnie jak na projekt z AI, lecz właśnie tę obietnicę warto odebrać przed otwieraniem gotowych dokumentów. Archiwum ZIP porządkuje przekazanie plików. Nie wystawia im świadectwa dobrego zachowania.

Na początku potrzebujemy rozróżnić listę zawartości, zapis po rozpakowaniu oraz późniejsze użycie poszczególnych plików. Każdy etap odpowiada na inne pytanie. Ładny wykres nie potwierdza, że do paczki nie dołączono zbędnego źródła danych. Poprawna lista nazw nie dowodzi jeszcze, gdzie narzędzie zapisze elementy i czy niczego nie zastąpi.

Przyjrzyjmy się temu na małej, własnej próbie, a potem na wymaganiach dla procesu. Przykłady dotyczą neutralnych materiałów. Odbiór operacyjny nie zastępuje specjalistycznego badania niezaufanych lub podejrzanych plików; taki zakres wymaga odpowiedniego środowiska i kompetencji.

Trzy pliki, które naprawdę przeszły przez paczkę

Na potrzeby tego tekstu utworzono własne archiwum z trzema krótkimi plikami tekstowymi. Jeden zawiera instrukcję przekazania, drugi fikcyjne liczby w CSV, trzeci tekst legendy. Nazwy wskazują odpowiednio foldery „przekazanie”, „dane” i „wykres”. Materiał nie pochodził od modelu ani z zewnętrznej paczki. Znamy jego zawartość, bo przygotowano ją do tej demonstracji.

Narzędziami zip i unzip zapisano archiwum, odczytano jego listę, a następnie rozpakowano je do osobnego pustego folderu. Lista obejmowała trzy oczekiwane pliki. Porównanie bajtów każdego wejścia i odpowiadającego mu wyniku potwierdziło identyczną treść. Zachowano archiwum, wynik próby i skróty plików. To rzeczywiście wykonane czynności, nie scenariusz przedstawiony jako gotowy test.

Dowód ma jednak wąski zakres: ta własna, zwykła paczka przeniosła trzy znane pliki bez zmiany treści. Nie badano odmowy zapisu poza folderem, archiwum o nadmiernym rozmiarze ani działania podejrzanych elementów. Sukces neutralnego przypadku nie odpowiada na wszystkie te pytania. Pokazuje natomiast, jak powiązać deklarowany materiał z otrzymanym wynikiem.

Przy skrótach plików w raporcie AI trzeba zachować takie powiązanie z rzeczywistymi bajtami. Sam ciąg znaków w wiadomości wykonawcy nie pozwala jeszcze potwierdzić tożsamości. Nawet poprawnie obliczony skrót nie rozstrzyga, czy treść jest właściwa dla zadania albo czy wolno ją uruchomić.

W fikcyjnym projekcie raportu spodziewamy się instrukcji, liczb i legendy. Plik z roboczą historią klientów nie należy do tego zamówienia. Jeżeli pojawi się w spisie, trzeba wyjaśnić go przed przekazaniem dalej, niezależnie od tego, czy wykres korzysta z niego na ekranie. „Model dołożył wszystko dla kompletności” nie jest decyzją o zakresie udostępnienia.

Spis powinien rozróżniać pliki od wpisów oznaczających foldery. Inaczej wykonawca policzy elementy archiwum, a odbiorca dokumenty i obaj podadzą różne, pozornie sprzeczne liczby. Przy małej paczce najczytelniej pokazać pełną listę z rolą każdej pozycji. Dla dużego przekazania potrzebna jest uzgodniona metoda porównania; widoczny początek listy nie dowodzi kompletności całego spisu.

Jeżeli zawartości części elementów nie można odczytać, oznacz je jako niesprawdzone. Dotyczy to również plików wymagających hasła lub narzędzia, którego odbiorca nie ma. Widoczna nazwa nie daje podstawy do wpisania „treść przejrzana”. Właściciel przekazania powinien dostarczyć uzgodnioną drogę dostępu albo usunąć zbędny element i przygotować nową paczkę.

Taki spis może być częścią odbioru materiałów po projekcie z agentami AI. Dla samego ZIP potrzebujemy pełnych nazw wewnątrz paczki, rodzaju elementów i ich związku z zamówieniem. Tytuł archiwum nie zastępuje tej informacji. „Final” na końcu nazwy pozostaje aspiracją autora, dopóki nie wiadomo, co znalazło się w środku.

Nazwa w spisie i miejsce zapisu to różne rzeczy

Plik wewnątrz archiwum może mieć nazwę wraz z informacją o położeniu w folderach. Narzędzie musi przełożyć tę informację na miejsce zapisu. Odbiorca powinien znać dozwolony folder docelowy oraz zasadę postępowania z nazwą, która nie pasuje do tego zakresu. Nie wystarczy, że okno podglądu pokazuje znajomy plik tekstowy.

Dokumentacja Pythona odróżnia obsługę nazw w extract i extractall od interfejsu zipfile.Path, który nie przeprowadza takiej normalizacji i pozostawia sprawdzenie nazw wywołującemu. Ostrzega też przed rozpakowywaniem niezaufanych archiwów bez wcześniejszej kontroli. Nazwa biblioteki nie opisuje więc samodzielnie użytej drogi odbioru.

Osoba zamawiająca odbiera konkretny skutek: nic nie powinno trafić poza wskazane miejsce. Wykonawca techniczny ma natomiast wyjaśnić, jak konkretny program rozstrzyga docelową ścieżkę i co odrzuca. Nie projektujemy tu gotowego zabezpieczenia przez wyszukiwanie jednego fragmentu tekstu w nazwie. Kontrola musi odpowiadać systemowi, typom elementów i rzeczywistej metodzie zapisu.

Dokumentacja Go archive/zip opisuje błąd ErrInsecurePath warunkowo, przy ustawieniu GODEBUG `zipinsecurepath=0`. Zaznacza również możliwość zignorowania błędu przez program korzystający z biblioteki. Sama obecność sprawdzającego mechanizmu nie dowodzi, że aplikacja kończy operację odmową.

W protokole potrzebujemy zatem odpowiedzi na pytanie o zachowanie całej używanej aplikacji, nie tylko linku do jej zależności. Gdy nazwa jest odrzucana, co zobaczy operator? Czy reszta paczki zostanie zapisana? Czy częściowy wynik otrzyma oznaczenie niekompletności? To decyzje procesu, które powinny być uzgodnione przed próbą.

Do rozstrzygnięcia pozostaje również zderzenie nazw. W fikcyjnej paczce dwa różne foldery mogą zawierać własny plik „opis.txt”. Zachowanie struktury utrzymuje rozróżnienie. Gdy dalszy importer składa wszystko w jednym folderze, musi mieć jawną regułę odmowy, zmiany nazw albo innego uporządkowania wyniku. Nie powinien po cichu wybierać jednego tekstu. Porównanie samych końcówek nazw nie wystarczy do odebrania takiej zmiany.

Python opisuje także domyślne nadpisywanie plików przy ponownym rozpakowaniu tego samego archiwum. To zachowanie wskazanego modułu. Nie zakładamy identycznej reakcji każdego programu, ale w odbiorze trzeba nazwać regułę dotyczącą już istniejącego celu.

Własna próba zaczynała się od pustego folderu, więc nie sprawdziła zachowania przy konflikcie z wcześniejszym plikiem. Osobny przypadek kontrolny powinien wykorzystać wyłącznie neutralną zawartość przeznaczoną do tej próby. Oczekiwanie trzeba zapisać przed uruchomieniem: odmowa, zachowanie starszego elementu albo świadome zastąpienie. W wyniku porównuje się oba stany, a nie tylko komunikat o zakończeniu.

Osobno nazwij dozwolone rodzaje elementów. Jeśli przekazanie wymaga zwykłych plików i folderów, dowiązanie, czyli element odsyłający do innego miejsca, wymaga wyjaśnienia. Osoba odbierająca nie musi umieć analizować wszystkich odmian archiwum. Musi mieć ustalony warunek zatrzymania i właściwego wykonawcę kontroli zamiast odruchu „rozpakujmy, może się uda”.

Taką drogę można omówić w operacyjnym przeglądzie przekazywania plików w Aeneia Audit. Wybierzemy materiał, oczekiwany skutek i potrzebne dowody. Implementacja mechanizmu rozpakowywania lub specjalistyczne sprawdzenie jego zabezpieczeń wymaga odrębnie ustalonego zakresu technicznego.

Nie przenoś także wniosków z samej kontroli polecenia powłoki przygotowanego przez AI. Można poprawnie przekazać nazwę archiwum do programu, a następnie nieprawidłowo obsłużyć nazwy znajdujące się wewnątrz. To kolejna granica danych; prawidłowe cudzysłowy komendy nie rozstrzygają struktury paczki.

Mały plik nie ustala wielkości pracy

Rozmiar pobranego archiwum i łączny rozmiar rozpakowanych materiałów to dwa różne parametry. Zgoda na przyjęcie niedużego ZIP nie powinna oznaczać nieograniczonego zapisu jego zawartości. Nie potrzebujemy do tego demonstracji obciążającej komputer. Potrzebujemy jawnych limitów i dowodu reakcji w kontrolowanym środowisku.

OWASP zaleca uwzględnianie rozmiaru po dekompresji, gdy przyjęty plik będzie rozpakowywany. Limit pliku przesyłanego i limit dalszego przetwarzania odpowiadają na inne ograniczenia zasobów. Odbiór powinien ustalić, które z nich faktycznie egzekwuje aplikacja.

W zwykłym procesie przekazywania raportów przydatne będą granice liczby elementów, łącznego zapisu i pojedynczego pliku. Właściciel procesu ustala je z wykonawcą na podstawie potrzebnych materiałów. Limit nie powinien powstawać wyłącznie przez skopiowanie przypadkowego ustawienia. Raport z trzema tekstami oraz paczka zdjęć źródłowych mogą wymagać innych wartości.

Jeśli wewnątrz dopuszczono kolejne archiwa, określ, czy aplikacja tylko je przechowuje, czy także automatycznie rozpakowuje. Samo znalezienie ZIP w ZIP nie oznacza, że wykonano drugi etap. Z kolei automatyczne wejście w następny kontener musi należeć do zakresu kontroli. Dla prostego przekazania raportu łatwiej może być zażądać jednej przejrzystej struktury bez takiego zagnieżdżenia.

Próbę granicy przygotowuje osoba odpowiedzialna za środowisko. Może wykorzystać małe, kontrolowane wartości limitów, zamiast tworzyć ogromne archiwum. Zapis powinien pokazać oczekiwaną odmowę, rzeczywisty komunikat i stan pozostawionych materiałów. W środowisku testowym automatyzacji chodzi właśnie o kontrolę skutków; etykieta „test” na ekranie nie ogranicza zużycia dysku.

Pomyśl również o ponowieniu po przerwaniu. Czy aplikacja zaczyna od nowego pustego miejsca, usuwa własny częściowy wynik czy pyta o jego zastąpienie? Każda wybrana droga wymaga rozpoznania, które pliki należą do tej próby. Nie sprzątaj całego współdzielonego folderu, żeby wygodnie zresetować odbiór jednego archiwum.

Rozpakowane materiały nadal potrzebują własnego odbioru

Po zakończeniu porównaj wynik ze spisem i zamówieniem. Czy wszystkie potrzebne pliki istnieją? Czy trafiają do ustalonej struktury? Czy nie pominięto materiału, którego brak ujawni się dopiero przy otwieraniu raportu? Sukces programu rozpakowującego nie powinien zastępować tej kontroli zgodności.

Dla brakującego elementu zanotuj, czy nie było go w spisie, został odrzucony przed zapisem, czy zapis zakończył się błędem. Te wyniki prowadzą do różnych poprawek. Nie uzupełniaj paczki plikiem z komputera autora podczas odbioru bez odnotowania zmiany. Odbiorca ma otrzymać kompletną wskazaną wersję, a nie instrukcję odtworzenia szczęśliwego zbiegu lokalnych plików.

Przy poprawce archiwum zachowaj wcześniejszą wersję i wskaż różnicę. Wymiana pliku danych może zmienić treść raportu, a wymiana instrukcji sposób jego użycia. Jeżeli paczka powstała ponownie, dowód dotyczący poprzedniej nie potwierdza automatycznie nowej zawartości. Nazwij wersję rzeczywiście otrzymaną przez odbiorcę.

Następnie zastosuj kontrolę właściwą dla poszczególnych formatów. Podgląd HTML i SVG dotyczy aktywnej treści i zależności dokumentu, a nie struktury ZIP. Plik może zostać zapisany dokładnie we właściwym miejscu i nadal wymagać osobnej oceny przed wyświetleniem. Rozpakowanie i uruchomienie nie powinny być jedną nierozróżnialną czynnością.

W naszym neutralnym przykładzie końcowe porównanie potwierdziło trzy identyczne teksty. Dla właściwego procesu decyzja powinna dodatkowo wskazać, kto może otwierać poszczególne materiały i w jakim celu. Jeżeli zamówiono raport do czytania, nie ma powodu, żeby odbiór po cichu rozszerzał się na wykonywanie dołączonego programu.

Przekazanie można przyjąć wtedy, gdy mamy konkretną paczkę, zgodną zawartość i sprawdzony sposób jej odbioru. Gdy nie potrafimy ustalić skutku rozpakowania, wykonawca ma dostarczyć odpowiedni dowód albo prostszą postać materiałów. Plik ma ułatwiać przejęcie pracy. Odbiorca nie powinien sam rozstrzygać zagadki, co właściwie dostał.