Das war mir neu, dass man die händisch bauen muss.
Bislang liefen seit nach v78 eigentlich alle TB-Updates ohne Auffälligkeiten durch. Glaube ich zumindest....
Beiträge von wicki_w
-
-
Zitat
Soll das heißen, dass bei dir in der Version TB/115.x (unter Linux Mint) die externe Verwaltung von geheimen Schlüsseln ohne Änderungen von Präferenzen funktioniert hat bzw. auch nach dem Mint-Update heute noch funktioniert? Erstaunlich!
Das kann ich in zwischen nicht mehr genau sagen - aber ich denke schon, dass in den vergangen 2 Jahren mal Updates durchgelaufen sind - und hätte danach PGP nicht mehr funktioniert, dann wäre mir das aufgefallen.
Aber ich werde das nochmal explizit testen.
Und stimmt: mit dem "smartcard-link" scheint es doch noch zu funktionieren.
thx
Wicki
Nachtrag: so wie es aussieht, läuft es mit der Version 128 doch nach einem Update - Aber mail.openpgp.allow_external_gnupg wird nicht übernommen sondern muss nachträglich wieder auf true gesetzt werden. Dann sind priv./pub-Keys wieder funktionsfähig.
-
Hi zusammen,
ein Mint-Update auf 22 hat mir eine neue TB-Version beschert, die als "Benefit" mal wieder ein völlig neues PGP-handling mit sich bringt.
Das ist ziemlich ärgerlich - ist man aber inzwischen ja gewohnt. Um weiter externe PGP-Keys nutzen zu können, bin ich erst mal wieder auf Ver. 115 zurück. Denn ich habe keine Möglichkeit gefunden, weiter externe Keys nutzen zu können, ohne die Keys zu importieren. Aber auch das Importieren funktioniert nicht. Es kommt die sehr informative Fehlermeldung
"! Fehler: Datei konnte nicht importiert werden"
Auch "CTRL-shift-j" erläutert den Error nicht weiter.
Das ist aber auch nicht schlimm - denn ich will gar keinen Key importieren, der dann irgendwo im TB abgespeichert wird und ohne Passworteingabe genutzt werden kann.
Ist das jetzt wirklich so gewollt, dass es nicht mehr möglich ist, das externe PGP zu verwenden?
Wenn ja, gibt mir das doch einigermassen zu denken. Vielleicht übersehe ich ja auch einfach nur etwas.
Wenn ich etwas übersehe, dann freue ich mich über einen Hinweis.
Munter bleiben
WickiNachtrag: mit
gpg --export-secret-key -a [insert-your-40-char-id] > private.asc
bzw.
gpg --export-secret-key -a > private.asc
wird eine importierebare Datei erzeugt. Aber TB hat dann den private-key offen herumliegen. Auch nach einen Reboot wird jede PGP-Mail sofort und ohne PW-Abfrage geöffnet. (Ein K9-Mailer auf einem Android wird überigens beim Anklicken einer solchen Mail sofot und kommentarlos beendet - aber das ist ja ein ganz anderes Thema)
-
ok, so gehts:
ZitatSOLUTION: In the account settings for "Copies & Folder" under "Place a copy in", uncheck the default "Sent folder on " and check the "Other" option, then select the Sent folder from the drop down along side. I suspect this problem is because the PlusNet setup places the Sent folder as a subfolder of the Inbox not alongside it. I am assuming the default option is not expecting this.was bleibt ist die frage: warum stellt der das eigenmächig ungebeten um ?
und
Gibt es sonst noch ein paar nette Überraschungen, bei diesem Update?
-
103.0.2 (64-Bit) Linux Mint 21 Vanessa
Warum landen gesendete Mails nach einem Update nun plötzlich ungefragt
vom IMAP-Konto des Mailservers in "Gesendet " unter "Local Folders" ?
Und wie bekomme ich die nun plötzlich aktivierte "Hierarchie-Anzeige" der Mails wieder aus?
ok - letzteres habe ich gefunden.
aber: warum macht der sowas ?
Gibt es sonst noch ein paar nette Überraschungen, bei diesem Update?
wicki
-
Statusinfo:
Der Bug wurde jetzt auf "NEW" gesetzt - und wird vermutlich demnächst öffentlich einsehbar.
Letzte Lösungsvorschläge:
----------------------
(ganz pragmatisch)
Wenn Forwarding scheitert steht das im Filter-Log .
Wenn wir die Nachricht intakt als.eml-Anhang weiterleiten,
gibt es kein Problem. Wenn die Identität so konfiguriert ist,
dass sie verschlüsselt gesendet wird, können wir stattdessen
einfach die Weiterleitung als Anhangsmodus erzwingen.
------------------
finde ich gut so.
-
Soviel zum Verständnis des ganzen Themas. Siehe #2. Dann müsstest du den Empfängern deinen geheimen Schlüssel zur Verfügung stellen.
Du kannst die Ätzerei einfach nicht lassen, was?
Da Du das Problem nicht verstehst:
Ja, der Empfänger _hat_ den Privkey!
Es geht mir darum, eine PGP-Mail an den legitimen Besitzer des Privkey per Filter weiter zu versenden.
Ein Handling, wie es auch ein klassischer .procmail macht.
TB aber macht die Mail auf, ent-PGPt sie und schickt sie dann als Klartext weiter. Das ist gruselig.
Aber dieser Thread war eigentlich nur gedacht, um über den Bugzilla-Status zu informieren.
Und der ist noch immer unverändert:
Das Problem ist bestätigt, aber nicht offiziell confirmed bzw. bewertet.
Zu Sperrung der Funktion ist dort die Fraget:
"Wie informiert man den User, dass ein Filter nicht ausgeführt wurde?"
M.e. _ist_ er (der Empfänger) informiert, wenn er eine Mail mit PGP-Attach bekommt.
Hat er den Key, dann kann er sie lesen - wenn nich, dann nich.
Sollte sich weiter etwas tun informiere ich hier.
-
Da der Bug noch nicht confirmed ist, ist der betreffende Thread auch noch nicht für alle lesbar.
If ]....]encryption enabled by default, then I agree it's a security issue.
[....]
Nun ist die Frage im Gespräch: wie handlet man das Problem?
Ein Userdialog für jede Mail wäre sinnfrei - da können ja schnell
mal 100 Meldungen lokal aufgehen.
Meine Idee wäre: dann nur eine Notice verschicken - oder besser
die gesamte Mail (encrypted ist sie ja schon) 1:1 als Attach zu versenden.
Letzteres hab ich dann mal so vorgeschlagen.
Das reisst aber vermutlich den programmtechnischen Ablauf total durcheinander.
Oder hat jemand einen besseren Vorschlag?
Wenn es eine weitere Rückmeldung gibt, dann poste ich das hier.
-
was nützt es irgendwem, wenn er meinen rechner mit irgendeinem stick bootet???
Ich schreibe dazu nichts mehr. Wenn du es immer noch verstanden hast, dann tut es mir leid. Ich hätte jemanden, der bei E-Mails auf Verschlüsselung setzt, tatsächlich etwas mehr Sachverstand zugetraut.
du hast immer ein wenig pech mit dem denken, was?
du behauptest, nur mit dem pgp-key (ohne kenntnis der passphrase) kann man pgp-mails lesen.
du kannst nicht erklären, was es irgendwem nützt, wenn er meinen rechner von einem stick bootet.
und unteststellst jemand, den du überhaupt nicht kennst, mangelnden sachverstand.
im übrigen "setze ich nicht bei emails auf verschlüsselung" - ich halte sie schlichtweg für selbstverständlich.
wie ich eine haustür statt eines vorhangs für selbstverständlich halte.
ist wirklich schön hier bei euch - ihr tut viel gutes für die menschen......
-
es bewegt sich zumindest etwas:
-------
A way for the user to shoot themselves in the foot is not necessarily a security issue. This mostly seems like a usability issue to me[......]
-----
der vorschlag lautet nun
"verschlüsselte E-Mails niemals durch Filter nach außen"
ja, wäre ich durchaus dafür.
schaun wir mal was weiter passiert
im übrigen glaube ich, dass pistolenholster, bei denen man sich bei
der benutzung sehr einfach in den fuß schießen kann, sehr schnell
vom markt wären.
und in amiland könnte sich der hersteller vor millionenschweren
klagen nicht retten....
btw: was nützt es irgendwem, wenn er meinen rechner mit irgendeinem stick bootet???
da kann er auch die platte ausbauen, mitnehmen oder kopieren - nützt ihm ebensowenig
*soyftz*
-
"Ein BIOS/UEFI-Passwort würde etwas mehr Schutz bieten,"
Ja, sicher.
Ich vergaß: Ein BIOS-Passwort schützt vor dem Kopieren des RAMs und vor Keyloggern.
".....wenn du erkennst, wie ungeschützt deine verschlüsselten E-Mails derzeit sind."
nochmal: es geht hier nicht darum, wie sicher PGP-Mails sind. Es geht darum, dass ein
TB sie nicht einfach so entschlüsslen und dann einfach so verteilen sollte.
VE: zitat aus dem linkv on dir:
"The problem is that it is no longer possible to decrypt an email to a folder as Enigmail did very well."
nuja, damit ist es doch klar: das ist gar kein Bug! Das ist ein Feature!
Ich bin jetzt raus hier - sollte sich was neues ergeben von Bugzilla meld ich mich wieder...
-
"Wenig hilfreich"
Ist wohl die passende Umschreibung für die Richtung, in die dieser Thread nun abdriftet.
Aber seis drum:
Ohne Passhrase nützt einem der Key nichts.
Ram-Dumpen geht nicht ohne Root-Access, Keylogger-install auch nicht.
(ja, kann man alles umgehen, wenn man wirklich will. s.u.)
Rechner klauen geht immer. Bei Home im externen Luks hat man nicht
mehr als Hardware geklaut.
Dennoch : 100%ige Sicherheit gibts nicht. Trotzdem sollte man nicht
alle Türen durch Vorhänge ersetzen. sprich: PGP_mails nicht TB-Filter forwarden.
Was nicht sein _darf_:
dass ein nichtmals böswilliger Laie genau das unbewusst/ungewollt tun kann.
-
Das ist es für mich und hoffentlich die meisten Mitlesenden keinesfalls. [...]und das auch andere meine mails an meinem TB lesen ist völlig normal.
Wir sollten dann aber bitte die Schwere des Bugs im Verhältnis einordnen. Er ist in deinem Fall komplett vernachlässigbar, wenn du anderen Zugriff auf deinen Rechner gewährst.
Es gibt da so etwas zwischen sich nahestehenden Personen, dass sich "Vertrauen" nennt.
Und solche vertrauten Menschen, die dürfen sicher auch meine Mailer benutzen.
Und es gibt z.b. auch Konstellationen von gemeinsamen Mailaccounts, die mit einem
allen Teilnehmern bekannten Key und Passphrase arbeiten.
Es geht halt nur darum: die Mails sollen nicht unverschlüsselt auf dem Server irgendeines
Mailproviders liegen. (Denn was damit z.B. bei Google passiert, das wissen wir ja alle - hoffe ich)
Genau das passiert aber, wenn einer aus der Nutzergruppe sich eine Weiterleitung zwecks
Notify einrichtet. Wodruch dann dieser Fehler auffiel.
Und das musst Du mir jetzt mal erklären:
Wie kommst Du ohne die Passphrase zu kennen an die Inhalte von PGP-Mails?
Wo findet man diese Tools im Internet? Mir ist keins bekannt, dass das in vertretbarer Rechnzeit schaffen würde.
(ok, ich hab auch nicht danach gesucht, weil ich eben _nicht_ die Atomkoffercodes der USA verwalte...)
-
Also das mit dem "Rechner sperren", das sehe ich auch nicht als so
sehr wichtig an.
Das ist mir unverständlich. Jemand der Zugriff auf deinen Rechner bekommt, kann sich alles abziehen, was er möchte. Und das ist dir nicht so wichtig? Das kann ich mir gar nicht vorstellen.
wir sollten das nicht so zerreden. jeder hat seine individuellen prioritäten.
und das auch andere meine mails an meinem TB lesen ist völlig normal.
dass sie aber eine weiterleitung von PGP-mails einrichten könnten
(habs ausprobiert: dauert 10 sekunden) und diese mails dann
unbemerkt und unverschlüsselt irgendwohin gehen können, das
ist nicht normal.
und das sollte behoben werden.
-
Wer nicht einmal den eigenen Rechner bei Verlassen konsequent sperrt...
Also das mit dem "Rechner sperren", das sehe ich auch nicht als so
sehr wichtig an. Es geht nicht um die Codes von Putins oder Bidens Sprengköpfen....
Ich möchte nur nicht, dass jeder, der mal an den TB ran kommt, dann auch gleich
alle PGP-Mails lesen und versenden kann.
Das geht ja auch (nach bisherigem Kenntnisstand) nicht.
(Wenn man Timeout für die Passphrase kurz genug setzt)
Aber die Einrichtung eines Filters zur Weiterleitung, die ist möglich auch ohne
PGP-Key/Passphrase.
Und wenn die Weiterleitung einmal drin ist, dann merkt der Anwender das nicht.
So lange er nicht aktiv danach sucht. Und alle Mails werden dann unverschlüsselt
weiterlgeleitet.
-
Sending the message with encryption might not be possible. This means that a filter action could fail for some messages. How would we handle that?
Ich habe den Eindruck, sie haben das Problem noch nicht ganz verstanden.
.....
Wenn ein Anwender 'Verschlüsseln + Signieren' vorgegeben hat und das ohne Probleme möglich ist, hat TB das auch so umzusetzen – ohne Wenn und Aber!
Ja, so sehe ich das auch - und so sollte das jeder sehen.
Ich habs nochmal in Bugzilla erläutert.
Denn ich brauche ja nur 1 Minute zugang zu dem TB-Mailer des Users
um einen Filter einzurichten und bekomme dann _alle_ seine PGP-Mails
unverschlüsselt als Klartext - und der User merkt _nichts_ davon.
Sowas darf nicht sein.
-
Dass sicherheitsrelevante Bugs nicht für jeden einsehbar sind, ist ganz normale Praxis.
So ist es.
Ich hatte allerdings damit gerechnet, dass das innerhalb von 5 Tagen zumindest mal confirmed wird.
Ist ja kein sonderlich kompelxer Versuchsaufbau dafür nötig.
In der Bugmeldung steht das gleiche drin wie hier am Anfang dieses Threads.
oh, ich seh grad:
status ist immer noch UNCONFIRMED. aber es ist ein reply da:
doch an der Stelle hab ich erst mal aufgehört zu lesen.
und eine Schachtel Valium eingeworfen:
"I agree it's not ideal. But I'm not sure it's a security issue,"
das ist was für morgen.....
Thanks for your report.
I agree it's not ideal. But I'm not sure it's a security issue, because it's the user's own's decision and action that triggers the forwarding.
I'd agree this problem as an incomplete implementation that doesn't warn the user about all possible, potentially problematic consequences of configuring automatic filter actions.
Fixing the scenario you describe will have larger consequences, I think.
Sending the message with encryption might not be possible. This means that a filter action could fail for some messages. How would we handle that? A filter could run on many messages, so it isn't as simple as showing a popup for each failure. We'd have to ensure the user can learn about all failed filter actions.
I think this is a difference from today, because today all filter actions are expected to always succeed, right?
--------
-
Ich kann den Fehler ebenfalls bestätigen, auch, dass das schon ein "dicker Klopfer" ist.
schön, dass wir mal einer Meinung sind
bugzilla sieht das wohl anders:
UNCONFIRMED
krass.... -
Außerdem taucht im Thema 'Linux + PGP' auf – das schränkt den Kreis der interessierten Leser schon mal stark ein.
Unter Win haben wir das noch getestet - aber ich gehe davon aus, dass es dort genauso sein
wird.
• 23 hours ago - UNCONFIRMED
"Die meisten sind doch mit der 'Bug-Inflation' der 102.* Version beschäftigt …"
Vielleicht sollte ich mal nachsehen, ob es eine aktuelle Version von "Pine" gibt.... -
.... Dort ist die Timeoutzeit auf 60s eingestellt, was dazu führt, daß bei eingehenden verschlüsselten Mails in der Regel immer nach der Passphrase gefragt wird – unabhängig von einem Masterpasswort in TB.
...
Die Weiterleitung im Klartext erfolgt übrigens unabhängig davon, ob man für die Weiterleitung 'Eingebunden' oder 'Als Anhang' konfiguriert hat.
Ta, das ist schon ein ziemlicher Klopfer - und ich hätte erwartet, dass bei den Supportern
sofort der Alarm an geht. Aber der Status ist noch immer "UNCONFIRMED".
Aber auch hier im Forum scheint das kaum jemand irgendwie zu berühren...
Und wenn jemand keinen Agent verwendet und ein Masterpasswort eingegeben hat,
dann macht der TB das ganz von alleine - und man bekommt nichts davon mit.
Es sei denn, man hat das Filter-Log eingeschaltet und schaut da ab und zu mal rein.
Ich finde das echt gruselig.
