Smithery is now a part of Arcade.dev! Read more in our announcement here
Sprawdza podpis elektroniczny w PRZYCHODZĄCYM PDF - czy plik zmieniono po podpisaniu, kto go podpisał, kiedy, czy jest znacznik czasu i czy podpis obejmuje cały dokument...
Kancelaria dostaje podpisane PDF-y - wyroki, decyzje, umowy, pisma od drugiej strony - i zwykle ufa im na słowo albo na zielony pasek w czytniku. Ten skill sprawdza plik mechanicznie, w całości na maszynie kancelarii: dokument nie jest nigdzie wysyłany, narzędzie nie odpytuje żadnego serwera i działa bez internetu. Ma to znaczenie, bo sprawdzany plik zwykle jest objęty tajemnicą zawodową.
Najczęstszy realny problem nie brzmi „czy podpis jest fałszywy", tylko „czy ktoś dopisał coś po podpisaniu". PDF pozwala dołączyć kolejną wersję na końcu pliku - podpis pozostaje kryptograficznie nienaruszony, a dokument już nie jest tym, co podpisano. Skill to wykrywa.
Ten skill nie podpisuje. Złożenie podpisu to akt nieodwracalny i skuteczny na zewnątrz - zostaje człowiekowi. Narzędzie jest wyłącznie odczytowe.
Kolejność w pipeline OCR: jeśli dokument idzie potem do skanowania lub OCR
(drabinka PDF, silnik vlm-html z [[doc-intel-contract-pl]]), walidację podpisu
rób NAJPIERW, na oryginale. Przygotowanie skanu spłaszcza PDF przed renderem,
żeby pola formularza nie zniknęły z obrazu - i przy okazji NISZCZY podpis
kryptograficznie. Po spłaszczeniu nie ma już czego walidować.
Instalacja w izolowanym środowisku. Windows:
python -m venv .venv && .venv/Scripts/python.exe -m pip install pyHanko
Linux i macOS:
python3 -m venv .venv && .venv/bin/python -m pip install pyHanko
Uruchamiaj interpreterem z tego środowiska, nie systemowym - inaczej dostaniesz
ModuleNotFoundError. Windows:
.venv/Scripts/python.exe waliduj_podpis.py <plik.pdf>
Linux i macOS:
.venv/bin/python waliduj_podpis.py <plik.pdf>
Tryb maszynowy: dołóż --json (wynik zawiera werdykt_ogolny, podpisy,
zakres_sprawdzenia).
Kody wyjścia, identyczne w obu trybach: 0 podpis ważny w zakresie sprawdzonym,
1 brak podpisu albo werdykt inny niż ważny (w tym dokument zmieniony po
podpisaniu), 2 błąd odczytu pliku. Kod wynika z werdyktu, nie z tego, czy
udało się cokolwiek odczytać - nadaje się więc do kontroli automatycznej.
Werdykt jest jeden i łączony. Osobno podane „integralność OK" i „pokrywa cały
plik: nie" czytają się jak dobra wiadomość, a razem znaczą DOKUMENT ZMIENIONY PO PODPISANIU. Skill nigdy nie rozdziela tych dwóch ustaleń w podsumowaniu.
Czy podpis jest kwalifikowany w rozumieniu eIDAS. Do tego potrzebne są
unijne listy zaufane (LOTL/TSL) z kotwicami zaufania państw członkowskich,
których to narzędzie nie wgrywa. Bez nich łańcuch zaufania jest raportowany jako
NIEROZSTRZYGNIĘTY - i tak trzeba to powiedzieć klientowi, zamiast wyprowadzać
z zielonego napisu wniosek, którego on nie niesie.
Skill nie ocenia też, czy treść dokumentu jest prawdziwa merytorycznie.
Skill przeszedł przebieg na wygenerowanych plikach kontrolnych. pyHanko 0.36.2, Python 3.13, instalacja i wywołanie dokładnie wg instrukcji powyżej:
| Przypadek | Werdykt | Kod |
|---|---|---|
| PDF podpisany, nienaruszony | PODPIS WAZNY w zakresie sprawdzonym, łańcuch NIEROZSTRZYGNIETY |
0 |
| PDF podpisany, treść dopisana po podpisaniu (poprawny incremental update) | DOKUMENT ZMIENIONY PO PODPISANIU przy integralności OK |
1 |
| PDF bez podpisu | Dokument NIE zawiera podpisu |
1 |
Drugi wiersz to powód istnienia tego skilla: podpis pozostaje kryptograficznie nienaruszony, a dokument nie jest już tym, co podpisano. Werdykt łączy oba ustalenia zamiast pokazywać osobno „integralność OK".
Granica: pliki były kontrolne, z certyfikatem samopodpisanym. Skill nie przeszedł jeszcze biegu na prawdziwym piśmie z sądu podpisanym podpisem kwalifikowanym - to zostaje do zrobienia na materiale kancelarii. Sprawdzona jest mechanika, nie zachowanie wobec konkretnego dostawcy podpisu.
pyhanko loguje nieudaną budowę ścieżki certyfikatu jako błąd ze śladem stosu.
Przy braku wgranych kotwic zaufania jest to stan oczekiwany, nie awaria -
skrypt wycisza te logi i przenosi ustalenie do pola lancuch_zaufania. Nie
interpretuj tych śladów jako błędu narzędzia.
Te reguły obowiązują w każdym skillu tej wtyczki, także gdy sam skill milczy. Są skopiowane do każdego skilla, więc działają zarówno po instalacji całej wtyczki, jak i pojedynczego skilla.
Plugin obsługuje dokumenty: konwersję do Markdown, redlining .docx i anonimizację danych osobowych. Część operacji dotyka danych wrażliwych, więc reguła ochrony danych jest tu pierwsza.
let-it-be), zanim treść trafi do modelu. Dane osobowe nie powinny wychodzić do API. To zasada minimalizacji (RODO).Niektóre operacje są nieodwracalne (anonimizacja w trybie nieodwracalnym, zaakceptowanie wszystkich zmian w .docx). Skille oznaczają je jawnie - wykonuj je dopiero po potwierdzeniu przez człowieka.
Wynik to projekt. Nic nie zostaje wysłane ani złożone, zanim sprawdzi to uprawniony człowiek. Plugin przygotowuje plik, nie wykonuje aktu wysyłki.
Plugin daje narzędzia na dokumentach (konwersja, redline, anonimizacja, akta i chronologia). Nie ocenia treści prawnej. Weryfikację cytatu wobec źródła prawa daje plugin „fundament weryfikacyjny”; chronologia-stanowiska-pl sprawdza tylko, czy cytat stoi na wskazanej stronie akt.
