Eine Website zur Abnahme dokumentieren

Sealjar hält ausgewählte Webseiten und den aktuellen Code in einem ZIP fest. Bildschirmfotos zeigen die Desktop- und Smartphone-Ansicht. Der gerenderte HTML-Inhalt und ein Bericht gehören ebenfalls dazu. Ein vertrauenswürdiger Zeitstempel zeigt, dass die versiegelten Dateien spätestens zu diesem Zeitpunkt vorlagen.

Vor der Erfassung muss feststehen, welche Seiten und welcher Code erfasst werden dürfen. Auch der Ausgabeordner muss festgelegt sein. Jede URL wird einzeln angegeben; Sealjar folgt keinen Links zur Suche nach weiteren Seiten. Ein Paket kann mehrere Hosts und ein Git-Repository enthalten. Die Erfassung ersetzt weder das Abnahmeprotokoll noch einen Liefernachweis.

Installation und Vorschau

Die Installationsanleitung beschreibt Linux, macOS, Git Bash, WSL und natives Windows. Für Webseiten und Demo wird Chrome oder Chromium benötigt, für Code und Demo Git. Pakete lassen sich ohne Chrome oder Git prüfen. Auch der Berichtsexport und die Wiederherstellung von Snapshot-Dateien brauchen diese Programme nicht. Ein History-Bundle braucht Git zum Auschecken. Ohne Chrome sind bei reiner Code-Erfassung HTML-Berichte möglich, aber keine PDFs. report --pdf kopiert nur bereits gespeicherte PDFs.

Im Stammordner des zu erfassenden Repositorys kann die Ausgabe im übergeordneten Ordner liegen. Der aufgelöste Pfad muss außerhalb des Repositorys liegen. Die Beispiel-URL wird durch die freigegebene Adresse ersetzt:

OUT=$(cd .. && pwd -P)
sealjar capture https://staging.example.com . --out "$OUT" --dry-run

Wenn die vollständige Vorschau und der Ausgabeordner stimmen, kann die Erfassung starten:

sealjar capture https://staging.example.com . --out "$OUT" --confirm --no-prompt

Die vollständige Vorschau zeigt Seiten, Code, Ausschlüsse und den absoluten Ausgabeordner. Relative Pfade beziehen sich auf den aktuellen Arbeitsordner. Der Trockenlauf startet keinen Browser, greift nicht aufs Netz zu und schreibt keine Dateien. Bei Formularanmeldung ist --login nur mit einer anwesenden Person möglich. HTTP-Basic-Auth kann über SEALJAR_AUTH übergeben werden. Zugangsdaten gehören weder in URLs noch in Protokolle. Authorization-Header der Anwendung, etwa Bearer-Tokens für eine API, bleiben erhalten. Sealjar ergänzt Basic-Auth nur bei Anfragen ohne eigenen Authorization-Header und nur für die aufgeführten Zielursprünge. Weitere Optionen stehen unter Capture.

Ergebnis lesen und prüfen

Neben dem ZIP entsteht ein Leseordner. report/report.de.html bleibt zusammen mit den Bildern in diesem Ordner; die Verweise sind relativ. Das Bericht-PDF ist eine eigenständige Lesekopie. Bericht und SEAL.html sind ohne Installation lesbar. Der Bericht verweist für Zeitstempel auf die Siegelseite und verify. Die Siegelseite selbst gehört nicht zur Dateiliste im Manifest. Beim Export wird sie aus geprüften Daten neu erstellt.

sealjar verify paket.sealjar.zip

Der tatsächliche ZIP-Pfad ersetzt den Beispielnamen. Drei Ergebnisse bleiben getrennt: Erfassung, Dateien und Zeitstempel. Code 0 bedeutet, dass die Dateien übereinstimmen und mindestens ein Zeitstempel vertrauenswürdig ist. Probleme bei der Erfassung können trotzdem vorliegen. Code 10 bezeichnet veränderte oder ungültige Inhalte, Code 11 einen fehlenden vertrauenswürdigen Zeitstempel. Originaldateien bleiben unverändert; eine fehlgeschlagene Prüfung wird nicht durch Bearbeiten der erfassten Dateien behoben.

Aussagekraft und Datenschutz

Passende Prüfsummen (SHA-256) zeigen die Übereinstimmung mit dem Manifest. Ohne authentifiziertes Manifest könnten Dateien und Prüfsummen gemeinsam ersetzt worden sein. Die Erfassungszeit selbst wird durch den Zeitstempel nicht unabhängig geprüft.

Das Paket zeigt nicht, ob die Inhalte wahr oder vollständig sind. Es zeigt auch nicht, ob die erfassende Person ehrlich gehandelt hat oder die gespeicherten Daten vom Server stammen. Es belegt weder Lieferung noch Abnahme. Ob der erfasste Code die Website erzeugt hat, bleibt ebenfalls offen. Eine bestimmte rechtliche Wirkung oder Zulässigkeit als Beweismittel wird nicht zugesagt. Bei wichtigen Streitfällen empfiehlt sich eine neutrale Begleitung, etwa durch einen Sachverständigen oder Notar.

Vertrauen entsteht durch System-Wurzelzertifikate, das eingebettete FreeTSA-Root oder separat beschaffte Wurzelzertifikate, die bei der Prüfung angegeben werden. Zertifikate allein aus dem Paket begründen kein Vertrauen. Offline-Prüfungen erkennen spätere Zertifikatswiderrufe nicht. Sealjar v0.1 bewertet keine eIDAS-Qualifikation und bezeichnet Zeitstempel nicht als qualifiziert. DigiCert ist der Standard, FreeTSA der Ausweichdienst. Eigene Dienste lassen sich mit --tsa wählen; stamp ergänzt später Zeitstempel, ohne Manifest oder erfasste Dateien zu ändern.

Bei der Erfassung werden Zielseiten und deren Ressourcen geladen. Hinzu kommen Anfragen an DNS-Server und Zeitstempeldienste. Ein Zeitstempeldienst erhält einen Hash und übliche Netzwerkmetadaten. Zeitstempelanfragen beachten Standard-Proxys, die Verbindungsproben von doctor nicht. Maskierung und Ausschlüsse entfernen nicht alle privaten Inhalte. Solche Inhalte können weiterhin in Bildschirmfotos und HTML stehen, ebenso im Code und in der Git-Historie. Gerade die Historie kann alte Geheimnisse enthalten. Vor der Weitergabe ist eine Prüfung des Pakets nötig.

Wenn die Demo keinen Online-Zeitstempel erhält, nutzt sie einen lokalen Token mit dem Hinweis „Demo timestamp, not trusted“. Die Prüfung endet dann mit Code 11. Der Signaturschlüssel ist öffentlich. Auch wenn ein ausdrücklich angegebenes Wurzelzertifikat dem Token Vertrauen gewährt, liefert er keinen unabhängigen Zeitnachweis.

Weiter geht es mit Pakete lesen und prüfen.