pc_henning schrieb am 07.06.2017 07:42:
Unsere höchste Priorität ist sicherzustellen, dass GnuPG auch in Zukunft gewartet wird. Dazu gehört das Reagieren auf Fehlerberichte, Sicherheitsprobleme zu beheben und mit dem neuesten Stand der Kryptographie mitzuhalten.
Das ist aber auch wieder so ein Henne-Ein-Problem: Wenn GnuPG nicht so fürchterlich viel komplizierter und komplexer wäre als es das gute alte PGP 2.6 jemals war, würde es auch weniger Fehler und Sicherheitsprobleme geben.
Und was den "neuesten Stand der Kryptografie" angeht - genau diese Segnungen sind es, die mich an gpg teilweise am meisten stören.
Jede neue Empfehlung der NSA wird dort immer sofort eingebaut, weil es gerade hipp und trendy ist.
Anstatt dass man lieber ein paar Jahre zuwartet und erst einmal beobachtet wie gut die neuen Algorithmen ein paar Jahre später noch aussehen, wie es bei Sicherheitsthemen eigentlich angeraten wäre.
Klar, wenn bestehende Algorithmen irgendwann geknackt werden oder als unsicher gelten, wie MD5 oder SHA-1, dann mĂĽssen die Autoren darauf reagieren.
Aber so etwas kommt nur äußerst selten vor.
Hingegen kamen eine ganze Latte verzichtbarer Crypto-Algorithmen seit der PGP2.6-Zeit hinzu.
Darunter auch solche Perlen wie CAST5, ĂĽber welches schon Bruce Schneier schrieb "I don't buy the design process".
Oder die DSA-Unterschriften, welche den private Key leaken können, wenn nicht genug Entropie für den Zufallszahlengenerator zur Verfügung steht und der Angreifer Zufallszahlen vorhersagen kann.
Das soll jetzt aber keine spezielle Kritik an GnuPG sein, sondern ist eher den "kommerziellen" PGP-Versionen am PGP5 anzulasten, an denen sich GnuPG als "Nachfolger" historisch orientieren musste.
Nichts desto trotz, diese Altlasten sind ärgerlich, und ihr Vorhandensein verwirrt Anwender zusätzlich wenn sie Crypto-Algorithmen aussuchen wollen.
Aber das sind nur Nebenaspekte.
Meine eigentliche Kritik an GnuPG bleibt seine immer stärker überbordende Komplexität und seine umständliche Bedienung aus der Kommandozeile.
Gnuk
Das Gnuk Sicherheitstoken besteht komplett aus Freier Software. Auch das Hardwaredesign, entwickelt von Niibe, ist frei verfĂĽgbar.
Danke für diesen Hinweis; davon hatte ich bislang noch nie etwas gehört.
Hört sich aber sehr interessant an, weil nach so etwas habe ich grundsätzlich schon immer gesucht. Ich werde nachher gleich zu diesem Thema googeln.
Unter der Annahme dass es sich dabei um etwas nützliches handelt, wäre eine Integration mit GnuPG natürlich grundsätzlich wünschenswert.
Allerdings würde ich die Finanzierung solch einer Entwicklung eher als ein eigenständiges Projekt betrachten, denn einem reinen Benutzer der Software bringt solch eine Integration keinen Nutzen, wenn sie nicht ebenfalls die dazu nötige Hardware kaufen wollen.
Davon abgesehen hat GnuPG ohnehin schon SmartCard-Support, und daher wundert mich dass man noch groĂźartige Erweiterungen fĂĽr ein weiteres Crypto-Token braucht.
Man sollte meinen, alle erforderlichen Schnittstellen würden schon existieren, und man bräuchte nur einen Software-Adapter bzw. "Treiber" für die neue Hardware zu entwickeln.
Das aber wĂĽrde ich klar im Verantwortungsbereich der Entwickler der neuen Hardware ansehen, und nicht als Job der GnuPG-Autoren.
Auf jeden Fall: Separate Finanzierung fĂĽr solch ein Projekt! Typischer Weise mittels Crowdfunding.
Wir möchten die Dokumentation verbessern. Insbesondere arbeiten wir an einem Buch mit dem Titel An Advanced Introduction to GnuPG
Soll man darĂĽber jetzt lachen oder weinen?
Erst machen sie eine so schlechte man-Page dass man darin vieles nicht findet und erst durch Ausprobieren - vielleicht - drauf kommt wie es funktioniert.
Und anstatt die man-Page zu verbessern, wollen sie jetzt ein Buch heraus bringen?
Obwohl, GnuPG ist mittlerweile so sinnlos komplex geworden, damit kann man vermutlich eine ganze BĂĽcher-Reihe fĂĽllen, wenn man es drauf anlegt.
Fragt sich nur, wer Lust hat solche BĂĽcher zu lesen, bloĂź weil die man-Page schon fĂĽr die grundlegendsten Dinge wie das Selektieren der Crypto-Algorithmen nicht ausreicht?
Mir wäre eine drastische Abspeckung von GnuPG, und auch seiner man-Page jedenfalls deutlich lieber.
Größeres Ökosystem
Genau davor graut mir. Alles noch größer, noch komplizierter.
Die GnuPG-Autoren sollten sich auf die Kernfunktionalitäten beschränken, und den Rest des Ökosystems den anderen Autoren überlassen welche die entsprechenden GUI-Apps implementieren.
Die meisten Leute nutzen GnuPG nicht direkt, sondern durch Werkzeuge und Plugins.
Und das liegt wohl auch daran dass die Bedienung in der Commandline so kompliziert und umständlich ist, dass nur die wenigsten Lust haben gewohnheitsmäßig so zu arbeiten.
Das Ding hat einfach viel zu viele Optionen, und niemand tippt sich gerne die Finger wund wenn er gpg mal eben schnell aus der Commandline aufrufen will.
Da schreibt man sich dann schnell seine Wrapper-Scripte, und ... schon nutzt man "GpuPG nicht direkt", genau wie oben beklagt/festgestellt.
zu verbessern. Insbesondere möchten wir sicherstellen, dass das GPG-Plugin für Apple's Mailprogramm (GPGTools) mit jeder neuen Version von macOS funktioniert.
Ohhhh, dafĂĽr wĂĽrde ich natĂĽrlich extra-gerne spenden!
Damit proprietäre ClosedSource-Software funktional aufgewertet wird, und besser mit OpenSource-Software konkurrieren kann!
Dabei wäre es gerade bei Apple garantiert kein Problem, ein separates Crowd-Funding aufzustellen.
Apple-Benutzer sind ja mehr als alle andere bereit, für jeden Blödsinn extra zu bezahlen.
Da sollte es eigentlich kein Problem darstellen sie dazu zu bringen, auch einmal fĂĽr etwas *sinnvolles* Geld auszugeben.
Grad der letzte Block erklärt auch sicherlich, warum es so viele Features gibt ...
Aber man kann natĂĽrlich auch einen Roman schreiben und Stimmung gegen machen. Ist ja eh einfacher....
Wenn du es kürzer haben willst: "Komplexität ist der Tod von Sicherheit".
Selbst wenn man alle anderen Argumente als irrelevant betrachtet, dieses ist es nicht.
gpg ist viel zu fett. Zu viele Optionen, und einige davon (wie --no-use-embedded-filename) sind eigentlich nicht wirklich optional sondern vielmehr nötig um Sicherheitslecks zu vermeiden.
Statt noch fetter, mĂĽsste gpg daher eher dringend *verschlankt* werden!