Willkommen im User-Forum von mailbox.org
 

Enigmail: Kein MDC - keine Entschlüsselung

5860633 hat dies geteilt, 14 Monaten her
gelöst

Ich nutze Enigmail 2.0.5 mit Thunderbird 52.8.0 auf Ubuntu 16.04.04LTS.

Es gab kürzlich ein unvermittelt auftretendes Problem bei der Entschlüsselung von Mails, die von mailbox.org über POP3 heruntergeladen werden. Fehlermeldung:


Fehler - Nachricht enthält keinen Integritätsschutz (MDC)


Das konnte man zunächst zumindest umgehen durch Angabe entsprechender Kommandozeilenparameter für gpg. Seit Enigmail 2.0.5 wird dieser Workaround nun scheinbar absichtlich ultimativ verhindert. Diese Nachrichten sind nicht mehr im Mail Client zu entschlüsseln, bestenfalls noch manuell auf der Kommandozeile.


Ich verstehe die Hintergründe nur teilweise. Meine Fragen wären: Hat das was mit mailbox.org zu tun? Wer müßte tätig werden? Wie komme ich aus der Nummer lebend wieder raus?


In meinem Account bei mailbox.org nutze ich das verschlüsselte Postfach.

Kommentare (48)

Foto
1

Ist für den verwendeten Key MDC aktiviert?


gpg --edit-key <user-id>

gpg> showpref

Foto
1

gpg> showpref

[uneingeschränkt] (1). Vorname Name <irgendwas@mailbox.org>

Verschlü.: AES256, AES192, AES, 3DES

Digest: SHA256, SHA1, SHA384, SHA512, SHA224

Komprimierung: ZIP, nicht komprimiert

[uneingeschränkt] (2) Vorname Name <irgendwas@mailbox.org>

Verschlü.: 3DES

Digest: SHA1


Komprimierung: ZIP, nicht komprimiert


Die Schlüssel wurden von mailbox.org bei der Aktivierung von Guard erzeugt, oder so.

Foto
1

Hmm, all meine lokal erstellten Keys zeigen "Features: MDC, Keyserver no-modify". Welche GPG Version verwendest du?


GnuPG 2.2.7 hat die Option:


--ignore-mdc-error This option changes a MDC integrity protection failure into a warning. This can be useful if a message is partially corrupt, but it is necessary to get as much data as possible out of the corrupt message. However, be aware that a MDC protection failure may also mean that the message was tampered with intentionally by an attacker.


Mann müsste sich mal das git/ChangeLog genauer anschauen.

Foto
1

Die beiden Optionen --ignore-mdc-error und --no-mdc-warning hatte ich verwendet. Das ist genau der Workaround, den ich eingangs erwähnt hatte. Das hat aber nur wenige Tage funktioniert. Mit dem Upgrade von Enigmail auf 2.0.5 wurde das unterbunden. Im Enigmail Forum gibt es dazu mehrere Diskussionen mit dem Entwickler. Das Problem an sich ist klar: MDC sollte immer verwendet werden, Enigmail verweigert jetzt die Entschlüsselung, wenn nicht. Aus Sicht der Sicherheit mag das richtig sein.


Aber ich frage mich, wie auch mehrere andere Nutzer, wie kriege ich meine alten Mails ohne MDC entschlüsselt.


Und warum fehlt MDC bei Nachrichten, die über das verschlüsselte Postfach bei mailbox.org laufen?

Foto
1

Schon mal mit einer nightly Version von Enigmail bzw. einer älteren Version probiert? Oder mutt und gnupg. Enigmail verwendet openpgp.js, oder? 3.0.9? In 3.0.1x scheint es einen Fix zu geben.

Zur zweiten Frage bekommen wir hoffentlich eine Stellungnahme von mailbox.org. Vielleicht macht es einen Unterschied, wenn man die Keys mit gnupg selbst erstellt und dann hochlädt? Dann kann der Key auch länger sein (z.B. 4096 Bit)

Und hast du schon den Mailbox Support (https://help.mailbox.org) direkt kontaktiert?

Foto
1

Nein, ein Ticket habe ich noch nicht aufgemacht. Ich tendiere dazu, sowas erst mal in die Runde zu werfen, weil ja oft die Community schon Lösungen hat oder findet. Aber ich denke, das wäre einer der nächsten Schritte.

Foto
2

Wir schauen uns das nächste Woche noch einmal konkret an, aber ich habe das heute morgen erstmal als Bericht an Guard-Entwickler weitergeleitet. Ich vermute, daß Guard aufgrund irgendwelcher Default-Settings in den verwendeten Java-Bibliotheken per Default kein MDC aktiviert und da dass bislang ja stets unaufällig war, hat's halt niemand gemerkt. -Aber das läßt sich zukünftig dann ja ändern.


Wir schauen uns das nächste Woche noch einmal konkret an, aber ich habe das heute morgen erstmal als Bericht an Guard-Entwickler weitergeleitet. Ich vermute, daß Guard aufgrund irgendwelcher Default-Settings in den verwendeten Java-Bibliotheken per Default kein MDC aktiviert und da dass bislang ja stets unaufällig war, hat's halt niemand gemerkt. -Aber das läßt sich zukünftig dann ja ändern.

Foto
1

Vermutlich so in der Richtung. Danke. Und schönes Wochenende.

Foto
1

Wir haben nachstellen können, daß Guard-Keys die Flags fehlen. Das wird durch einen Patch gelöst werden.


Andererseits /sollte/ GPG beim codieren eigentlich trotzdem by default MDC einsetzen, da die Keys AES256 mit einer block size von 128 einsetzen, so daß GPG automatisch MDC anwerfen sollte (siehe oben beschriebene Doku aus dem Aufrufparameter).


Wir debuggen das noch. Unklar ist uns gerade, ob Guard vielleicht früher Keys mti anderen Ciphers erzeugt hat und das hier ein Problem alter Keys ist, das wir dann mit neuen Schlüsseln natürlich nicht nachstellen können.

Foto
1

@zapata


Also ich weiß jetzt nicht mehr ob der mail1 vom Guard erstellt worden ist aber der mail2 ist sicher von mir erstellt worden.

  1. gpg> showpref
  2. [ultimate] (1). Mail <mail1@demo.mail>
  3. Cipher: AES256, AES192, AES, 3DES
  4. Digest: SHA512, SHA384, SHA256, SHA224, SHA1
  5. Compression: ZIP, Uncompressed
  6. [ultimate] (2) Mail <mail1@demo.mail>
  7. Cipher: 3DES
  8. Digest: SHA1
  9. Compression: ZIP, Uncompressed

  1. gpg> showpref
  2. [ultimate] (1). Mail <mail2@demo.mail>
  3. Cipher: AES256, AES192, AES, CAST5, 3DES, IDEA
  4. Digest: SHA256, SHA1, SHA384, SHA512, SHA224
  5. Compression: ZLIB, BZIP2, ZIP, Uncompressed
  6. Features: MDC, Keyserver no-modify
  7. [ultimate] (2) Mail <mail2@demo.mail>
  8. Cipher: AES256, AES192, AES, CAST5, 3DES, IDEA
  9. Digest: SHA256, SHA1, SHA384, SHA512, SHA224
  10. Compression: ZLIB, BZIP2, ZIP, Uncompressed
  11. Features: MDC, Keyserver no-modify


Wie man sieht fehlt bei einem das Feature MDC. Kann es sein das der Guard das nicht beim erstellen einbaut?

Foto
1

Es ist richtig, daß die Guard-Keys kein MDC-Flag bekommen haben und derzeit laufen die Arbeiten, daß Guard mittelfristig bei seinen Keys die MDC-Flags nachpatcht.


Allerdings -- wie zu Beginn der Diskussion gepostet -- sollte das egal sein, weil GPG bei ausreichender Crypto automatisch MDC verwenden sollte.


Insofern ist nach allen Analysen hier unklar, wieso das offensichtlich unterbleibt und ob es sich ggf. um einen Bug bei GPG handelt.


Wir testen gerade, ob wir GPG enforcen können MDC zu verwenden. Das ist im Test-Setup ein paar Stunden Aufwand und wir bitten um Geduld.

Foto
1

Sollte jetzt auch kein Druck sein sondern eher zur Auflösung beitragen.

Foto
Foto
1

Ich habe exakt das gleiche Problem und kann die Emails nicht mehr lesen und nutze auch das verschlüsselte Postfach. Der gleiche Fehler kommt auch unter R2Mail2 auf Android. Ich habe stundenlang bei Google nach dem Problem gesucht und nichts gefunden, deshalb gehe ich davon aus, dass das spezifisch für Mailbox.org ist. Das ist total ärgerlich, weil meine ganzen online Bahntickets in dem Account gespeichert sind und ich diese zur Erstattung einreichen muss....

Foto
1

Das Problem habe ich ausserdem auch noch. Ich verwende auch R2Mail2 unter Android.


Und zur Klarstellung nochmal: Es geht nicht um eine Ende-zu-Ende-Verschlüsselung mit einer anderen Person, sondern um das verschlüsselte Postfach von mailbox.org. Die Schlüssel wurden von mailbox.org erzeugt und die Nachrichten, die da reingeworfen werden, werden mit diesen Schlüsseln ver- und bei mir am Client wieder entschlüsselt. Also, sollten.

Foto
Foto
1

Das muss dann mit den von Mailbox.org erzeugten Schlüsseln zusammen hängen.

Ich nutze das verschlüsselte Postfach mit einem RSA Schlüssel den ich 2014 mit Enigmail erzeugt habe.


Und bei mir funktioniert alles. Sowohl mit Enigmail 2.0.5 (Thunderbird 52.8.0) wie auch mit K9 Mail.

Foto
1

Schlüssel habe ich selbst erstellt, nicht auf mailbox.org. Das hat auch immer funktioniert, bis das Enigmail Update kam.

Foto
1

Ich habe das gleiche Problem: im Browser funktioniert mein verschlüsseltes Postfach von mailbox.org, aber mit Thunderbird kann ich die von mailbox verschlüsselten Emails nicht mehr öffnen. Interessanterweise kann ich die Emails eines gleichzeitig erstellten zweiten Postfachs in derselben Thunderbird-Anwendung lesen... Beide Schlüssel sind 2,5 Jahre alt und von Guard erzeugt.


Ich bin ratlos.

Foto
1

Also ich habe das selbe Problem, ich habe das auch schon einmal als Ticket eingesendet.

Mein Key habe ich auch selber erstellt und dann importiert, wenn mir jemand eine Verschlüsselte Mail schickt geht es ebenfalls nicht.

EIn anderes Postfach funktioniert aber komischerweise, alle Testmails kamen von der gleichen Person.

Foto
1

Hallo,


für alle Leidgeplagten zu diesem Thema habe ich einen Workaround für Thunderbird, zumindest habe ich so alle alten Mails entschlüsselt bekommen:

1. Lokalen Ordner Archiv erstellen

2. Enigmail 2.0 (vom 25.3.2018) installieren (https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/versions/)

3. Alle verschlüsselten Mails markieren und im Menü von Enigmail "Entschlüsseln in Ordner" auswählen.

4. Nun sind die Emails im lokalen Ordner entschlüsselt und können vom Server gelöscht werden.

5. Neueste Version von Enigmail installieren.

Foto
1

Ich finde die Idee die EMails unverschlüsselt abzulegen nicht so toll, aber dennoch danke für den Input.

Foto
1

Die Idee finde ich auch nicht gut. Da ich aber meine alten Emails noch brauche, war das die einzige Möglichkeit, einen einfachen Zugriff zu bekommen.


Ich habe jetzt einen neuen PGP Schlüssel generiert und das verschlüsselte Postfach damit wieder aktiviert und jetzt scheint es zu funktionieren. Technisch können natürlich die alten Mails nicht vom Server neu verschlüsselt werden.

Foto
1

Ein neu erzeugter Schlüssel funktioniert?

Ich habe 2 Schlüssel die zur gleichen zeit auf die gleiche art erzeugt wurden.

Einen für MBO und einen für ein eigenes Postfach. Der bei MBO geht nicht :(

Foto
Foto
1

Es gibt gerade die Rückmeldung der Entwickler, daß ein Bug gefunden wurde, wenn einem Schlüssel eine weitere ID zugewiesen wurde, bevor der Public Key für unsere encryptete INBOX hochgeladen wurde. In diesem Fall wurden einige Flags nicht ganz sauber "umkopiert".


Das würde bedeuten, daß nur User betroffen sind, die weitere IDs in den Schlüsseln verwenden.


Ich muß gestehen, daß mir das noch nicht ganz plausibel erscheint, weil ja in jedem Fall das MDC-Flag im Key fehlt -- andererseits, wie oben geschrieben -- sollte GPG auch ohne dieses Flag jederzeit MDC verwenden. Wir debuggen das weiterhin.


Trotzdem wäre eine Rückmeldung hier ganz hilfreich und würde uns Zeit sparen:


Sind das wirklich alles Fälle wo "advanced keys" mit mehr als einer ID im Spiel sind? Oder sind hier auch User betroffen, die nur die ganz normale Haupt-Standard-ID im Key verwenden?


Bei meinen Test-Cases mit einem nagelneuen Test-Account und nagelneu erzeugten Keys ist es mir bislang NICHT gelungen Mails zu erzeugen, die sich mit meinem Thunderbird/Enigmail nicht decodieren lassen. Sprich: Mein Test-Case zeigt die Fehler gerade nicht. Das macht es so schwer das zu debuggen. Aber ich habe wie gesagt auch noch keine weitere ID hinzugefügt...

Foto
1

Bei mir ja. Habe meine eigene Domain und die mailbox.org Domain in dem Zertifikat.

Foto
1

Bei mir auch. Ich hatte 2 IDs in dem Key. Der neue hat nur eine ID, deshalb scheint es jetzt zu funktionieren.

Foto
Foto
1

Testkandidat gesucht: Da es mir wie gesagt schwerfällt den Fall auf meinem Client nachzustellen und ich ungerne weiter Zeit verschwenden / vertrödeln würde einen Problem aufzubauen um es dann zu fixen, würde ich mich freuen, wenn sich hier kurz ein Testkandidat zur Verfügung stellt, der das Problem aktuell noch hat und mir bestätigen könnte, daß nach einer Config-Änderung bei uns die Mails für Thunderbird wieder lesbar sind.


Kurzer Ping an p.heinlein@mailbox.org wären nett, dann würde ich temporär kurzzeitigi den Change vornehmen, eine Test-Mail schicken und mich über eine entsprrechende Rückmeldung freuen.

Foto
1

Bin dabei :D

Foto
Foto
2

Wir wissen mittlerweile, warum es ein Problem (nur) bei Schlüsseln mit zwei IDs gab. Wie so immer ist die Sache... komplexer...

Unser Guard hat einen scheinbar belanglosen Bug, daß beim zusammenkopieren von zwei IDs die Flags des Keys nicht richtig gesetzt werden. Damit geht auch ein ggf. sogar gesetztes MDC-Flag verloren. Das aber ist eigentlich egal, weil GPG per Default automatisch MDC verwendet, sobald die Ciphers des Key das hergeben.

Hier ist es aber so, daß der Key dann gar keine Flags mehr hat. Darunter fehlt auch das Flag für den bevorzugten vom Schlüsselinhaber gewünschten Cipher. GPG arbeitet nun nur auf Basis von Default-Werten und hat hier (warum auch immer, erstaunlicherweise) die Default-Auswahl auf 3DES, obwohl der Schlüssel eigentlich sauberes AES256 unterstützt.

GPG verwendet dann by Default unnötig schlechte Ciphers und mit diesen ist dann am Ende kein MDC möglich.

Insofern ein Zusammenspiel verschiedener Bugs verschiedener Programme, die so bislang nie auffielen und/oder irrelevant waren und nun durch das neue Default-Verhalten in Sachen MDC zum tragen kommt.

Wie schon geschrieben werden wir die nächsten Wochen einen Fix ausrollen, der alte Keys nachträglich wieder mit richtigen Flags versieht. Außerdem testen wir eine Konfiguration mit der wir vielleicht AES256 und damit MDC erzwingen können, egal was GPG für Defaults hat. Bitte etwas Geduld.

Für Profis:

Unsere Entwicklung schreibt dazu:

Here are some steps you can give your current customers on the support board to resolve the issue for them immediately (for future incoming emails).

Make sure gpg has your key. If not, download from Guard your private key, then import into gpg

> gpg --import private.asc

then, we edit the keys

> gpg --edit-key your@email

then, we set the default preferences

gpg> setpref

You will be asked if you want the default settings. Select Y

gpg> quit

Confirm save changes

Then, export the key for uploading to mailbox

> gpg --armor --export your@email > mykey.asc

Copy the contents of mykey.asc to the encrypted inbox public key. This will fix the issue of incoming emails not having MDC. I have tested it on mailbox, and solved the issue.

Unfortunately, we can't alter previously sent emails. They can, of course, read the emails using Appsuite and Guard. Starting 2.10 (next version), we warn of missing MDC information (and remove HTML markup), but it won't fail.

Foto
3

Danke an Daniel für die schnelle Zuarbeit; er hatte sich als Testkandidat zur Verfügung gestellt.


Anhand seines Schlüssels konnten wir eben nachweisen, daß wir GPG durch einen Config-Change anweisen können, MDC zu verwenden, auch wenn keinerlei Flags im Key gesetzt sind.


Wir haben den Change eben produktiv auf allen Nodes ausgerollt, Ab sofort müßten alle nun neu eingehenden Nachrichten mit MDC verschlüsselt werden und damit auch unter aktuellen Enigmail-Versionen decodierbar sein.


Mit Blick auf alten Nachrichten ist das natürlich weiterhin etwas schwierig. Hier würde ich einerseits mal abwarten, wie sich die Diskussion bei Enigmail entwickelt. Deren Entscheidung das nun plötzlich zu blocken läuft ja nicht ganz diskussiosfrei ab und findet durchaus Kritik. Auch wir sind über dieses Vorgehen etwas verwundert.


Desweiteren haben wir Pläne in einigen Monaten ein Modul zu entwickeln, das auch ausgehende Nachrichten verschlüsselt und mit dem auch eine nachträgliche Verschlüsselung bereits gespeicherter Nachrichten möglich wäre. Wir werden die nächsten 2-3 Wochen diskutieren, ob wir die Entwicklung dieses Moduls vorziehen.

Foto
1

Kein ding immer wieder Gern, wollte ich im Ticket ja schon.

Ich mag euren Dienst sehr und helfe auch gern mit wenn ich kann :)

Auf das Modul freue ich mich auf jedenfall schon sehr.

Foto
Foto
1

Hab nur ich jetzt das Problerm, dass die Eingangsverschlüsselung obwohl der Haken gemacht ist nicht mehr funktioniert?


Ich kann auch gerade keinen anderen Public Key als verschlüsselung angeben, da der Server mit der Fehlermeldung


"Auf dem Server trat ein vorübergehender Fehler auf. Die Anfrage konnte nicht verarbeitet werden." antwortet


merkwürdig

Foto
1

Meine neu eingehenden Mails werden nicht mehr verschlüsselt.


Die letzte verschlüsselte ging um 21.34 Uhr ein, die erste unverschlüsselte um 22.20 Uhr.

Foto
1

Dann liegt das unserem Config-Change, dann muß ich den leider vorerst wieder zurücknehmen.


Wir hatten die Befürchtung, daß es bei sehr komischen alten Schlüsseln dazu kommen könnte, daß nicht verschlüsselt werden kann.


Das kann dann aber eigentlich NUR der Fall sein, wenn diese Schlüssel tatsächlich keinerlei MDC unterstützen und damit auch nicht mehr dem heutigen Stand entsprechen. Genaugenommen -- wenn ich den Zwang zu MDC wieder rausnehme, dürften diese Mails auch nicht mehr mit Enigmail & Co decodierbar sein.


Ich drehe den Change jetzt erstmal zurück. Darf ich fragen, wo/wie Ihr Eure Schlüssel erzeugt habt und/oder könnt Ihr mir Euren Public-Key zur Analyse an p.heinlein@mailbox.org zusenden?

Foto
1

Nee, Quatsch, Public-Key brauche ich nicht, den kann ich mir ja auf Systemebene holen. Allerdings machen wir jetzt erstmal Schluß und debuggen das morgen in Ruhe.


Ich hatte gehofft das heute Abend durch einen pragmatischen Schnellschuss lösen zu können, aber dann müssen wir uns das morgen noch einmal in Ruhe und gründlich in allen denkbaren Variationen anschauen.

Foto
1

Jetzt ist die Mail schon raus ;-) aber gut, Stand 22:45 kam bereits die erste verschlüsselte wieder rein. Top!

Foto
1

Also wenn ich einen Public Key eintragen möchte kommt die Meldung:

  1. Bitte prüfen Sie Ihre Mailfilter-Regeln. Diese scheinen ungültig zu sein. Antwort von Server: "Open-Xchange: line 31: error: pgp_encrypt command: invalid ASCII armor for key 1/30264696: invalid character in base64 data. Open-Xchange: error: validation failed. "

Foto
1

als Workaround für den obrigen fehler habe ich die Verschlüsselung des Postfachs deaktiviert dann den Schlüssel eingetragen und dann die Verschlüsselung wieder aktiviert. Jetzt läuft es mit dem neuen Schlüssel.

Foto
2

Dieser Fehler in den Mailfilter-Regeln tritt auf, wenn ZWEI Schlüssel gleichzeitig verwendet werden. Ist also eher selten der Fall und hat mit dem aktuellen MDC-Problem nichts zu tun.


Leider ist dieses Ticket vor einigen Wochen nach einer Rückfrage seitens OX bei uns etwas vergessen worden. Wir gingen aus, OX hat alles, die OX-Entwickler haben etwas unklar übersehen und wir hatten nicht gleich Zeit zu antworten, so daß OX auf uns wartete, wir auf OX.


Jetzt sind wir aber tagesaktuell in der Diskussion und Analyse dazu und ich rechne diese Woche hier mit der Erkenntnis zur Ursache und in zwei/drei Wochen dann hoffentlich mit einem Fix bei den nächsten Patch-Releases.


Peer

Foto
1

Dann sieht der Fehler aber eigentlich so aus:

de8618b875d04bc3924e8b15eaa22fc5


Im obigen Post stimmt mich die wahnsinnig hohe Zahl der Keys nachdenklich (1 von 30264696), vielleicht war der Fehler bei Daniel doch im Zusammenhang mit den aktuellen Problemen aufgetreten.

Foto
1

Ich verstehe die Passage "(1 von 30264696)" nicht, aber ich weiß, dass das


a) definitiv rein gar nichts mit dem aktuellen Codierungsproblem zu tun haben kann, die beiden Komponenten sind grundverschieden und sehen sich auch nie

b) das auftritt, wenn man zwei Schlüssel eingespielt hat und diese dann später vom Sieve-Modul gelesen/validiert werden.


Gebt den Developern noch die paar Tage, die sind da jetzt dran und haben alles notwendige um das nachzustellen. Für mich sieht es so aus, als ob da das Trennzeichen zwischen den beiden Keys nicht richtig vom Validator verstanden wird und der sich da (definitiv zu unrecht) aufregt. Denn der Syntax der Sieve-Datei ist ja in Ordnung.

Foto
Foto
1

Also vor dem Hotfix von Mailbox.org hat der Public Key und die Eingangsverschlüsselung ohne Probleme funktioniert.


Der Key wurde am 02.06.2015 mit Mailvelope v0.13.1 erstellt und hatte auch das MDC Flag. Da der Key auch nur aus einer ID Bestand, hätte der Fix auch nicht mein Postfach betreffen müssen.


Gerne sende ich meinen Public Key zur Untersuchung ein.

Foto
1

Mein Key ist ebenfalls mit MDC:


  1. Cipher: AES256, AES192, AES, CAST5, 3DES

    Digest: SHA512, SHA384, SHA256, SHA224, SHA1

    Compression: ZLIB, BZIP2, ZIP, Uncompressed

    Features: MDC, Keyserver no-modify

Foto
2

Wenn ich GPG2 zwinge MDC zu verwenden, streckt er alle viere von sich. Hier von Deinem Postfach:


May 30 22:35:40 dobby7 dovecot: lmtp(mail@xxxxxxx): program `/usr/bin/gpg2' terminated with non-zero exit code 2


Ich habe ja den dumpfen Eindruck, daß GPG2 hier nicht ganz sauber ist. Wir debuggen das morgen und werden ggf. die GPG-Entwickler hinzuziehen. Ein "gpg2 --force-mdc" darf jetzt eigentlich nicht zum Absturz führen wenn der Schlüssel MDC unterstützt...

Foto
1

Für dieses Postfach möchte ich noch zu bedenken geben, dass zwei Keys hinterlegt sind (1x Guard und 1x eigener), bevor das den Test unnötig verkompliziert.

Foto
Foto
3

Zwischenstand: In Rücksprache mit GnuPG-Entwickler Werner Koch haben wir nun eine top-aktuelle gnupg-Version für unsere Server vorbereitet, die -- so Werner Koch -- per Default auf AES und damit MDC gehen sollte und nicht auf die Idee kommen sollte, unnötig 3DES zu verwenden.


Allerdings werde ich die erst am Wochenende in Ruhe ausrollen können, da wir das natürlich dann testen und beobachten wollen.

Foto
1

Hört sich gut an, wenn ihr wieder wen zum testen braucht kann ich das gerne machen.

Foto
Foto
3

Wir haben heute morgen um 6 Uhr :-) neue GPG-Versionen im Cluster ausgerollt. Meine zwei Testkandidaten Daniel und 9490334 hier aus der Forendiskussion haben rückgemeldet, daß nun alles fehlerfrei und wie gewünscht funktioniert, so daß wir das soeben für alle User auf allen Hosts freigeschaltet haben.


Wir setzen nun eine ganz aktuelle GnuPG-Version ein, die -- anders als vorher -- von sich aus AES vor 3DES vorzieht und damit by default eine MDC-taugliche Verschlüsselung macht, wo immer das möglich ist, so daß es auf die Key-Flags nun gar nicht mehr ankommt.


Mittelfristig wird es in ein paar Wochen vermutlich mal eine Guard-Version geben, die die Keys im Hintergrund "repariert". Aber das ist dann für uns hier gar nicht mehr relevant.


Dank an alle, die mitgeholfen haben -- und ich hoffe jetzt, daß mir hier keiner mehr irgendeine Fehlfunktion rückmeldet. :-)