Anfang März 2018 finden wieder die Chemnitzer Linux-Tage (auch als Onion Service) statt. Traditionell organisiere ich die Keysigning-Party. Die Anmeldung dafür ist abgeschlossen und ich habe eine Grafik für das Web of Trust erstellt:
Wer mir eine OpenPGP-verschlüsselte E-Mail schicken will, sollte demnächst doppelt vorsichtig sein. Ich entdeckte heute, dass es zur Key-ID 0xEA3E4D61 zwei Schlüssel gibt. Einer der beiden wurde vermutlich automatisch erzeugt und gehört mir nicht! Der Fingerabdruck meines derzeitig aktiven Schlüssels ist:
pub 4096R/0x65B3F094EA3E4D61 2010-01-15 Schl.-Fingerabdruck = 60D8 5B8D 9A1C D2D1 355E BE9F 65B3 F094 EA3E 4D61 uid Jens Kubieziel <jens@kubieziel.de> uid Jens Kubieziel <jens@freie-re.de> uid Jens Kubieziel <kubieziel@gmx.de> uid Jens Kubieziel <lugjena@kubieziel.de> uid Jens Kubieziel <jens@torservers.net> sub 4096R/0x7A0A527D47FFDBE1 2010-01-15
Wenn ihr mir eine verschlüsselte E-Mail schicken wollt, vergleicht unbedingt die obige zweite Zeile. Im Allgemeinen empfiehlt es sich in der Konfigurationsdatei von GnuPG die Variable keyid-format 0xlong oder gleich long zu setzen. Die kurze Key-ID ist, wie oben zu sehen, leicht zu fälschen.
Update: Das Problem betrifft nicht nur mich. Auf Twitter war von mehreren Fällen zu lesen und auch die Kernel-Entwickler sind betroffen.
Am 19. und 20. März fanden in Chemnitz wieder die Chemnitzer Linux-Tage statt. Einer alten Tradition folgend organisierte ich das Keysigning. Das heißt, Leute mit einem OpenPGP-Schlüssel können teilnehmen und sich gegenseitig ihre Identität bestätigen. Durch die Prüfung und Signatur wird das Vertrauensnetz (Web of Trust) gestärkt.
In den letzten Jahren stellten wir uns dazu in einer Reihe auf. Die erste Person bewegte sich dann zur zweiten und anschließend zur dritten, vierten usw. Nachdem die erste Person vorbei war, fing die zweite an. So sah das ungefähr aus:
Startaufstellung:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
Erste Person startet:
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 1 |
Zweite Person startet:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 2 | 1 |
Nach einer Weile startet die sechste Person:
| 7 | 8 | 9 | 10 | 1 |
| 6 | 5 | 4 | 3 | 2 |
Das heißt, die erste Person reiht sich wieder ans das Ende ein. Eine Reihe zeigt jeweils den Ausweis und die andere Reihe vergleicht.
Bei dem Verfahren ist nun der Nachteil, dass anfangs sehr viele Leute im Leerlauf sind. Sie müssen warten, bis die erste Person endlich bei denen angekommen ist. Um dies ein wenig zu beschleunigen, haben wir die Reihe dieses Jahr direkt gefaltet. Nach der Sortierung in eine Reihe stellten sich alle gegenüber auf:
| 1 | 2 | 3 | 4 | 5 |
| 10 | 9 | 8 | 7 | 6 |
Die Idee war, dass wieder eine Reihe prüft und die andere den Ausweis zeigt. Leider habe ich das wohl nicht genau genug erklärt und es wurde parallel von beiden Seiten gemacht. Als die Reihe nun zur Hälfte abgearbeitet war, kamen die Teilnehmer bei ursprünglichen Gegenüber wieder an und nahmen an, alle erwischt zu haben. Dies ist aber nicht der Fall:
| 2 | 3 | 4 | 5 | 6 |
| 1 | 10 | 9 | 8 | 7 |
Die Aufstellung oben ist nach dem ersten Wechsel. In der initialen Aufstellung verglich beispielsweise Teilnehmer 3 mit Teilnehmer 8 die Daten. In obigem Schritt vergleicht 3 mit 10 usw. Nach fünf Schritten stehen sich 3 und 8 wieder gegenüber. Teilnehmer 3 hat dann die Identität der Teilnehmer 8, 10, 2, 4 und 6 verifiziert. Was ist mit 1, 5, 7 und 9? Diese fehlen offensichtlich. Es kostete mich einige Mühe die Teilnehmer zu überzeugen, dass der Lauf noch nicht beendet ist. Hoffentlich kann ich alle dann im nächsten Jahr auf diese Seite verweisen und die Überzeugungsarbeit wird einfacher. 
Wer sich für den Stand des Web of Trust interessiert:
Die 5. Wahlperiode des Thüringer Landtages neigt sich dem Ende zu. Einer der letzten Beschlüsse ist die Drucksache 5/7583 mit dem Titel Verschlüsselte Kommunikation ermöglichen und befördern
. In der Endfassung enthält der Beschluss die Bitte an die Landesregierung:
- zukünftig Wege zu ermöglichen, welche die Vertraulichkeit des Inhalts elektronischer Kommunikation mit öffentlichen Stellen des Landes und der Nutzung ihrer elektronischen lnformationsdienste sowie des Inhalts elektronischer Kommunikation zwischen öffentlichen Stellen des Landes durch Angebote einer sicheren End-to-End-Verschlüsselung (Kryptografie) eröffnen,
- die Bürger des Freistaats Thüringen in geeigneter Weise über die Möglichkeiten der Verschlüsselung elektronischer Kommunikation, insbesondere auf den Web-Seiten der Landesregierung, zu informieren.
Darin steckt der Wunsch, TLS für Webseiten und Ende-zu-Ende-Verschlüsselung vielleicht mit OpenPGP zu machen.
Ich entschied mich, denselben Weg wie Anna Biselli zu gehen. Sie versuchte, verschlüsselt mit einem Abgeordneten zu kommunizieren. Ich besuchte die Webseiten der Fraktionen im Landtag und die der Abgeordneten. Dabei wollte ich jede Seite mit https öffnen und suchte nach einer Möglichkeit für verschlüsselte E-Mail-Kommunikation. Konnte ich beides nicht finden, so schrieb ich die Abgeordneten an. Was kam dabei heraus?
Die CDU-Fraktion im Landtag bietet keinerlei Unterstützung für SSL/TLS an und es gibt auch keine Möglichkeit zur verschlüsselten E-Mail-Kommunikation.
Die Webseite der SPD-Fraktion begrüßt mich mit der Meldung SSL peer has no certificate for the requested DNS name. Eine verschlüsselte Verbindung zu der Seite ist damit nicht möglich und ich fand auch keinen OpenPGP-Schlüssel auf der Seite.
Die Webseite der FDP-Fraktion scheitert zunächst an den Einstellungen in meinem Browser und sagt Peer attempted old style (potentially vulnerable) handshake. Wenn ich die Einstellungen lockere, so präsentiert die Seite ein Zertifikat, was für die Domain web6.online-now.de ausgestellt ist. Wenn ich dann auch noch dieses akzeptiere, so erhalte ich von der resultierenden Seite die Meldung Die Domain “www.thl-fdp.de” ist nicht über https verfügbar. Die Unterstützung von OpenPGP ist wie bei den anderen Parteien.
Die Webseite der Fraktion der Grünen hat ein Zertifikat, welches seit Ende 2013 abgelaufen ist. Ich hatte den Fakt im Juli 2014 gemeldet. Zum Zeitpunkt des Blogeintrages hat sich an dem ungültigen Zertifikat nichts geändert. Wird dies akzeptiert, so werden die Inhalte der Webseite angezeigt. OpenPGP sucht man jedoch vergeblich.
Einzig die Fraktion der LINKEn unterstützt SSL/TLS vom Start weg und die Servereinstellungen sind sehr gut. Hier wäre nur zu wünschen, dass die Webseite alle Anfragen standardmäßig auf die verschlüsselte Seite umleitet. Die positiven Nachrichten reißen aber noch nicht ab. Denn die Kontaktseite bietet einen OpenPGP-Schlüssel zum Download an und weist den Fingerprint aus. Damit ist die LINKE eindeutig der Spitzenreiter, was verschlüsselte Kommunikation betrifft.
Von den knapp 90 Abgeordneten im Landtag gibt es nur zwei, die einen OpenPGP-Schlüssel anbieten:
Beider Webseiten sind auch per HTTPS zu erreichen. Jedoch verwendet die Seite von Dirk Adams ein falsches Zertifikat und die Seite von Katharina König bzw. der Provider blockieren Verbindungen über Tor. Falls ihr also die Seite mit Tor ansurft, kann es sein, dass sich diese nicht öffnet. 
Uwe Barth (FDP) nutzt ein Wordpress-Blog als Webseite. Damit kann die Seite auch per HTTPS besucht werden. Die SPD-Abgeordneten David-Christian Eckardt, Uwe Höhn, Birgit Pelke und Claudia Scheerschmidt nutzen das Angebot von Sozinet. Das bietet ebenfalls HTTPS an.
Bei allen anderen Abgeordneten fand ich keine funktionierende Möglichkeit, per HTTPS auf die Seite zuzugreifen. Ebenfalls konnte ich keine Nennung von E-Mail-Verschlüsselung finden. Also schrieb ich E-Mails und fragte nach.
Die Abgeordneten der FDP haben das Wahlkampfmotto Wir sind dann mal weg
wohl zu ernst genommen. Denn ich erhielt von keinem der angeschriebenen Abgeordneten eine Antwort.
Die CDU schien sich intern auf eine Antwort geeinigt zu haben. Alle Antworten hatten nahezu denselben Wortlaut und verwiesen darauf, dass der Beschluss eine Aufforderung an die Regierung enthält. Erst wenn diese eine Entscheidung getroffen hat, so werden die Abgeordneten diese umsetzen. Aus den Antworten wurde klar, dass vorher nichts zu erwarten ist.
Von der SPD antworteten einige wenige Abgeordnete. Allerdings treten diese nicht mehr zur Wahl an oder sind unsicher, ob sie wiedergewählt werden. Daher hatte das Thema keine Priorität.
Von den grünen Abgeordneten erhielt ich zwei Antworten. In einem Fall ist eine neue Webseite in Arbeit. Die neue Seite soll dann auch Verschlüsselung unterstützen. Im anderen Fall war die Meinung, dass Verschlüsselung nicht notwendig ist, da alle auf der Seite angebotenen Daten öffentlich sind.
Bei der Linken konnte ich einen interessanten Effekt beobachten. Anfangs erhielt ich von den Abgeordneten individuelle Antworten. Ab einem Zeitpunkt kamen eine Art Standardantworten mit ähnlichem Wortlaut. Ich vermute, dass sie sich intern auf eine Sprachregelung geeinigt haben. Bei den individuellen Antworten gab es Abgeordnete, die klar schrieben, dass sie sich mit dem Thema bisher noch nicht auseinandergesetzt haben und noch nicht wissen, wie sie damit umgehen. In einem Fall erhielt ich eine verschlüsselte E-Mail mit Schlüssel und hätte künftig verschlüsselt kommunizieren können.
Insgesamt gibt es bei den Abgeordneten noch viel zu tun. Natürlich verwiesen viele auf die bevorstehenden Sommerferien und Wahlen. Daher werde ich die Wahlen abwarten und später nochmal bei den Abgeordneten nachfragen. Vielleicht wird Thüringen der Verschlüsselungs-Standort Nr.1.
mutt ist ein E-Mail-Programm für die Kommandozeile unter GNU/Linux. Das Programm wird über die Tastatur bedient und über eine Textdatei konfiguriert. Wer das innerhalb einer Firma verwendet bzw. auf Rechnern mit mehreren Nutzern, wird vermutlich ein schlechtes Gefühl haben, dort Passwörter zu hinterlassen. Für den Versand von E-Mails bzw. den Zugang zum Mailserver per IMAP muss meist ein Passwort angegeben werden. Das steht standardmäßig im Klartext in der Datei. Wie kann man sich schützen?
Die Lösung ist ganz einfach: Passwörter werden mit GnuPG verschlüsselt und mutt angewiesen, die Datei zu entschlüsseln. In der Passwortdatei stehen die Passwörter in einem Format, welches mutt versteht:
set imap_pass=“MeingeheimesIMAP-Passwort”
set smtp_pass=“MeingeheimesSMTP-Passwort”Anschließend wird dieses Datei mit GnuPG veschlüsselt. In die Konfigurationsdatei .muttrc kommt nun zusätzlich die Zeile:
source “gpg -d ~/.mutt/passwort.gpg |”Beim Start liest mutt die Konfiguration aus und startet GnuPG wie angegeben. Es muss das Passwort zur Entschlüsselung eingegeben werden und fertig ist alles.
Natürlich ist es sinnvoll, seine Festplatte oder das Home-Verzeichnis zu verschlüsseln. Denn manchmal gibt es andere Programme, die solche Informationen ebenso im Klartext hinterlassen.
Vielen Dank an Rainer für den Hinweis!
Letzte Woche hielten Roger und Jake vom Tor-Projekt einen Vortrag an der TU München. Die Veranstaltung war eher ein Marathon aus Fragen und Antworten. Dabei erwähnten die beiden auch, dass es unter Windows keine Möglichkeit gäbe, die Software GnuPG sicher herunterzuladen. Ein Versuch bestätigte das. Doch wie kann man als Windows-Nutzer auf sichere Weise zu der Software gelangen?
Verschlüsslung von Mails und Dateien unter Windows erfolgt mit gpg4win. Es gibt eine Downloadseite mit verschiedenen Versionen. Ein digitale Unterschrift zu jeder Datei wird ebenso geboten. Wo liegt also das Problem. Der Download der Dateien erfolgt über HTTP. Das kann beliebig manipuliert werden, ohne das der Anwender etwas merkt. In Ländern wie Syrien, die Bluecoat-Rechner einsetzen, ist die Manipulation der Verbindung bereits jetzt Realität.
Ich fragte bei Intevation, dem Betreiber der Server, nach einer Lösung. Mir schwebte eine SSL/TLS-Verbindung für die Webseite vor. Nach der Antwort ist der komplette Betrieb einer HTTPS-Seite zu aufwändig. Allerdings gibt es für den Fileserver ein selbst-signiertes Zertifikat. Das kann über eine spezielle Seite heruntergeladen werden.
Damit sind alle Komponenten zusammen, um zumindest dem erfahrenen Benutzer einen sicheren Download zu ermöglichen. Ihr solltet dabei folgendermaßen vorgehen:
Auf dem Wege hat zumindest ein erfahrener Nutzer die Chance, sicher an die ausführbare Datei zu kommen. Viel Spass beim Verschlüsseln!
Patrick Beuth hat für die ZEIT ein Experiment gemacht. Er stellte sich die Frage, wie schwierig es für Laien ist, sich anonym und sicher zu bewegen. Diese Erfahrungen schrieb Beutch in der Serie »Mein digitaler Schutzschild« nieder. Für das Experiment kaufte er sich einen neuen Rechner und installierte Ubuntu. Später machte er sich Gedanken zu sicheren Verbindungen über VPN und Tor, nutzte E-Mail-Verschlüsselung mit OpenPGP und verschlüsselte die Festplatte. Die Artikel sind aus der Sicht eines neuen Benutzers geschrieben und sehr interessant zu lesen.
ZEIT Online macht sogar den Sprung vom Artikel in die Praxis und organisiert am 26. Februar eine CryptoParty. Dort zeigen Patrick Beuth und die Organisatoren der CryptoPartys in Berlin, wie die verschiedenen Werkzeuge zu benutzen sind. So wird die anfängliche Hürde, derartige Werkzeuge zu benutzen sicher kleiner.
Mein Mailprogramm mutt brachte mich kürzlich zur Verzweiflung. Denn beim Öffnen eines Mailordners wollte die Software jede E-Mail öffnen. Insbesondere bei verschlüsselten Mails wurde immer wieder nach dem Passwort gefragt. Enthielt der Ordner mal keine verschlüsselte E-Mail, so erschien immer noch die Meldung Kann keinen Mailcap-Eintrag für [MIME-Typ] finden.. Der MIME-Typ hängt vom eventuellen Anhang der Mail ab. Beispiele sind image/png, application/pdf oder anderes. Wie lässt sich das Problem nun lösen?
Immerhin wusste ich, dass die Probleme nach einem Update auf Ubuntu 12.04 begannen. Also vermutete ich das Problem bei Ubuntu. Allerdings zeigte ein Debian mit derselben Konfiguration gleiches Verhalten. In der Manpage von mutt suchte ich nach einem Debugging-Schalter. Den gibt es nicht. Jedoch lassen sich systemweite und lokale Variablen deaktivieren.
-n umgeht die systemweite Konfiguration und -F /dev/null legt den Ort der lokalen Konfiguration fest. In dem Fall bekommt mutt ein Dateiendezeichen (EOF) und nutzt also keine Konfiguration. Mit den Einstellungen trat das Verhalten nicht auf. Also zum nächsten VersuchBei knapp 100 kB an Konfigurationsdateien ist suchen natürlich leichter gesagt als getan. Glücklicherweise habe ich die Dateien mit source eingebunden. So kam ich vergleichsweise schnell auf eine Datei, die sich um die Farbgestaltung der Einträge im Index kümmert. Mit klassischer Binärsuche ging es dann weiter und nach etwa zehn Schritten fand ich den Übeltäter.
color index black black “! ~b .”
Dieser Eintrag macht bestimmte E-Mails »unsichtbar«. Ich erhalte immermal wieder Spam, der keinerlei Text im Nachrichtenteil enthält. Die obige Regel weist mutt an, den Body (~b) zu durchsuchen. Der Punkt trifft auf ein beliebiges Zeichen zu und das Ausrufezeichen negiert das Ganze. Insgesamt passt diese Regel also auf E-Mail, die keine Zeichen im Body haben. Alle diese E-Mails werden schwarz auf schwarzem Hintergrund gezeichnet.
Jetzt ist also klar, warum mutt unbedingt in diverse E-Mails schauen wollte. Denn nur so kann diese Regel angewendet werden. Also habe ich die zunächst rausgeschmissen. Sven Guckes wies mich später darauf hin, dass mit ~G PGP-Nachrichten ausgeschlossen werden können.
Ich bin mit meinem Mailprogramm nun wieder glücklich und freue mich auf neue E-Mails. :-)
Kürzlich hatte ich mit jemanden eine Diskussion über NNTP und Gnus. Dabei fiel mir auf, dass er die Datei, welche unter anderem Passworte enthält, verschlüsselt aufbewahrt. Im Verlauf des Gespräches kamen wir daher auf den EasyPG Assistent zu sprechen. Das ist ein Modus für den Emacs, der gute Unterstützung für GnuPG innerhalb des Editors bietet. Meine ersten Versuche damit liefen recht erfolgversprechend.
Bei Debian, Ubuntu und Co. muss einfach das Paket easypg installiert
werden. Debian installiert in
/etc/emacs/site-start.d/50easypg.el eine Datei, die den
Start des Modus’ übernimmt. Falls das bei dir nicht der Fall ist,
kannst du in deiner .emacs die Zeile (require
’(epa-setup)) eintragen. Danach steht dir der Easypg Assistent
zur Verfügung.
Das oben angesprochene Verhalten lässt sich erzeugen, in dem man die Endung .gpg an die Datei anhängt. Beim erstmaligen Speichern der Datei fragt der Modus nach dem korrekten Schlüssel:
Select recipents for encryption. If no one is selected, symmetric encryption will be performed. - `m’ to mark a key on the line - `u’ to unmark a key on the line [Cancel][OK] - E8CBC9EE886DDD89 User 1 <user1@example.org> - 3B9D09F31B30974B User 2 <user2@example.com> u 547EBEB15774924D Jens Kubieziel <jens.kubieziel@example.org>
Standardmäßig ist der Schlüssel markiert, zu dem es auch einen privaten Schlüssel gibt. Falls du einen anderen wählen willst, gehst du in die entsprechende Zeile und wählst den mit der Taste m aus. Nachdem diese Auswahl mit Enter bestätigt wurde, befindet sich eine verschlüsselte Datei auf deiner Festplatte. Beim späteren Öffnen der Datei wird der Emacs nach dem Passwort fragen und dir den Inhalt anzeigen.
Daneben arbeitet EasyPG sehr gut mit dem Dired-Mode zusammen. Mit zwei Tastendrücken lassen sich Dateien ver-/entschlüsseln, signieren etc. Laut Handbuch ist die Unterstützung für E-Mail ebenfalls gut. Das habe ich nicht getestet und kann dazu nichts sagen.
Insgesamt hat mich EasyPG sofort begeistert und gehört ab sofort zu den Emacs-Modi meiner Wahl.
Das nächste Keysigning steht an und wieder einmal stellt sich für alle Teilnehmer die Frage, wie man am besten alle Schlüssel unterschreibt. Ich nutze dafür caff und will euch im folgenden kurz eine Einführung in die Konfiguration des Programmes geben. Hoffentlich hilft das, leichter und schneller zu Ergebnissen zu kommen.
Die Software gehört bei Debian und darauf basierenden Distributionen zum Umfang der Distribution und wird im Paket signing-party ausgeliefert. Andere Distributionen können die Dateien aus dem Subversion auschecken.
caff wird über die Datei .caffrc gesteuert. Im folgenden sind einige Einstellungen genauer erläutert. Dabei reichen meist die ersten vier oder fünf genannten Einstellungen, um caff zum Laufen zu bekommen.
$CONFIG{’owner’} = ‘Max Mustermann’;
$CONFIG{’email’} = ‘mm@example.org’;
$CONFIG{’keyid’} = [ qw{01234567890ABCDE} ];
In den beiden Variablen legt ihr euren Namen, E-Mail-Adresse und die Key-ID eures Schlüssels fest. In der letzten Einstellung kann auch eine Liste von Schlüsseln stehen. Die Key-ID bzw. den Fingerprint eures Schlüssels erhaltet ihr durch Eingabe des Befehls: gpg --fingerprint emailadresse.
$CONFIG{’mail-template’} = <<’EOM’
Text der E-Mail
EOM
Diese Variable trägt den Text der E-Mail, die an die Adressaten verschickt wird. Ihr könnt dort beliebigen Text reinschreiben und auch Variablen lassen sich expandieren. So wird {$owner} durch den oben festgelegten Namen ersetzt, {$key} steht für die Key-ID und {@uids} ist ein Array über alle UIDs. In der Beispieldatei, die mitgeliefert wird, findet ihr auch ein Beispiel zur Anwendung dieser Variablen.
$CONFIG{’mailer-send’} = [ ‘smtp’, Server => ‘mail.example.org’, Auth => [’mm’, ‘GehHeim’] ];
Wenn ihr einen lokalen Mailserver habt, dann ist die obige Einstellung nicht nötig. Sie betrifft vielmehr Anwender, die üblicherweise Programme wie Thunderbird, Evolution etc. nutzen und ohne lokalen Mailserver unterwegs sind. Dann hier muss caff wissen, wie es die E-Mails versenden soll. Meist wird zum Versand ein Smarthost des Providers genutzt. Der Name des Mailservers wird oben eingetragen und innerhalb der eckigen Klammern nach Auth kommen die Zugangsdaten (Benutzername und Passwort).
$CONFIG{’keyserver’} = ‘subkeys.pgp.net’;
Es könnte sein, dass ihr einen anderen Keyserver als den obigen standardmäßig eingestellten Nutzer wollt. Dann solltet ihr subkeys.pgp.net durch den Keyserver eurer Wahl ersetzen. Im Allgemeinen ist dieser aber eine gute Wahl.
Die Software bietet noch eine Vielzahl weiterer Möglichkeiten zur individuellen Steuerung. Diese sind in der Handbuchseite zu caff erklärt. Wie ihr oben schon gesehen habt, hat jede Option den Aufbau $CONFIG{’optionsname’} = ‘einstellung’;. So könnt ihr auch die weiteren in der Manpage genannten Optionen belegen.
Nachdem alle Einstellungen getroffen sind, kannst du dich ans Unterschreiben machen. Das Programm muss mit einer Liste von Key-IDs aufgerufen werden. Doch woher kommen diese? Ich stelle bei den Keysignings, die ich leite, am Ende einen Keyring aller Teilnehmer zur Verfügung. Das macht es einfach, die Key-IDs zu extrahieren:
gpg --no-default-keyring --keyring=KEYRINGDATEI --with-colons --list-keys \
| awk -F: ‘/^pub/ { print $5 }’
Nun ruft ihr das Programm auf: caff -m yes -u 0x012345 KEYIDS. Die Variable -m steht dafür, die E-Mails ohne Nachfrage zu versenden. Es gibt vier Möglichkeiten, diese zu belegen und wer es will, kann die Einstellungen auch in der .caffrc treffen. Ich persönlich nutze hier lieber die Kommandozeile, um die Option zu übergeben. Mittels -u übergebt ihr die Key-ID eures eigenen Schlüssels. Auch diese Einstellung kann bereits in der .caffrc getroffen werden. Nach einem beherzten Druck auf die Entertaste geht die eigentliche Arbeit los. Ihr werdet Schlüssel für Schlüssel nach eurer Unterschrift gefragt und könnt unterschreiben.
Ich hoffe, diese Anleitung ist für Teilnehmer an einem Keysigning nützlich und hilft, den Aufwand auf ein Minimum zu reduzieren.
Foto von NoirinP.
Die Chemnitzer Linux-Tage 2009 kommen langsam wieder näher. Wer sich im März zu Linux und Co. informieren will, sollte sich das Wochenende unbedingt freihalten. Ich werde wieder die Keysigningparty organisieren. Wenn du daran teilnehmen willst, sende mir den Fingerprint (oder mindestens die Key-ID) deines PGP-Schlüssels. Der Schlüssel sollte auf einem Keyserver verfügbar sein. Ich werde den mit in die Liste der Teilnehmer aufnehmen und du kannst dann, ausgerüstet mit Stift, Ausdruck der Liste und einem Ausweisdokument, am Keysigning teilnehmen.
Viel Spass euch bei den Chemnitzer Linux-Tagen
Ich sinniere schon seit einiger Zeit, wie ich ausgehende E-Mails weitgehend automatisch verschlüsseln kann. Vor längerer Zeit stiess ich dabei auf das Perlskript von Martin Grandrath. Auf der Seite ist gut beschrieben, wie das einzurichten ist. Das problem am Skript ist die relativ lange Startzeit. Es vergehen in der regel mehrere Sekunden bis mutt einsatzfähig ist.
Vor kurzem unterhielt ich mich mit Jörg Sommer darüber. Er hat eine Lösung mit zsh-Mitteln gebastelt. Diese ist zudem noch wesentlich schneller als die obige Variante:
#!/bin/zsh
hook_name=send-hook
blacklist_file=$HOME/Mail/crypt_blacklist
output_file=$HOME/Mail/crypt_hook_list
setopt extendedglob
gpg_dump=( ${(f)“$(gpg --list-keys --with-colons)”} )
# filter out lines without @
people=( ${(f)"$(for line in ${(M)gpg_dump:#(pub|uid):*@*}; do
print ${“${(@s.:.)line}”[10]}; done)"} )
typeset -a -U addresses
# possible bad lines:
# • email@example.com -- only an address
# • name (<…>)
addresses=( ${${people%>}##*<} )
[[ -r $blacklist_file ]] &&
addresses=( ${addresses:#${(j:|:)~${${(f)"$(<$blacklist_file)"}:#\#*}}} )
print -l "$hook_name\t~A\tunset crypt_autoencrypt" \
"$hook_name\t'~t \""${(j:|:)addresses//./\\\\.}"\"'\tset crypt_autoencrypt" \
> $output_file
Was macht das Skript? Anfangs werden zunächst ein paar Variablen festgelegt und das erweiterte Globbing der zsh eingeschalten. In der Variable gpg_dump wird alsdann die Ausgabe von gpg --list-keys --with-colons gespeichert. Nun folgt ein wenig zsh-Magic. 
Die Anweisung hinter people entspricht in etwa der Shellzeile awk -F: ‘/^(pub|uid)/ { print $10 }’ gpg_dump, d.h. dort liegen dann alle E-Mail-Adressen, die auf den Schlüsseln angegeben waren. Schließlich wird für alle Adressen auf der Blackliste ein enstprechender Eintrag erzeugt und die Konfiguration in die Variable output_file geschrieben.Die Adressen in der Blackliste werden entfernt. Was übrig bleibt, schreibt das Skript in Datei, deren Name in output_file gespeichert ist. Dabei muss man beachten, dass mutt nicht unendlich viele Einträge akzeptiert. Es scheint eine Begrenzung irgendwo bei 200 Einträgen zu geben.
Das ist aus meiner Sicht eine gute Alternative zu Martins Skript. Solltet ihr Anmerkungen, Fragen, Kommentare haben, schreibt mir es unten rein oder schreibt direkt eine E-Mail an Jörg.
Update: Eine Zeile im Beitrag war ungenau formuliert. Nach einem Hinweis von Jörg habe ich das verbessert.
Es ist nicht mehr weit, dann startet in Magdeburg der gleichnamige Open-Source-Tag. Es gibt dort viele interessante Vorträge rund um Freie Software. Ihr erfahrt Neues über LaTeX und OpenOffice, lernt wie man sicher mit Tor und GnuPG kommuniziert, wie man mit GNU R Statistiken erstellt und vieles mehr.
Ich habe unter anderem das Keysigning übernommen. Falls ihr teilnehmen wollt, schickt mir euren Schlüssel bzw. die Key-ID per E-Mail und ladet euch dann die Liste der Teilnehmer herunter. Weitere Anwesiungen gibt es dann vor Ort.
Ich wünsche allen viel Spass beim Magdeburger Open-Source-Tag!
Eine der größten Veranstaltungen zu GNU/Linux beginnt in etwas mehr als einem Monat: die Chemnitzer Linux-Tage. Dieses Mal wird am ersten Wochenende im März das zehnjährige Jubiläum begangen. Wie all die Jahre zuvor, gibt es eine Reihe interessanter Vorträge und Workshops. Nach dem erfolgreichen Test im letzten Jahr bieten die Organisatoren auch dieses Mal einen Workshop on demand an, d. h. wenn du gern einen Workshop zu einem bestimmten Thema hättest, meldest du diesen an und wenn sich ein Kundiger findet, hält er diesen mit dir. Ich habe im letzten Jahr einen solchen Workshop zu Tor geleitet. Er ist mir in guter Erinnerung geblieben, da ich mit wenigen Leuten detailliert auf deren Fragen eingehen konnte.
“Meine” Veranstaltung ist, wie fast jedes Jahr, das Keysigning. Falls noch nicht geschehen, solltet du dich anmelden, in dem du die KeyID oder den Schlüssel selbst an mich sendest. Ich nehme diesen dann mit in die Liste der Teilnehmer auf. Zum Keysigning bringst du dann einen Ausdruck der Liste, deinen Ausweis sowie einen Stift mit und folgst meinen Anweisungen. ,;-)
Ich wünsche euch viel Spass bei den Chemnitzer Linux-Tagen!
Die LUG Jena trifft sich an diesem Donnerstag, dem 2008-01-17, zum regelmäßigen Stammtisch. Neben verschiedenen Gesprächsthemen ist auch ein größeres Keysigning angesetzt. Falls du dich gerade in Jena befindest und dein Web of Trust erweitern willst, komm um 19:00 Uhr in die Quere No.1 und bring deinen Ausweis, einen Ausdruck deines Fingerprints sowie einen Stift mit.