Im April fragte @mac nach für ihn brauchbaren PDF-Editoren jenseits von Adobe und trat damit einen laaangen Thread los, der sich über ein halbes Jahr erstreckte: Alternative zu kostenpflichtigen PDF Tools wie Acrobat Pro/DC oder pdf won...

Das lag nicht an den Allerweltsfähigkeiten von PDF-Editoren, sondern an zwei nicht ganz so weit verbreiteten Funktionalitäten: der PDF/A-Ausgabe und dem Umgang mit digitalen Signaturen.

Im Laufe der langen Diskussion wurde klar, dass nur ein gründlicher Test der Programme, die überhaupt mit diesen Eigenschaften aufwarten können, in Bezug auf diese eine fundierte Entscheidungsgrundlage würde bilden können. Den hatte ich gegen Ende des Threads versprochen, komme aber erst jetzt dazu, mein Versprechen einzulösen.

Um das recht klare Ergebnis vorwegzunehmen:

• Je nachdem, ob man nur eine, einige oder alle Varianten von PDF/A (bis einschließlich der 3er-Varianten) benötigt, kann man aus der folgenden Tabelle den entsprechenden Editor auswählen, im einfachsten Fall ist das aber gar nicht mehr nötig: Seit Big Sur beherrscht auch Vorschau die Ausgabe von PDF/A-2b und wenn man sich damit zufrieden geben kann, hat man bereits alles, was man braucht. (Zu den Unterschieden zwischen den verschiedenen PDF/A-Varianten siehe Wikipedia.)
• Bei den digitalen Signaturen erfüllte kein einziger PDF-Editor die Anforderungen vollständig; das schaffte nur der zum Vergleich herangezogene Acrobat Reader von Adobe. Da der kostenlos ist und, falls erforderlich, im Gegensatz zu fast allen anderen Adobe-Programmen auch auf den case-sensitiven Varianten der beiden macOS-Dateisysteme läuft (Adobe kann, wenn es nur will …), gibt es kein Argument, ihn nicht zu verwenden.

Hier nun die tabellarische Übersicht über die PDF/A und digitale Signaturen betreffenden Fähigkeiten der für den Mac erhältlichen PDF-Editoren, die das überhaupt können. Acrobat Pro DC blieb gemäß der Ausgangsfrage außen vor; stattdessen wurde Acrobat Reader zunächst zum Vergleich und schließlich als Referenzprogramm für digitale Signaturen aufgenommen.



Zur PDF/A-Ausgabe ist eine Erläuterung unnötig; man kann sich einfach an der Auflistung der gebotenen Varianten orientieren (die Ausgaben aller Programme wurden auf Konformität getestet und haben allesamt bestanden). Dabei fällt auf, dass der Foxit PDF Editor, der als einziger Editor digitale Signaturen zwar nur eingeschränkt, aber doch wenigstens fehlerfrei unterstützt, auch bezüglich des Umfangs der PDF/A-Unterstützung am besten abschneidet. PDFpen Pro sendet zur Konvertierung Daten ins Internet.

Weit mehr ist zu der Unterstützung digitaler Signaturen zu sagen. Dabei geht es an dieser Stelle nur um unterschiedlichen Fähigkeiten der einzelnen Programme; wie das digitale Signieren funktioniert und wofür die einzelnen Fähigkeiten benötigt werden, wird in dem parallelen Thread zum digitalen Signieren PDFs digital signieren – eine Anleitung besprochen.

Ein einziges rotes Feld (außer in der Spalte bezüglich PDF/A) macht den Einsatz eines PDF-Editors für digitale Signaturen bereits unmöglich; wie man auf einen Blick sieht, bleibt somit außer dem Acrobat Reader nur der Foxit PDF-Editor übrig, der allerdings keine Zeitstempel unterstützt (zu deren Funktion siehe PDFs digital signieren – eine Anleitung | Kapitel 8) und nur unvollständige Angaben bei der Überprüfung der Gültigkeit der Unterschriften macht.

Zertifikate für digitale Unterschriften haben nur eine Gültigkeit von 1 – 3 Jahren; abgelaufene Zertifikate müssen aber aufbewahrt werden. Im Lauf der Zeit sammeln sich so zahllose Zertifikate für dieselbe Person an. Will man zum Unterschreiben das aktuelle Zertifikat auswählen, bekommt zur Auswahl aber auch alle abgelaufenen Zertifikate nur mit dem (ja stets gleichen) Namen der Person, nicht aber dem Ablaufdatum angezeigt, ist es schlicht unmöglich, das korrekte Zertifikat auszuwählen; das passiert gleich 2 Programmen.

Manchmal müssen PDFs mehrfach unterschrieben werden, etwa gesondert die Zurkenntnisnahme eines Widerrufsrechts. Mehrere Programme erlauben das aber nicht; entweder ist nach der ersten eine weitere Unterschrift schlicht unmöglich oder aber die zweite Unterschrift macht die erste ungültig, weil sie als unzulässige Veränderung des Dokuments aufgefasst wird.

Livecycle Dynamic XFA-Formulare sind ein exotisches Adobe-Format für PDF-Formulare, das es erlaubt, Formulare abhängig von bereits gemachten Angaben zu verändern (z.B. in einem bestimmten Fall unnötige Felder auszublenden), das aber kaum unterstützt wird, da Adobe heftige Lizenzgebühren dafür verlangt. Versucht man z.B. in Vorschau solch ein PDF-Formular zu öffnen, erhält man auf einer ansonsten blanken PDF-Seite eine der beiden folgenden erbaulichen Meldungen:
Wer also Formulare unterschreiben will oder muss, die in Vorschau so aussehen, ist auf Livecycle Dynamic XFA-Kompatibilität angewiesen.




Interoperabilität

Offenkundig ist es für digitale Signaturen von entscheidender Bedeutung, dass der Status der Unterschrift (gültig – Gültigkeit unbekannt – ungültig) von allen Programmen gleich angezeigt wird. Da Adobe nicht nur der Urheber der Technologie zum digitalen Signieren von PDFs ist, sondern seine Acrobat-Programme auch den de-facto-Standard für PDF-Programme darstellen, wird im Falle einer juristischen Auseinandersetzung stets die Statusanzeige in einem der Acrobat-Programme den Ausschlag geben. Daher ist in den folgenden Interoperabiltäts-Tabellen der Status die Referenz, den Acrobat anzeigt.


Ein PDF mit einer oder mehreren Unterschriften mit einem gültigen (Personen-)Zertifikat wird in den verschiedenen Kombinationen der verschiedenen Programme wie folgt angezeigt:



Die Referenz ist die mit Acrobat Reader erstellte und auch validierte Signatur; der Status ist hier erwartungsgemäß gültig. Bei vielen anderen Programmkombinationen gibt es aber bereits in diesem eindeutigsten aller Fälle Probleme. Besonders kurios: PDFpen Pro ist die Gültigkeit der mit ihm selbst (mit einem gültigen Zertifikat!) erstellen Unterschrift unbekannt.

Diese Tabelle reicht eigentlich bereits, um alle Programme außer Acrobat Reader und Foxit PDF Editor als unbrauchbar für digitale Signaturen anzusehen.


Nun der Fall, dass der Inhalt des PDFs (sofern beim Unterschreiben nicht gesperrt) nach dem Unterschreiben verändert wurde (PDFpen Pro konnte hier zum Erstellen nicht verwendet werden, das das Programm das Dokument grundsätzlich nach der ersten Unterschrift sperrt):



In diesem Fall sollte der Stand des Dokuments zum Zeitpunkt der Unterschrift abrufbar sein; das schafft ausschließlich der Acrobat Reader. PDFpen Pro behauptet explizit, das Dokument sei überhaupt nicht verändert worden. Foxit PDF Editor erkennt zwar korrekt den Sachverhalt, zeigt den Stand des Dokuments zur Zeit der Signatur aber nicht an.


Wird ein für PDF-Unterschriften nicht zugelassenes, reines Email-Zertifikat verwendet (das nur die Echtheit der Email-Adresse bestätigt, nicht aber die Echtheit der Identität des Unterzeichners), sind sich zumindest 3 Programme einig:




Eine Signatur mit einem abgelaufenen Email-Zertifikat ist mit 3 Programmen (korrekterweise) gar nicht möglich (als Referenz habe ich daher in diesem Fall notgedrungen PDFpen Pro verwendet); die mit den 3 übrigen Programmen erstellten PDFs werden immerhin von 4 Programmen gleich bewertet:



Warum die Bewertung hier aber mehrheitlich Gültigkeit unbekannt und nicht etwa ungültig lautet (auch beim Acrobat Reader), bleibt schleierhaft. Möglicherweise überlagert die Tatsache, dass es sich um ein Email-Zertifikat handelt, das die Identität einer Person in keinem Fall eindeutig festzustellen erlaubt, den schlichten Sachverhalt, dass das Zertifikat abgelaufen ist. Ein abgelaufenes Personen- (und nicht nur Email-)Zertifikat stand zum Test leider nicht zur Verfügung.


Foxit PDF Editor erlaubt keine Signatur mit einem selbstsignierten Zertifikat, alle anderen Programme schon:



In der Bewertung der Gültigkeit sind sich hier fast alle Programme einige; nur Wondershare PDFelement Pro haut völlig daneben (tat dies ansatzweise aber bereits auch in den anderen Tests).



Das war’s. In Bezug auf etliche Details habe ich, damit der Text nicht zu sehr ausufert, die Tabellen für sich sprechen lassen; wenn etwas unklar ist, bitte nachfragen.

Auch wenn ich von der Thematik derzeit nicht betroffen bin, möchte ich dir ein herzliches Dankeschön dalassen. Ich habe den Ursprungsthread gelesen und einen Eindruck davon bekommen, wie mühselig es gewesen sein muss, das alles auszutesten und zusammenzutragen.

Auch von mir ein herzliches Dankeschön! Ich fürchte nämlich, dass das Problem in Bälde auf mich zukommt.

Nun habe ich also Adobe Acrobat Reader - aufgrund der Einschränkungen von PDFpen Pro, wie von Weia ausführlich und hervorragend dargestellt 👍🏻 - wieder installiert.
Hier der Download-Link zu allen Versionen . Den Download habe ich über Firefox durchgeführt, da bei mir die Seite in Safari nicht funktioniert.

Adobe installiert in LauchDaemons:
com.adobe.ARMDC.Communicator.plist
com.adobe.ARMDC.SMJobBlessHelper.plist

und in LauchAgents:
com.adobe.ARMDCHelper.cc24aef4a1...420d.plist

Nun möchte ich keine Hintergrundprozesse von Adobe, so lange Adobe nicht läuft. Nach dem Beenden läuft bei mir weiterhin AdobeCRDaemon im Hintergrund. Zudem ist das ein Intel-Prozess, was auf einem M1-Mac auch unschön ist.

Folgender Terminalbefehl stoppt den Hintergrundprozess AdobeCRDaemon:
sudo launchctl stop /Library/LaunchAgents/com.adobe.ARMDCHelper.cc24aef4a1...420d.plist (richtigen Dateinamen ergänzen)

Die LaunchDaemons werden bei jedem Update neu installiert, wenn ich diese deinstalliere. Ist deaktivieren eine bessere Lösung und wie funktioniert das?

Ob Deaktivieren die Neuaktivierung nach einem Update verhindert, weiß ich jetzt nicht, aber der Befehl müsste sinngemäß (nicht getestet) lauten:

Ohne sudo davor hat es geklappt. Mal sehn, was beim nächsten Update passiert.

Betreff: Update-Verhalten von Adobe Acrobat Reader

Adobe vermeide ich ansonsten, da Adobe überall im System seine Dateien verstreut und selbststartende Programme installiert.
Soeben habe ich Adobe Acrobat Reader auf die Version 21.011.20039 aktualisiert und wollte mal genauer hinschauen, was wieder für ein Mist installiert wird.

Die Datei com.adobe.ARMDCHelper.cc24aef4a1...420d.plist habe ich zuvor, wie oben dargestellt deaktiviert und in ein neues Unterverzeichnis names "AdobeDisabled" verschoben.

1. Update-Fehlversuch
Da ich den Adobe Updater deinstalliert hatte (die Package Datei mittels uninstallpkg), habe ich aus Adobe Acrobat Reader heraus das Update manuell angestoßen. Adobe wollte zwei Dateien in LaunchAgents installieren, was ich mit BlockBlock verhindert habe. Danach ging nichts mehr weiter.

2. Versuch - erfolgreich
Update als dmg heruntergeladen und installiert - dauert, aber kein Problem.

Das Interessante ist nun, dass der oben genannte LaunchAgent auch nach dem Update im Unterverzeichnis AdobeDisabled verbleibt und somit dauerhaft deaktiviert ist.

Auch wenn das Thema digitale Signaturen nicht ganz mein Beritt ist
und ich eher auf der Suche nach einer Acrobat-Alternative für die Druckindustrie bin,
so gehört doch Weia ein großes Lob und Dank für die Mühe und Aufklärung welche er betreibt.
Mal ganz abgesehen von der aufgebrachten Zeit => Danke Weia

Die Diskussion in dem parallelen Thread PDFs digital signieren – eine Anleitung hat ergeben, dass ich in der Übersichtstabelle einen Aspekt nicht gebührend berücksichtigt habe: die Long Term Validation (LTV). Signaturen müssen LTV-fähig sein, um auch nach dem Ablaufdatum eines Zertifikats noch als gültig anerkannt zu werden, solange sie während der Gültigkeitsdauer des Zertifikats erstellt wurden. Dazu war der Zeitstempelserver gedacht, der Letzteres beglaubigen konnte.

Zwar hatte ich in der Tabelle bereits aufgelistet, ob die verschiedenen Programme Zeitstempelserver nutzen können, dies aber fälschlicherweise für eine zusätzliche, zwar nette, aber nicht zwingend erforderliche Fähigkeit gehalten, da der Acrobat Reader mittlerweile auch ohne Zeitstempelserver vermittels eines neuen, anderen Verfahrens LTV-fähige Signaturen erstellen kann, die mutmaßlich auch überall anerkannt werden.

Das kann aber, wie sich herausstellte, nur der Acrobat Reader. Qoppa PDF Studio 2021 kann das nicht einmal mit Zeitstempelserver und die übrigen Programme können das ohne Zeitstempelserver jedenfalls nicht, können aber auch keinen Zeitstempelserver verwenden. Damit bleibt nur der Acrobat Reader als zuverlässig LTV-fähig übrig. Da die LTV-Fähigkeit ein unabdingbares Kriterium ist (wer will schon Unterschriften, die nach wenigen Jahren ihre Gültigkeit verlieren?), ist die um LTV-Fähigkeit ergänzte Spalte Zeitstempelserver unglücklicherweise jetzt fast vollständig rot; der Acrobat Reader steht allein auf weiter Flur:



Nach wie vor wäre der Foxit PDF Editor die beste Alternative, aber auch er ist zur Zeit wegen der fehlenden LTV-Fähigkeit unbrauchbar. Die Windows-Version des Foxit PDF Editors kann Zeitstempelserver verwenden; es bleibt zu hoffen, dass Foxit auch die Mac-Version bald um diese Fähigkeit ergänzt.

Es gibt möglicherweise einen weiteren PDF-Editor: LibreOffice.

In ein PDF lässt sich eine Signatur einfügen. Für die Verwaltung der Signaturen gibt es das NSS Tools certutil

In den Einstellungen von LibreOffice sieht das wie folgt aus (7.2.5.2 ARM64). Es lässt sich sogar ein TimeStamp-Server angeben.
Weiter habe noch nicht nachgeforscht.



Ein signiertes PDF erkennt LibreOffice nicht als gültiges Zertifikat. Vermutlich muss ich erst diesen Zertifikatmanager aktivieren.

Hm, das sieht aber so aus, als sei das überhaupt nicht in die macOS-Schlüsselbundverwaltung integriert und zudem nur für in LibreOffice erstellte Dokumente verwendbar. Das wären dann schon erhebliche Einschränkungen.
Dann mach mal.

Die elektronische Signatur bekomme ich in LibreOffice nicht ans Laufen.
Es scheitert daran, dass ich den Certificate Path nicht so angeben kann, dass LibreOffice die Schlüsselbundverwaltung von Firefox nutzt. Dort ist mein Zertifikat hinterlegt.

Ansonsten:
D-Trust gehört zu den unterstützen Zertifikaten
AdES-compliant (advanced digital signature)
Es sollte für PDFs funktionieren - das ist keine Funktion speziell für LibreOffice-Dokumente
In Firefox gibt es hier eine Dokumentation (funktioniert nicht in Safari)
file:///Applications/LibreOffice.app/Contents/Resources/help/en-US/text/shared/guide/digital_signatures.html?&DbPAR=SHARED&System=MAC

Zu einem in Adobe signiertem PDF bekomme ich folgende Meldung. Das wird aber an meiner mangelnden Implementation liegen.