Posts by generalsync

    Vermutlich ist der Schlüssel noch in den Konten-Einstellungen eingetragen (Menü | Konten-Einstellungen). Dort solltest du für jedes Konto – und jede Identität, sofern du Konten mit mehreren E-Mail-Adressen nutzt – jeweils im Bereich "Ende-Zu-Ende-Verschlüsselung" unter der Überschrift "OpenPGP" festlegen können, welcher Schlüssel genutzt wird. Wenn du dort "Keiner" wählst, wird OpenPGP für das jeweilige Konto / die jeweilige Identität deaktiviert.


    Für die Zukunft: Ich würde stark davon abzuraten, Schlüssel zu löschen. Vielleicht willst du eine zuvor verschlüsselte Nachricht doch noch einmal lesen oder jemand sendet dir versehentlich eine verschlüsselte Mail; die Entschlüsselung funktioniert dann auch nach der Deaktivierung weiter.

    Wird das Adressbuch nur lokal gespeichert?

    Sofern du nichts explizit anders konfiguriert hast: ja.



    Kann man das "irgendwie" auf allen Rechnern synchronisieren?

    Klar. Prinzipiell gibt es dazu zwei Konzepte: entweder du synchronisierst beide Rechner mit einer zusätzlichen zentralen Stelle (z.B. ein eigener Server oder ein Cloud-Dienstleister) oder du synchronisierst deine Rechner direkt miteinander, z.B. über WLAN. In jedem Fall ist dafür ein Add-on notwendig.


    Wenn du einen eigenen CardDAV-Server betreibst oder eine entsprechende Dienstleistung in einer für dich vertrauenswürdigen Cloud gemietet hast (achte dabei auf Datenschutz – es sind schließlich nicht deine Daten!), wären das dafür nötige Add-ons TbSync oder CardBook. Letzteres bietet mehr Funktionen, ersetzt aber das normale Thunderbird-Adressbuch und ist daher inkompatibel mit anderen Add-ons und manchen eingebauten Funktionen.


    Es geht aber auch ohne Server oder Clouds: das von mir entwickelte GeneralSync (30 Tage kostenlos, anschließend können Privatkunden den Preis selbst wählen) stellt zusätzliche Adressbücher (und Kalender) bereit, die über (W)LAN automatisch mit den anderen Geräten synchronisiert werden. Da die Übertragung nur lokal stattfindet, muss man dafür dem Anbieter (mir) anders als bei einem Cloud-Dienstleister nicht vertrauen.


    Disclaimer: ich bin als Entwickler von GeneralSync bei diesem Thema offensichtlich befangen. ;)

    Da die Gegenrichtung ein gängiges Problem ist (private Termine den anderen Kollegen mitteilen, ohne Details zu den Terminen), gibt es dafür viele Möglichkeiten. Voraussetzung ist, dass dein Arbeitgeber dir einen Zugriff mit dem Smartphone erlaubt.


    Wenn der Arbeits-Kalender synchronisiert wird (z.B. vom Arbeitgeber bereitgestellter Server), sollte das Synchronisationsprogramm / der Server eine Option haben, mit dem du auf eine eingeschränkte Version zugreifen kannst. Bei Serverlösungen ist dafür eventuell ein separater Nutzeraccount notwendig, da dein "normaler" Kalender-Benutzer ja bereits Vollzugriff hat. Dein Handy synchronisierst du dann direkt mit derselben Methode wie deinen Arbeits-PC.


    Am besten kenne ich mich da natürlich mit dem von mir entwickelten GeneralSync aus: dort würde man bei der Kopplung des Smartphones mit dem Arbeits-PC festlegen, dass man dem anderen Gerät nicht vertraut (damit der Kalender nicht sofort übertragen wird) und dann den Kalender mit der Einschränkung auf "Verfügbarkeitsinformationen" vom PC an das Smartphone senden (d.h. nur Start- und Endzeiten sowie der Zustand "beschäftigt"/"frei" werden übertragen, das Smartphone kann im Kalender nichts ändern). In anderen Tools heißt die Funktion unter Umständen anders, weitere mögliche Schlüsselwörter sind z.B. "Free/Busy" und "Nur Uhrzeiten".


    Sollte der Arbeits-Kalender ein normaler Kalender sein, brauchst du irgendeine Synchronisationslösung die das unterstützt. Wenn dein Smartphone bei der Arbeit in dasselbe WLAN wie dein Arbeits-Computer darf, könntest du also z.B. GeneralSync auf dem Arbeits-PC installieren und deine bisherige Termine in einen GeneralSync-Kalender kopieren, dessen Verfügbarkeitsinformationen dann über das Netzwerk automatisch auf das Smartphone übertragen werden.


    In größeren Firmen ist das aber oft nicht erlaubt: dann solltest du lieber deinen Administrator fragen, wie das bei euch offiziell gehandhabt wird.

    Mein /home/ ist verschlüsselt und mein login macht die Schlüssel frei, weil ich die ja auch anderswo brauche.

    Damit sind alle Dateien darin vollständig ohne weitere Einschränkungen für jeden Prozess unter deinem Nutzeraccount lesbar. Wenn dir das reicht, brauchst du nach der gleichen Argumentation doch auch kein Passwort für PGP? Alle PGP-Schlüssel werden im Home-Verzeichnis gespeichert, sofern du dein Profil nicht an einen anderen Ort auslagerst.


    Wenn dir das nicht reicht, setze ein Master-Passwort oder mach es dir mit ausgelagerten Schlüsseln unbequem.

    Ich kenne kein Szenario außer dem efail, bei dem das bisher möglich gewesen ist.

    Alle roten Einträge unter https://www.mozilla.org/en-US/…nerabilities/thunderbird/


    Ich zähle seit 78 zwar nur eine Lücke, die nicht als "cannot be exploited through email" markiert wurde und die Ausführung von beliebigem Code zulässt; aber eine reicht ja, und in vielen Situationen macht Thunderbird ja doch auch mal einen Browsing-Kontext auf (Add-ons, Feeds, E-Mail-Loginseiten for OAuth, ...), spätestens dann werden auch alle anderen roten Einträge relevant. Ich will hier aber nicht die große Diskussion aufmachen wie wahrscheinlich es ist, dass solche Lücken bei dir persönlich ausgenützt werden.


    Wenn du persönlich für dich beschließt das das Risiko nicht relevant ist, kann ich auch gut damit leben – ist ja nicht mein Risiko.

    Das war in 68.* nicht möglich

    Sobald ein Angreifer Code ausführen kann ist das eben doch möglich. Ein Beispiel: der Angreifer öffnet zu einem passenden Moment ein Fake-Passwort-Popup um dein Passwort abzugreifen – der damit verschlüsselte private Schlüssel ist ja ohnehin immer lesbar, genau wie alle Mails.


    Mir ist nicht bekannt, dass jemand genug Interesse hätte das in der Praxis auch zu tun (ein Vorteil davon, dass E-Mail-Verschlüsselung nicht weit verbreitet ist^^), aber prinzipiell schützen Passwortabfragen nicht mehr, sobald ein Client übernommen wurde. Die Bedeutsamkeit von Sicherheitslücken unterschätzt man leicht, gerade (aber nicht nur!) als normaler Anwender.


    Das ist jetzt Geschichte, denn der Aufruf einer Mail in TB 78.* entschlüsselt dank der Integration von openPGP seit dem Import aus EnigMail automatisch, und es fehlt die Option, das zu verhindern. Ich "muß" die passphrase überhaupt nicht mehr eingeben.

    Wie Susi to visit schreibt: du musst vorher das Master-Passwort eingeben (außer du hast keines gesetzt, dann hättest du aber auch schon in 68 alle Zugangsdaten unverschlüsselt gespeichert?!). Die Daten bleiben also weiterhin immer verschlüsselt gespeichert. Wenn das nicht der Fall ist, dann wäre das ein tatsächlich ein kritischer Bug.


    Und wenn dich wirklich nur das stört, kannst du die privaten Schlüssel auch in Thunderbird löschen und wieder in gnupg verwalten, Thunderbird 78 hat dafür die versteckte Option 'mail.openpgp.allow_external_gnupg'. Öffentliche Schlüssel müssen aber immer in Thunderbird vorhanden sein, auch deine eigenen (WOT gibt es dadurch also nicht). Der automatische Import nimmt halt an, dass du den neuen und bequemen Weg willst, und hat dich daher umgestellt.

    Was ich mir gewünscht hätte, wäre eine Abfrage wie vor einem System-upgrade, wo auf die grundsätzlichen Änderungen hingewiesen wird und unsereins auf der Basis von release notes und FAQ eine Entscheidung treffen kann. Vorher.

    Das Problem ist, das man Normalnutzern damit vorgaukeln würde, es gäbe eine Alternative zum Upgrade.

    Eine alte Version von Thunderbird einzusetzen ist ein massives Risiko, da es dort bekannte Sicherheitslücken gibt. Dagegen ist fast jede Einschränkung in der Funktionalität weitgehend irrelevant: wenn ein Angreifer deine verschlüsselten Mails im Klartext raustragen kann, ist es für die Sicherheit unerheblich wie oft du dein Passwort eingeben musstest...


    Für nicht-Normalnutzer gibt es die Option, Updates nur manuell durchzuführen. Das bedeutet, dass man selbstständig mindestens einige Stunden pro Monat investieren muss. Wenn du dazu bereit bist und die Gesamtsituation verstehst, ist das eine Option die vielleicht besser zu dir passt: lies vor jedem Update die Release Notes und ggf. die zugehörigen CVEs und entscheide entsprechend deiner Situation selbst, ob du das Update installierst oder andere Maßnahmen gegen die Sicherheitslücken ergreifst. Du musst das dann aber wirklich regelmäßig tun, sonst erreichst du das Gegenteil von Sicherheit.


    während ich leise hoffen darf, daß möglicherweise das ein oder andere nachgebessert wird.

    Definitiv!

    vermeintlichen Schlüsseln von Angela Merkel schauen. Da bekommst du sehr viele Treffer, darunter auch von anderen Fakes signierte, sozusagen voll vertraute.

    Nur dazu: "vertraut" in WOT hat eine eigene, sehr enge Definition: nur, wenn man eine Signatur auf einen manuell als voll vertrauenswürdig markierten Schlüssel zurückverfolgen kann, wird dem Schlüssel "vertraut".


    Das Problem ist, das das Konzept nur dann funktioniert, wenn eine kritische Masse der Nutzer WOT aktiv und korrekt nutzt. Ist das der Fall, ist WOT deutlich sicherer als herkömmliche PKI, da jeder Nutzer gezwungen ist, alle möglichen "Zertifizierungsstellen" selbst zu prüfen. Bei PKI wird die Prüfung an eine zentrale Instanz abgeschoben, die prinzipbedingt Abwägungen machen muss, die entsprechend nicht für jedes einzelne Individuum optimal sind. Darüber hinaus sind zentrale Instanzen sehr viel lohnendere Ziele für etwaige Angreifer: ein erfolgreicher Angriff und alle Nutzer sind betroffen.


    In der Praxis haben aber viele statt WOT mangels vertrauter Schlüssel den "wahrscheinlichsten" Schlüssel genommen und als vertrauenswürdig markiert. Das widerspricht WOT, ist aber in der Praxis leider oft die einzige Option, da das eigene Vertrauensnetz mangels Verbreitung oft viel zu grobmaschig ist. Ein Netzwerk aus geprüften Zertifizierungsstellen wäre da die optimale Ergänzung: PKI kann ja auch in WOT abgebildet werden, nur eben nicht umgekehrt. ;)

    [OT]

    kannst du in den Logs sehen, wann welcher Beitrag geschrieben wurde?

    Am PC kann man mit der Maus über die relativen Zeitangabe fahren, dann werden Zeiten angegeben: der Beitrag von Mungo wurde um 20:15, deiner um 20:34 veröffentlicht.

    Es ist aber zumindest bei mir normal das man hier neue Beiträge nicht sieht bis die Seite neu geladen wird; ich habe deinen Beitrag auch erst nach dem Absenden von meinem gesehen; der Tab war bereits eine Weile offen...

    [/OT]

    Wenn ich nur den einen server nutzen kann, werde ich ebenso ohne Not bevormundet.

    Du solltest weiterhin Schlüssel aus allen Quellen importieren können?


    Darüber hinaus kannst du kannst prinzipiell auch ändern, welcher Keyserver für die Komfortfunktionen genutzt wird (derzeit über "temp.openpgp.keyserver" in der erweiterten Konfiguration). Dafür wird aber das vks-Protokoll vorausgesetzt. Dieses Protokoll garantiert maximal einen Treffer zu jeder Anfrage zu liefern, was für Endnutzer deutlich verständlicher ist und entsprechend eine einfacherer Benutzeroberfläche ermöglicht – so zumindest der Kommentar dazu im Thunderbird-Quelltext. SKS unterstützt das Protokoll entsprechend prinzipbedingt nicht. Eventuell kommt die Unterstützung mehrerer Keyserver oder von hkps irgendwann als erweiterte Option dazu, aber für den Moment war das eine bewusste Abwägung.


    Dass das WOT wegfällt stört mich zwar auch etwas, aber ich muss zugeben dass der "neue" Weg in der Praxis selbst für meine Szenarien einfacher und genauso sicher ist (nur eben ungewohnt) – WOT hat sich schließlich nie wirklich durchgesetzt.


    Was aber tatsächlich unschön ist, ist die separate Schlüsselverwaltung für Nutzer von Thunderbird und gnupg-basierten Anwendungen. Diese müssen nun zwei Schlüsselbunde pflegen. Ursache ist hier die rechtliche Inkompatibilität von GPL-lizenzierter Software wie gnupg mit offeneren Lizenzen wie der von Thunderbird: eine GPL-konforme Integration mit gnupg und built-in PGP-Support auf allen Plattformen hätte das Budget gesprengt, und letzteres hatte – zu Recht – Priorität.

    Nur als allgemeine Information, insbesondere an die CSS-Enthusiasten hier im Forum: Thunderbird hat seit Version 78.7.1 eine neue Theme-API. Mit dabei: Theme Experiments können – analog zu WebExtension Experiments – nun prinzipiell alles tun, was "alte" Theme-Typen konnten. So können Theme-Entwickler Vorschläge für zukünftigen Erweiterungen der API selbst umsetzen und sofort selbst nutzen. :)


    Siehe dazu auch die Ankündigung von @jobisoft (auf Englisch).

    Hast Du persönlich keine Probleme mit dem aktuellen Stand des Thunderbirds?

    Nein, in meinen produktiven Installationen gibt es keine Probleme, die mich im Alltag stören würden.


    Wie bereits geschrieben kannst du entweder die hier gegebenen Informationen (einschließlich den für die Eingrenzungen wichtigen Informationen von Susi to visit ), zusammen mit ggf. ein paar Experimenten, in präzise Fehlerberichte gießen und so dazu beitragen dass das Problem behoben wird – oder es lassen, und hoffen, dass sich schon irgendwann irgendjemand kümmern wird. Beides valide Standpunkte, aber hier weiterzudiskutieren wird das Problem nicht schneller lösen.

    Dann macht es aber keinen Sinn 'Alle Termine bearbeiten' anzuzeigen, dieser Punkt sollte zumindest inaktiv gesetzt werden.

    Wenn du konkrete Lösungen beitragen willst, würde es Sinn machen einen entsprechenden Bug zu öffnen und dort mögliche Problemlösungen vorschlagen. Wenn es dir besonders dringend unter den Nägeln brennt und du nicht warten kannst/willst bis sich jemand anderes darum kümmern könntest du dann auch – sobald du das OK für eine dieser Lösungen bekommst – selbst einen Patch entwickeln (oder einen Entwickler anstellen, der das für dich tut). Hier darüber zu diskutieren wird aber vermutlich keine schnellere Veränderung bewirken.


    Wenn du dafür Begriffe suchst: die neu erzeugten, leeren Elterntermine heißen "faked master events" und werden in Bugzilla auch als "X-MOZ-FAKED-MASTER event" bezeichnet, nach dem internen Eigenschaftsnamen, der diese Termine kennzeichnet.


    Beim Versuch, fehlende Angaben zu ergänzen wird man scheitern, man darf Eingaben zwar machen, aber nach TB-Neustart ist wieder alles verschwunden!


    Wirklich kein Datenverlust?

    Dem Anschein nach hakt es am Laden, nicht am Speichern. Wenn dieser Anschein nicht trügt und der Bug gemeldet, gefunden und behoben wurde, sollten deine "verschwundenen" Eingaben also wieder erscheinen.

    1. Falsche Nummerierung der Wochentage in mehreren Monaten (Sommerzeit?) in verschieden Jahren, z.B. 1978, in den beiden Ansichten 'Mehrere Wochen' und 'Monat' auch noch unterschiedlich.

    Das ist bekannt, Bug 1673835. Ursache sind wohl tatsächlich Zeitzonendetails, der Bug tritt entsprechend nur vor 2018 auf. Da die meisten Nutzer eher mit aktuellen Terminen hantieren, hat das vermutlich noch keinen Freiwilligen so sehr gestört das dieses Ansichtsproblem behoben wird.


    a) Einen Folgetermin mit Drag & Drop auf ein anderes Datum verschoben


    b) Einen Folgetermin mit 'Ausschneiden' und 'Einfügen' in an anderes Datum


    c) Einen Folgetermin mit 'Kopieren' in anderes Datum und anschließend Ursprungstermin gelöscht

    In deinen Fällen b und c legst du jeweils eine neue Instanz des Termins an, die nicht mehr mit dem Ursprungstermin verknüpft ist. Da dieser neue Termin aber Teil einer Terminserie sein muss um angezeigt zu werden legt Thunderbird dann einen neuen, leeren Ursprungstermin an. Es ist also gewollt, dass "Alle Termine Bearbeiten" in Szenarien b und c keine Daten anzeigt – schließlich sind alle Bestandteile des Termins logisch gesehen eine Ausnahmeregel!


    Mir ist bewusst das das für einige Nutzer nicht intuitiv ist, aber es ist die beste Lösung wenn man den Termin authentisch kopieren will. Man kann aber sicherlich darüber streiten, ob statt einer echten Kopie nicht lieber ein neue Termin mit gleichem Inhalt, aber ohne Terminserie angelegt werden sollte. Dann verliert man die Information über die Terminserie, aber gewinnt an Benutzerfreundlichkeit für Änderungen.


    Das Verschwinden des Ortes scheint mir aber wirklich ein Bug zu sein, hängt aber von weiteren Faktoren ab (eventuell: nur lokale Kalender bzw. nur durch Thunderbird bereitgestellte Kalender?). Zumindest trat das Problem in meinen Tests mit GeneralSync-Kalendern nicht auf.


    Das hier auf Drag-And-Drop geschobene Problem der nicht persistenten Termine ist aber wirklich gravierend, und weitreichender als es sich anhört: in meinen Tests scheint immer nur die erste Ausnahmeregel an einem Serientermin gespeichert zu werden, egal auf welchem Wege diese angelegt wurde. Scheint ein Backendproblem zu sein (d.h. in der Datenbank), und trifft damit auch GeneralSync, wenn auch in anderen Zusammenhängen. :/


    Kann aber noch nicht sicher sagen woran das liegt. Gespeichert wird scheinbar alles ordentlich, insofern hoffentlich ein Problem das ohne Datenverlust behoben werden kann.

    Da muss man dann, wie früher, nur die Version auf 85 anpassen dann funktioniert die Erweiterung auch.

    Nur als allgemeiner Hinweis: es ist leider nicht garantiert, dass das immer funktioniert und keine (ggf. scheinbar unabhängige) Probleme verursacht. Add-ons mit sogenannten Experimenten (wie das Geburtstagskalender-Add-on, da es noch keine offizielle Kalenderschnittstelle gibt) können massive Kompatibilitätsprobleme haben. Entsprechend sollten sie für jede Hauptversion getestet und ggf. angepasst werden – daher kann ich mir eine Unterstützung von Betas nicht leisten, schon gar nicht bei einem kostenlosen Add-on.


    Unter Kenntnis der Risiken (und bei guter Backup-Strategie) spricht aber natürlich nichts dagegen, es dennoch zu versuchen ;)

    Meines Wissens kann ein Import nicht ohne weiteres rückgängig gemacht werden (auch wenn es rein technisch mit einem Add-on gehen könnte – mir ist nur eben kein Add-on mit derartiger Funktionalität bekannt). Daher würde ich mal über andere Gemeinsamkeiten der neuen Termine nachdenken: haben alle Termine dieselbe Kategorie? Kommt in allen Terminen ein bestimmtes Wort vor?


    Wenn "Termine suchen" aktiviert ist (im Kalender-Tab erreichbar über Menüleiste bzw. Menü | Termine und Aufgaben | Termine suchen), gibt es über der Kalenderansicht ein Suchfeld über einer Liste, in der Spaltenweise sortiert werden kann. Darin können – wie in Listen üblich – ganzer Blöcke von Terminen markiert werden (obersten Termin des Blocks markieren, dann mit gedrückter Umschalttaste auf den untersten Termin des Blocks klicken). Der Block kann dann über Rechtsklick und "Termin löschen" gelöscht werden (oder mit der Entfernen-Taste). Achtung: Thunderbird löscht die Termine dann ohne weitere Rückfrage, so gelöschte Termine können nicht wiederhergestellt werden. Also zur Sicherheit vorher prüfen, dass die letzte Sicherung funktioniert hat und nicht allzu lange her ist. ;)

    Aber wie und an welcher Stelle kann/muss ich diese SQL-Befehle ausführen lassen?

    Prinzipiell: das Statement muss nach jedem Aufbau der Verbindung und vor dem ersten Zugriff durch LibreOffice ausgeführt werden. Ob und wo man dafür Optionen in LibreOffice oder dem ODBC-Server findet kann ich dir nicht sagen. Wie gesagt, von LibreOffice habe ich keine Ahnung. Ich hatte mich nur gemeldet da ich die Datenbankseite in Thunderbird kenne.


    Ohne das "TEMP" (d.h. dauerhaftes Anlegen der View direkt in der Datenbank, mit den beschriebenen Risiken bei Thunderbird-Updates) geht direkt mit jedem SQLite-Datenbankeditor. Die haben alle irgendwo ein Eingabefeld für SQL-Befehle. Nur vorher Thunderbird schließen!

    die benötigen Felder stehen auch in der Tabelle 'properties' nicht zur Verfügung

    Ich hatte bewusst ein Ausrufezeichen an "Zeilen" gepackt: OpenOffice erwartet eine Zeile pro Kontakt, mit allen Feldern in Spalten (zumindest in dem Dialog, aus dem die Screenshots sind). Thunderbird nutzt jeweils eine Zeile für jedes einzelne Feld in einem Kontakt (also i.d.R. mehrere Zeilen für denselben Kontakt!). Man muss das also für LibreOffice "übersetzen", z.B. mit einer View. Das braucht zwar keine wirklichen Programmierkenntnisse (den fertigen SQL-Befehl für Anzeigenamen und E-Mail-Adresse habe ich ja schon oben gepostet) aber natürlich durchaus ein bisschen Hintergrund und/oder Einarbeitung.


    Insofern sorry für das missverständliche "trivial", das bezog sich eher auf die Art der Problemlösung als auf den absoluten Aufwand bei der Umsetzung.


    (... und wenn du eine ODBC-Verbindung aufbauen kannst hast du ja zumindest ein bisschen Ahnung von Datenbanken ;) )