Benutzer:W01f: Unterschied zwischen den Versionen

Aus C3D2
Zur Navigation springen Zur Suche springen
K (todo)
 
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 3: Zeile 3:
* mailto vv01f [at] c3d2 [dot] de
* mailto vv01f [at] c3d2 [dot] de
* xmpp:wolf@jabber.c3d2.de
* xmpp:wolf@jabber.c3d2.de
* matrix:u/wolf402:matrix.org
* [https://chaos.social/@vv01f mastodon:@vv01f@chaos.social]
* [https://chaos.social/@vv01f mastodon:@vv01f@chaos.social]
* PGP: [https://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0x9CD3A46248B660CA 4B12EFA69166CA8C23FC47E49CD3A46248B660CA]
* PGP: [https://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0x9CD3A46248B660CA 4B12EFA69166CA8C23FC47E49CD3A46248B660CA]
Zeile 14: Zeile 15:
* ein bisschen coden/scripten und viel debuggen/absichern - bin aber kein Guru in irgendwas  
* ein bisschen coden/scripten und viel debuggen/absichern - bin aber kein Guru in irgendwas  
* ITSec, DSch (eher esoterisch mit Planung denn konkret mit Umsetzung)
* ITSec, DSch (eher esoterisch mit Planung denn konkret mit Umsetzung)
* Bitcoin, Monero, nachhaltige Finanzen
* Bitcoin, Monero, nachhaltige Finanzen: Grenzkostenökonomie
* (La)TeX – wie üblich mehr gefrickelt als gekonnt
* (La)TeX – wie üblich mehr gefrickelt als gekonnt
* Zugang zu Wissen
* Zugang zu Wissen
== ToDo ==
* [https://codimd.c3d2.de/plattform-mit-anreizsystem 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
:+ [ ] Mangel: Depot für Verein
<!-- * RSS/Torrent/OPDS für eBooks -->


=== Warum bin ich hier? ===
=== Warum bin ich hier? ===
Zeile 63: Zeile 73:
Bis die Tage.
Bis die Tage.


==== Warum nicht Schleuder? ====
==== Warum nicht [https://schleuder.org/ Schleuder]? ====


Top Antwort: Weil dann der Server an die Empfänger verschlüsselt und nicht der Sender.
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 wiederspricht dem Ansatz Ende-zu-Ende.
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.
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.
Zeile 87: Zeile 97:
==== Keylists ====
==== Keylists ====


Mal als Beispiel der am 2018-12-06 gewählte und am 2019-12-05 erneut bestätigte Vereinsvorstand; andere Listen könnt ihr euch entsprechend zusammenstellen:
Nur als Beispiel ein Vereinsvorstand; andere Listen könnt ihr euch entsprechend zusammenstellen:


;Thunderbird 78.* bietet [https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases seit Mitte Dezember experimentelle Unterstützung für Aliases] – [https://bugzilla.mozilla.org/show_bug.cgi?id=1644085 Details s. Bug 1644085], diese Lösung mittels einer JSON-Datei für Empfängerregeln soll bis April auch in das Release einfließen; das Format für die Definition wird noch überarbeitet.  
;Thunderbird 78.* bietet [https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases seit Mitte Dezember experimentelle Unterstützung für Aliases] mit Konfigiration über JSON bis die GUI verfügbar wird – [https://bugzilla.mozilla.org/show_bug.cgi?id=1644085 Details s. Bug 1644085].  
: [https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards Konfigurationshinweise für private Schlüssel mit GnuPG] – das erlaubt auch die Nutzung von Keys ohne (mit TB-Account/Identity übereinstimmender) E-Mail-Adresse
: [https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards Konfigurationshinweise für private Schlüssel mit GnuPG] – das erlaubt auch die Nutzung von Keys ohne (mit TB-Account/Identity übereinstimmender) E-Mail-Adresse



Aktuelle Version vom 24. April 2022, 13:10 Uhr

Kontakt

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
  • ITSec, DSch (eher esoterisch mit Planung denn konkret mit Umsetzung)
  • Bitcoin, Monero, nachhaltige Finanzen: Grenzkostenökonomie
  • (La)TeX – wie üblich mehr gefrickelt als gekonnt
  • 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
+ [ ] Mangel: 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
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="
0x9580391316684474BFBD41EC3E8C55248C19AF2A,
0x3724D87331C207452F1E3FDFC49A5BC961A73EF8,
0x3CA2EAAE4052C11EF5D8E852D4006DDF69FB4A4F
" sign="2" encrypt="2" pgpMime="2" negateRule="0"/>
~/.gnupg/gpg.conf
group vorstand@c3d2.de = 0x9580391316684474BFBD41EC3E8C55248C19AF2A 0x3724D87331C207452F1E3FDFC49A5BC961A73EF8 0x3CA2EAAE4052C11EF5D8E852D4006DDF69FB4A4F