Benutzer:W01f: Unterschied zwischen den Versionen

Aus C3D2
Zur Navigation springen Zur Suche springen
K (todo)
(41 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Kontakt ==
* mailto vv01f [at] c3d2 [dot] de
* xmpp:wolf@jabber.c3d2.de
* matrix:u/wolf402:matrix.org
* [https://chaos.social/@vv01f mastodon:@vv01f@chaos.social]
* PGP: [https://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0x9CD3A46248B660CA 4B12EFA69166CA8C23FC47E49CD3A46248B660CA]
== about me ==
== about me ==


* Erreichbarkeit: muc, vv01f@jabber.ccc.de
* Nichtraucher
* Nichtraucher
* leider beruflich zu viel unterwegs -> nur am WoE in der Stadt
* gut darin blöde Fragen zu formulieren


'''Interessen'''
'''Interessen'''
* Kunst im Kreise mir bekannter Künstler
* 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 (eher esoterisch mit Planung denn konkret mit Umsetzung)
* ITSec, DSch (eher esoterisch mit Planung denn konkret mit Umsetzung)
* Bitcoin
* Bitcoin, Monero, nachhaltige Finanzen: Grenzkostenökonomie
* (La)TeX – wie üblich mehr gefrickelt als gekonnt
* 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? ===


plain: Ich erhoffe mir einiges zu lernen und mit einigermaßen Gleichgesinnten Kontakt zu haben..
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 <code>pgprules.xml</code> für Thunderbird weil <code>group</code> in der Datei <code>gpg.conf</code> 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:
 
<pre>
gpg2 --list-packets ${file}
</pre>
 
Bzw. wenn du feststellen willst, ob dein Key in einer Mail dabei war:
 
<pre>
gpg2 --list-packets ${file} 2>&1 | grep -i ${deine-keyid}
</pre>
 
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 [https://schleuder.org/ 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:


== Eigene Vorhaben ==
;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


'''Bitcoin4all''' -> [https://bitcoinfoundation.org Bitcoin Foundation]
;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.
: Jedem der zuhören mag von Bitcoin erzählen und Konvertiten unterstützen ''- Status: viele bequatscht, einige mit Bitcoin bezahlt, wenige assimiliert, Lifetime Member der Bitcoin Foundation''
'''[http://w01f.eu/jeopardy/ JSJeopardy]'''
: Jeopardy als Erfolgskontrolle bei Schulungen ''Status: pausiert mangels Inhaltsbeiträge/Nutzern''
'''BitcoinCash'''
: Zahlungsmodul für Online-Shop ohne dedizierten daemon ''- Status: für ein Shopsystem mit PHP seit sep2011''
'''Personalplaner (Excel/VBA)'''
: Optimierung, Debugging eines Fremdprojektes + Schulung des Freizeitentwicklers ''- Status: done''
'''Bitcoin-Miner'''
: 2x 4er FPGA (Ztex 15y aus Pfefferkuchen-Pulsnitz) mit dekorativen Kupferkühlern, 1 PSU, zurechtgebastelte Kabel, 1 gebrauchtes Netbook mit ubuntu+btcminer ''- Status: done ~1,7GH/s@105W seit apr2012''
'''Die schlimmsten aller Trolle''' -> [http://www.youtube.com/watch?v=Lm8AUdsB2rQ Trailer] [http://www.visionbakery.com/vision/650 Crowdfunding für den Film]
: Der Trailer ist teil des auch gelisteten Diplomes und der Film resultiert schlichtweg ''- Status: Trailer done, film planning-phase'' - leider wird der Film aufgrund von Planungsmängeln und daraus resultierender Finanzknappheit nicht mit "uns" umgesetzt und damit sind die Investitionen (Maske von Antje Dahm) in den Trailer nicht im Film zu erwarten.
'''Website Maskenbildnerin'''
: simples Design vom Grafiker mit HTML5 umsetzen, Kontakt-Formular, vcard anwenden ''Status: done, online seit jul2012''
'''Status-Widget & Stundenplan für Fitness-Studio'''
: mit PHP+MySQL in bestehendem DMS, statische Stundenpläne neu umsetzen ''- Status: first draft done, project paused due to dataloss (DMS) at owners side''
'''Miner-Case'''
: 4 Bretter hübsch um die Hardware wickeln ''- Status: Jan2013 Gestoppt, Mining-Rig wird absehbar unrentabel''
'''Brotkasten'''
: Casemod eines Keyboard + Rechenzwerg ''- Status: teste IBM Model M + raspberry pi, hakumenta erklärt mir Strom *thumbup* ''
'''Freifunk in Dresden'''
: ''Satus: +1 Node für ddmesh.de in der Südvorstadt''
'''Studium "Irgendwas mit IT"'''
: ''Satus: waiting... ETA sep2014''


== Fragen? ==
;[https://archive.mozilla.org/pub/thunderbird/releases/ Ältere Thunderbird] bis 68.* <code>~/.thunderbird/$(cat ~/.thunderbird/profiles.ini|grep "^Path="|head -1|cut -d"=" -f2)/pgprules.xml</code> (Empfängerregel f. Enigmail, hier Version 2.0.8 (20180804-1515), hier erstes Profil)
<pre>
<pgpRule email="{vorstand@c3d2.de}" keyId="
0x9580391316684474BFBD41EC3E8C55248C19AF2A,
0x3724D87331C207452F1E3FDFC49A5BC961A73EF8,
0x3CA2EAAE4052C11EF5D8E852D4006DDF69FB4A4F
" sign="2" encrypt="2" pgpMime="2" negateRule="0"/>
</pre>


Wenn ihr was wissen wollt, einfach mal hier, im muc oder wenn man sich sieht formulieren..
;<code>~/.gnupg/gpg.conf</code>
<pre>
group vorstand@c3d2.de = 0x9580391316684474BFBD41EC3E8C55248C19AF2A 0x3724D87331C207452F1E3FDFC49A5BC961A73EF8 0x3CA2EAAE4052C11EF5D8E852D4006DDF69FB4A4F
</pre>

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