staging.inyokaproject.org

Hallo xUbuntu User
Ich habe mir Evolution installiert und das gefällt sehr gut bis auf eine Ausnahme:
Die Implementierung der Sicherheit bereitet grosse Probleme: Ich habe 4 verschiedene Mailkonten, die alle einen eigenen Sec und Pub Key haben. Diese Schlüssel sind in einem Dir jeder mit separater Kennung xxxx_full-secret.asc und xxxx_pub.asc abgespeichert. Diese xxxx_full-secret.asc Schlüssel Kennungen habe ich in Evolution als Fingerprint angegeben. Genau das gleiche konnte ich im Thunderbird auch machen, nur konnte ich da die Schlüsseldatei Datei importieren und das hat TB offensichtlich richtig gemacht. Die Überprüfung mit Seahorse wie auch mit Kleopatra zeigt die gleichen Schlüssel Kennungen als certified an.

Nun habe ich Probleme mit Evolution der teilweise die Email nicht verschicken kann. Folgende Fehlermeldungen treten auf:
Verfassen der Nachricht gescheitert.

1
2
3

Möglicherweise müssen Sie Ihre E-Mail-Einstellungen ändern.
Detaillierte Fehlermeldung: Ausgabe von gpg2:
gpg: übersprungen "63B3": Kein geheimer Schlüssel

Das ist aber ein geheimer Schlüssel

Das gleiche mit TB arbeitet einwandfrei. Nun habe ich die Befürchtung, dass der Schlüsselbund von TB und Evolution nicht das selbe sind. Im Terminal mit

1

gpg --fingerprint

werden ebenfalls die gleichen Kennungen angezeigt.

Nun zu meiner Frage wo speichert evolution die Schlüssel ab resp. was muss ich unter Sicherheit eingeben damit das auch funktioniert?

Hallo holimatic,

offenbar hast du versucht eine Mail mit gpg zu signieren, weil evolution versucht auf deinen geheimen Schlüssel zuzugreifen:

Möglicherweise müssen Sie Ihre E-Mail-Einstellungen ändern.
Detaillierte Fehlermeldung: Ausgabe von gpg2:
gpg: übersprungen "63B3": Kein geheimer Schlüssel

Das ist aber ein geheimer Schlüssel

Wie die Fehlermeldung schon sagt ist aber "63B3": Kein geheimer Schlüssel. Evolution greift auf den gleichen keyring wie seahorse oder gpg zu. Ich nehme daher an, dass du bei der Konfiguration in evolution einen Eingabefehler gemacht hast.

Wenn du in evolution unter "Bearbeiten" → "Einstellungen" → "E.Mail-Konten" dein Konto rechts auswählst und dann auf die Schaltfläche "Bearbeiten" kann im Konteneditor links unten die Schaltfläche "Sicherheit" angeklickt werden. Wenn du rechts die "OpenPGP-Schlüsselkennung" eingibst, achte bitte darauf, keine Leerzeichen zu verwenden (wie das zu Lesbarkeitszwecken manchmal gemacht wird). Statt z.B. "63B3 D232 34F5 2A70 0CA1 18FA C89C 07A2 958C C6B4" solltest du korrekterweise "63B3D23234F52A700CA118FAC89C07A2958CC6B4" eingeben.

Übrigens werden deine asc Export-Dateien nicht von evolution verwendet. Du solltest allerdings auch geeignete gpg Unterschlüssel für den Key haben. Schau deshalb z.B. in seahorse bei deinem "Eigener PGP-Schlüssel" unter dem Reiter "Details" nach, ob dein Schlüssel unter "Verwendung" auch "Verschlüsseln" und "Signieren, Beglaubigen" mit Unterschlüsseln vorhanden ist. Das hat zwar nichts mit evolution aber mit der Schlüsselgenerierung zu tun. Da du den Schlüssel aber bei TB wohl verwendet hast, nehme ich an, dass dies er Fall ist.

PS: Es ist immer hilfreich, wenn du die Versionen der verwendeten Software angibst. Also z.B. die Ausgaben von "evolution -v ; lsb_release -d ; uname -r".

shiro schrieb:

PS: Es ist immer hilfreich, wenn du die Versionen der verwendeten Software angibst. Also z.B. die Ausgaben von "evolution -v ; lsb_release -d ; uname -r".

evolution 3.36.5 Version von Software-Installation

shiro schrieb:

OpenPGP-Schlüsselkennung

Ich habe jetzt nur die ID ohne Space eingetragen und jetzt wird die Mail versendet. Anschliessend kommt aber der Fehler:

1

Nicht gesicherte digitale Unterschrift. Wird im TB so angezeigt

In Evolution wird das angezeigt.

1
2

Gültige Signatur, aber Adressen des Absenders und des Signierenden stimmen nicht überein (Guido Hollenstein <guido.hollenstein@holimatic.com>)
Verschlüsselt

TB funktioniert nach wie vor einwandfrei

Du solltest allerdings auch geeignete gpg Unterschlüssel für den Key haben. Schau deshalb z.B. in seahorse bei deinem "Eigener PGP-Schlüssel" unter dem Reiter "Details" nach, ob dein Schlüssel unter "Verwendung" auch "Verschlüsseln" und "Signieren, Beglaubigen" mit Unterschlüsseln vorhanden ist. Das hat zwar nichts mit evolution aber mit der Schlüsselgenerierung zu tun. Da du den Schlüssel aber bei TB wohl verwendet hast, nehme ich an, dass dies er Fall ist.

Alle 4 Schlüssel haben in Seahorse wie auch in Kleopatra den Eintrag Signieren, Beglaubigen, Legitimieren, Verschlüsseln.

Hallo holimatic,

die "Fehler"-Meldung beschreibt doch das Problem:

Gültige Signatur, aber Adressen des Absenders und des Signierenden stimmen nicht überein (Guido Hollenstein <guido.hollenstein@holimatic.com>)

Du verwendest ein PGP Zertifikat bei einem eMail Konto (Absender), dass mit der eMail des Signierenden (der eMail von der Person, für die das Zertifikat erstellt wurde) nicht übereinstimmt. Das Zertifikat ist technisch nutzbar, die Vertrauensstellung aber "anrüchig". Diese Aussage trifft aber für praktisch alle PGP Zertifikate zu. Ein PGP Zertifikat entspricht einem "self-signed" S/MIME Zertifikat, dem man manuell vertrauen muss. Eine Vertrauens-Infrastruktur wie bei S/MIME gibt es bei PGP nicht (in einen PGP Keyserver kann ja jeder sein Zertifikat laden). Dies ist aus meiner Sicht einer der Gründe, warum im professionellen Mail Verkehr S/MIME sich durchgesetzt hat. Im privaten Bereich kann man ja "self-signed" PGP Zertifikate nutzen.

TB kannst du als Referenz für Zertifikats-basierte Kommunikation nicht als Referenz verwenden. Immerhin gibt es wenigstens die Meldung "Nicht gesicherte digitale Unterschrift." aus. Was immer ein TB-Benutzer daraus entnehmen soll.

Prüfe daher deine PGP Zertifikate in seahorse auf exakte gleiche Schreibweise wie die des eMail-Kontos in evolution.

Nun denn, bleibe ich bei TB der tuts für meine Zwecke zur genüge und macht was ich erwarte.

Danke für die tech. Details shiro 😀

Nun ich kann jetzt in evolution alles verschlüsseln und entschlüsseln nachdem ich mein pop Konto mit imap erstellt erstellt habe. Diesem Konto konnte ich dann auch die richtige Schlüssel ID zuordnen und jetzt klappt es auch mit dem versenden.

Es gibt nur noch eine Unschönheit beim versenden:

1

Nach PGP-Schlüsseln des Empfängers wird in den Adressbüchern gesucht...

Das verstehe ich nicht und kann man das nicht abstellen oder richtig konfigurieren?

Schön zu hören, dass du evolution hinsichtlich PGP besser konfiguriert hast.

Wenn du die Meldung:

Nach PGP-Schlüsseln des Empfängers wird in den Adressbüchern gesucht...

erhältst, bedeutet dies, dass du versuchst, eine verschlüsselte Mail an einen Empfänger zu senden, von dem kein öffentlicher Schlüssel gefunden werden konnte.

Eine häufige Ursache ist, dass in gpg kein öffentlicher Schlüssel für den Empfänger importiert worden ist.

Normalerweise sucht evolution in deinem gpg-Keyring nach dem public key der Empfänger-Mail-Adresse. Wenn sie dort nicht gefunden wird, schaut er im Mail-Cache nach. Welche Adressen dort gespeichert sind, kannst du dir anschauen, wenn du unter "Bearbeiten" → "Einstellungen" → "Zertifikate" → "Kontaktzertifikate" gehst. Bevor evolution den von dir konfigurierten Schlüssel-Server (ist meistens ldap://keyserver.pgp.com, siehe auch SeaHorse → Einstellungen) abfragt, schaut es aber in deinen Kontakten (=Adressbücher) nach einem eventuell importierten Zertifikat. Evolution kann sowohl S/MIME als auch GPG Zertifikate abspeichern und bearbeiten. Siehe im Kontakteditor unter dem Reiter "Zertifikate" die Schaltflächen auf der rechten Seite.

Während der Suche auf dem LDAP Server (keyserver.pgp.com) bleibt häufig die oben angezeigte Benachrichtigung bestehen, die du durch Drücken auf "Abbrechen" beseitigen kannst, damit du das öffentliche GPG Zertifikat des Empfängers importieren kannst. Je nach deiner Vorliebe kannst du das Zertifikat mit gpg in den keyring importieren oder es in evolution bei den Kontakten ablegen.

shiro schrieb:

Schön zu hören, dass du evolution hinsichtlich PGP besser konfiguriert hast.

Wenn du die Meldung:

Nach PGP-Schlüsseln des Empfängers wird in den Adressbüchern gesucht...

erhältst, bedeutet dies, dass du versuchst, eine verschlüsselte Mail an einen Empfänger zu senden, von dem kein öffentlicher Schlüssel gefunden werden konnte.

Ich habe alle meine pub Schlüssel im Keyring das sehe ich sowohl in seahorse wie auch kleopatra

Eine häufige Ursache ist, dass in gpg kein öffentlicher Schlüssel für den Empfänger importiert worden ist.

Auch auf der Konsole sehe ich mit

1

gpg --list-keys

Alle Schlüssel aufgelistet auch die pubs an welche ich versenden will

Normalerweise sucht evolution in deinem gpg-Keyring nach dem public key der Empfänger-Mail-Adresse. Wenn sie dort nicht gefunden wird, schaut er im Mail-Cache nach. Welche Adressen dort gespeichert sind, kannst du dir anschauen, wenn du unter "Bearbeiten" → "Einstellungen" → "Zertifikate" → "Kontaktzertifikate" gehst. Bevor evolution den von dir konfigurierten Schlüssel-Server (ist meistens ldap://keyserver.pgp.com, siehe auch SeaHorse → Einstellungen) abfragt, schaut es aber in deinen Kontakten (=Adressbücher) nach einem eventuell importierten Zertifikat. Evolution kann sowohl S/MIME als auch GPG Zertifikate abspeichern und bearbeiten. Siehe im Kontakteditor unter dem Reiter "Zertifikate" die Schaltflächen auf der rechten Seite.

Während der Suche auf dem LDAP Server (keyserver.pgp.com) bleibt häufig die oben angezeigte Benachrichtigung bestehen, die du durch Drücken auf "Abbrechen" beseitigen kannst, damit du das öffentliche GPG Zertifikat des Empfängers importieren kannst.

Bei abbrechen wird der sende Vorgang abgebrochen und wird nicht versendet.

Je nach deiner Vorliebe kannst du das Zertifikat mit gpg in den keyring importieren oder es in evolution bei den Kontakten ablegen.gpg --list-keys

Hier wird dann der Kontakt auch angezeigt, aber bei Zerifikat pgp importieren und Auswahl des pub Schlüssels mit speichern wird nur PGP angezeigt und weiter nix. Beim Versuch an den Empfänger das Email zu verschicken wiederholt sich der selbe Vorgang.

Hier wird dann der Kontakt auch angezeigt, aber bei Zerifikat pgp importieren und Auswahl des pub Schlüssels mit speichern wird nur PGP angezeigt und weiter nix. Beim Versuch an den Empfänger das Email zu verschicken wiederholt sich der selbe Vorgang.

Ja, ein importiertes öffentliches Zertifikat wird nur als "PGP" angezeigt. Das ist korrekt.

Was mich irritiert ist, dass du dann die verschlüsselte Mail nicht versenden kannst. Ich habe mir die alte 3.36.5 Version installiert um dein Problem nachvollziehen zu können. Dann habe ich für eine meiner eMail-Adressen, für die ich kein PGP Zertifikat hatte, ein Zertifikat erstellt.

 gpg --generate-key
 gpg -k
...
pub   rsa3072 2022-01-31 [SC] [verfällt: 2024-01-31]
      99EBD025ABE174D22468963096D0E1ADCB8BADEB
uid        [uneingeschränkt] ...
sub   rsa3072 2022-01-31 [E] [verfällt: 2024-01-31]

Unter evolution habe ich dann eine PGP encryptete Mail an die Test Adresse geschickt. Es kam die Meldung Nach PGP-Schlüsseln des Empfängers wird in den Adressbüchern gesucht... aber nach einigem Warten wurde die Mail verschickt. Unter evolution konnte ich sie lesen, da ja das private Zertifikat bei mir im GPG-Keyring war. Mit einem anderen eMail-Client, der das öffentliche Zertifikat nicht hatte war nur als der Anhang der verschlüsselte Text vorhanden. So sollte es ja auch sein.

Ich habe dann das pub Zertifikat exportiert

gpg --export 99EBD025ABE174D22468963096D0E1ADCB8BADEB >test-pub.pgp

und die Datei dem Testaccount als PGP Zertifikat zugefügt. Ergebnis war, dass beim Versenden der verschlüsselten Datei die Nach PGP-Schlüsseln .. Meldung nicht mehr kam.

Mir fällt grad ein, dass evolution keine GPG1 Zertifikate unterstützt. Eventuell wäre das noch bei dir zu prüfen. Sonst versuch mal den gleichen Ablauf, den ich beschrieben habe. Sollte der Fehler immer noch bestehen, wäre sinnvollerweise das evolution-Engineering einzuschalten. Da deine SW Version aber schon etliche Jahre alt ist, wird man da keinen Support mehr bekommen. Bei den aktuellen Ubuntu Distributionen (z.B. 21.10) ist evolution 3.40.0 dabei. Bei Flatpak bekommt man aber auch 3.42.3, die dann unterstützt werden.