Benutzer:vv01f
Benutzer vv01f | |
---|---|
PGP Fingerprint: | 4B12EFA69166CA8C23FC47E49CD3A46248B660CA |
Instant Messaging | |
Jabber-ID: | wolf@jabber.c3d2.de |
Kontakt
- xmpp:wolf@jabber.c3d2.de
- matrix:u/wolf402:matrix.org
- nostr:npub10z4ffmdfw6agmspdlyg93l9z85kx4870hzj9g6ghpyxwpx6weyts0yt032
- mastodon:@vv01f@chaos.social
- PGP: 4B12EFA69166CA8C23FC47E49CD3A46248B660CA
about me
- Nichtraucher
- gut darin blöde Fragen zu formulieren
Interessen
- ein bisschen coden/scripten und viel debuggen/absichern - bin aber kein Guru in irgendwas
- Bitcoin, Monero, nachhaltige Finanzen: Grenzkostenökonomie
- Zugang zu Wissen
ToDo
- Plattform mit Anreizsystem
- pre:tix-Plugin für mechanizing einer anderen pre:tix-Instanz
- Vermögensverwaltung in Vereinen, Test, Dokumentation
- + [x] Vorgehensmöglichkeiten für laufende u. künftige Finanzierungen, dabei ETF-Auswahl
- + [x] Behandlung von Kryptoassets, insb. Bitcoin
- + [ ] ToDo: Automatisierung für Geschäftsprozesse, insb. Rechnungen über eG, KSt für eS/eV, Steuerberechnung für Optionen
- + [ ] ToDo: Depot für Verein
Warum bin ich hier?
plain: Ich erhoffe mir einiges zu lernen und mit einigermaßen Gleichgesinnten Kontakt zu haben und gemeinschaftlich mehr als allein zu erreichen…
War das Absicht?
- "Deine letzten E-Mails an $Mailingliste waren verschlüsselt, so dass nicht jeder sie lesen konnte. War das Absicht?"
Ja, ich verschlüssle seit einer Weile an Listen sofern es nicht explizit offene Informationen sind oder große Eile bei der Weitergabe von mir gewünscht ist. Das ist leider noch nicht so trivial wie man sich das wünscht. Unter anderem weil Nutzer einer Mailingliste nicht einfach eine Liste von Fingerabdrücke der Empfänger erhalten können.
Wenn man immer fordert möglichst viel zu verschlüsseln und dann eigentlich nur offene Mails durch die Kante schiebt, fand ich das sehr inkonsequent. Und deshalb verfolge ich einfach: Verschlüsseln wir doch was geht.
Dazu habe ich einfach die Empfängerregeln (per-recipient rules) eingesetzt. Genauer in der Datei pgprules.xml
für Thunderbird weil group
in der Datei gpg.conf
mir – in Verbindung mit den dann ggf. notwendigen (lokalen) Signaturen – zu anstrengend war. Letzteres ist aber insbesondere eine Option für alle Programme die den Agent noch so verwenden. Ich glaube so können u.a. Nutzer von Emacs trotz fehlender/falschen E-Mail Adresse in einer UID weiterhin gewohnt komfortabel PGP nutzen.
Sollte jemand mal wissen wollen an wen eine verschlüsselte Mail alles ging, kann er sich die Päckchen mit KeyIDs auflisten lassen:
gpg2 --list-packets ${file}
Bzw. wenn du feststellen willst, ob dein Key in einer Mail dabei war:
gpg2 --list-packets ${file} 2>&1 | grep -i ${deine-keyid}
Wenn nicht, kannst du mir deinen Key gerne bekannt geben und gerne auch die bislang nicht lesbare Mail (Message-ID bitte nennen) anfordern.
Und ja, mir ist bewusst, dass diese Möglichkeit noch nicht sonderlich bequem ist und mancher glaubt offene Listen sollten offen sein. Andere rechnen mir vor, dass das nicht skaliere weil die Größe der Mails mit jedem weiteren Empfänger um x KB steigt. Naja, wenn ich sehe wie das Web MB-weise verhunzt wird, ist das für mich kein ausschlaggebendes Argument. Vor nicht allzu langer Zeit haben Serverbetreiber bezüglich TLS noch argumentiert: "Ich hoste nur Informationen oder scheue die höheren Betriebskosten." Das will man ja auch nicht.
Allerdings hat mein Vorgehen auch erwünschte Effekte:
- manche Menschen verlängern abgelaufene Schlüssel
- andere Menschen legen sich Schlüssel zu
- oder senden mir ihren öffentlichen ob der Abneigung gegen Keyserver
- … also Menschen nutzen PGP und ihre Schlüssel
- mach einer probiert sogar PEP oder K9/PEP für Android aus
- der Wunsch nach Smartcards für den Einsatz auf fremden und mobilen Geräten steigt :D
- Entschleunigung von Mails
- Bugs in Enigmails per-recipient rules (beim editieren) wurden gefixt \o/
Bis die Tage.
Warum nicht Schleuder?
Top Antwort: Weil dann der Server an die Empfänger verschlüsselt und nicht der Sender.
Auch: Es wird an den Server verschlüsselt, dort liegen die Informationen im Klartext vor. Das widerspricht dem Ansatz Ende-zu-Ende.
Oder: Beim Verfahren, sind die Schlüssel grundsätzlich nur dem Server bekannt. Die Idee ist aber mehr Verschlüsselung (auch abseits der Mailingliste zu verbreiten. Wenn mehr Menschen Schlüssel haben und die Software eingerichtet wurde, wird die Verwendung damit antrainiert und nach der Adoption die Akzeptanz gesteigert.
Was kommt als nächstes?
- "Willst du echt Leute zu ihrem Glück zwingen?"
Machmal ja. D.h. ich nutze PGP im Zweifel auch mit symmetrischer Verschlüsselung um Menschen mit Informationen, die sie brauchen zum Einsatz zu bewegen. Das kann der- oder diejenige als Zwang wahrnehmen und ich lebe gut damit.
Welche Probleme sind noch offen
Wenn an Teilnehmer per BCC gesendet wird, kann man die IDs wahlweise verbergen. Dann haben die Empfänger ein Problem sobald sie mehr als nur einen Schlüssel nutzen, denn das Mailprogramm kann den Schlüssel nicht autmatisch auswählen und der Nutzer muss dies gezielt tun.
Es gibt Nutzer, die aus Trotz keine Öffentlichen Schlüssel weitergeben möchten. Denen kann ich auch nicht helfen.
Es gibt Nutzer, die nicht wissen was da gerade für ein komischer Spam auf der ML aufschlägt. Die fragen zumeist und sind ein Grund für diese Hinweise hier. Schöner wäre eine Lösung durch Multipart-Mails, sodass ein Klartext Part angezeigt wird wenn der Empfänger kein PGP hat. Sofern hierfür jemand eine gute Lösung oder einen handhabbaren Weg kennt, bin ich ganz Ohr.
Keylists
Nur als Beispiel ein Vereinsvorstand; andere Listen könnt ihr euch entsprechend zusammenstellen:
- Thunderbird 78.* bietet seit Mitte Dezember experimentelle Unterstützung für Aliases mit Konfigiration über JSON bis die GUI verfügbar wird – Details s. Bug 1644085.
- Konfigurationshinweise für private Schlüssel mit GnuPG – das erlaubt auch die Nutzung von Keys ohne (mit TB-Account/Identity übereinstimmender) E-Mail-Adresse
openpgp_alias_to_keys.json
{ "description": "Thunderbird OpenPGP Alias Rules", "rules": [ { "email": "vorstand@c3d2.de", "keys": [ {"description": "sandro", "fingerprint": "53B26AEDC08246715E15504B236B6291555E8401"}, {"description": "chrissy", "fingerprint": "E3113521241B159C17A79D9FA38DF02A52BB4630"}, {"description": "winzlieb", "fingerprint": "3724D87331C207452F1E3FDFC49A5BC961A73EF8"} ] } ] }
- Thunderbird 68.* wird standardmäßig automatisch auf eine neue Version angehoben, dabei wird auch das Profil für die ältere Version unbrauchbar. Um das zu verhindern ist neben einem Backup eine [Policy-Datei](https://www.thunderbird-mail.de/lexicon/entry/239-thunderbird-update-per-policy-verbieten-also-komplett-deaktivieren/) hilfreich.
- Ältere Thunderbird bis 68.*
~/.thunderbird/$(cat ~/.thunderbird/profiles.ini|grep "^Path="|head -1|cut -d"=" -f2)/pgprules.xml
(Empfängerregel f. Enigmail, hier Version 2.0.8 (20180804-1515), hier erstes Profil)
<pgpRule email="{vorstand@c3d2.de}" keyId=" 0x3724D87331C207452F1E3FDFC49A5BC961A73EF8, 0x53B26AEDC08246715E15504B236B6291555E8401, 0xE3113521241B159C17A79D9FA38DF02A52BB4630 " sign="2" encrypt="2" pgpMime="2" negateRule="0"/>
~/.gnupg/gpg.conf
group vorstand@c3d2.de = 0x3724D87331C207452F1E3FDFC49A5BC961A73EF8 0x53B26AEDC08246715E15504B236B6291555E8401 0xE3113521241B159C17A79D9FA38DF02A52BB4630