Blog

Verschlüsselte Postkarte

AppleInsider stellt zwar noch einige verschlüsselte Messenger vor, hat aber eigentlich bereits resigniert:

And remember: if you wouldn't say or do something in public, it's wise not to send it across the internet, either. Even encrypted.

Нулевое доверие

Die größte Sorge des Auswärtigen Amtes in Bezug auf Cyberwar-Aktivitäten gilt nicht den Auswirkungen auf die kritische Infrastruktur in Deutschland oder der fehlenden Zurechenbarkeit von Angriffen, sondern der Bedrohung der vertrauensvollen Zusammenarbeit mit den russischen Strafverfolgungsbehörden durch Angriffe auf russische Systeme:

Wenn die selbst ernannten Online-Kämpfer einen deutschen Pass haben, ziehen die uns mit rein, verdeutlichte Grienberger. Da lasse sich dann nicht mehr unterscheiden, ob es sich um eine private oder staatliche Aktion handle. Wenn Russland auf uns zukommt und verlangt, die virtuellen Eindringlinge zu bestrafen, sind wir in einer schwierigen Situation. Es müsste daher dringend geklärt werden, wie kann man diese Leute wieder demobilisieren?

Man möchte sich gar nicht ausmalen, wie ungehalten die Russische Föderation auf eine verzögerte Auslieferung deutscher Hackerinnen reagieren würde.

Apfelhund

Einige Tage nach der konkreten Ankündigung von passkeys für die verschiedenen Apple-Betriebssysteme, ersten Katastrophenszenarien (die allerdings auch für MFA-Systeme einschlägig sind) und widersprüchlichen Heilsversprechen trägt Michael Tsai die naheliegenden Fragen vollständig zusammen:

I don’t understand the slide at the end where it says that Passkey protects against device theft but a password manager (maybe) doesn’t.

Other questions:

  • Can I get at my passkeys from Keychain Access?
  • Is there a way to manually back them up or move them between devices (other than manual AirDropping one at a time)? It would be nice to have a backup in cold storage rather than rely on a small number of devices that are all in the same building and connected to the same cloud account.
  • What happens if there’s a problem with the system or the site so that it doesn’t offer to auto-fill the passkey that I need? I’m thinking about cases where there are multiple or changing domains. It sounds like there’s no manual picker but that having one wouldn’t help because if it thinks the domain is wrong the passkey wouldn’t work, anyway.
  • This requires iCloud Keychain, yet someone may not want to put all of their passwords in iCloud. Is it practical to use a local keychain for some stuff alongside iCloud Keychain?
  • How well is this going to work in different browsers and across different platforms?

[...]

It sounds like anyone who can get into your Apple ID account and either see your phone notifications or redirect an SMS message can delete all your passkeys.

[...]

In what sense are passkeys locked to a device if they are syncing via iCloud Keychain? Is the idea that they must be on one of your devices because there is no way to export them?

Gegen aufkeimende Unsicherheit, ob passkeys wirklich die Antwort auf alle Authentifizierungsfragen sind, empfehle ich die wohltemperierte Prosa des einschlägigen Apple-Supportdokuments.

Der auf das Zusammenwirken von Apple und FIDO anspielende Titel dieses Blogposts hätte auch gut zur nostalgischen Hochstimmung rund um Clarus' Rückkehr gepasst, aber die Hundekuh und Druckdialoge im Allgemeinen interessieren mich deutlich weniger als Apples WebAuthn-Implementierung.

Targeted Release Schedule

Dass Vim 9.0 (Vim9 script!) und BBedit 14.5 (Tail Mode! finer-grained control over invisibles display!) zeitgleich (und wenige Tage nach der Abkündigung eines deutlich jüngeren Konkurrenzproduktes) veröffentlicht werden, hilft mir über die Vernachlässigung durch einen gewissen Hardware-Lieferanten hinweg.

Offline 2

Meinem Wunsch, iOS-Geräte auch ohne Netzzugang sinnvoll nutzen zu können, kommt der Webserver WorldWideWeb sehr entgegen. In der Theorie muss ich lediglich meine statische Website innerhalb meines iCloud Drive ablegen und WorldWideWeb starten, um sämtliche Seiten auch offline im Browser aufzurufen.

In der Realität scheitert das Vorhaben zunächst an der intelligenten iOS-Speicherverwaltung, die nur sehr widerwillig den Download ganzer Ordner zulässt – und WorldWideWeb findet nur lokal gespeicherte Dateien. Außerdem kämpft WorldWideWeb selbst mit dem iOS-Taskmanagement, das Hintergrundprozesse im Zweifelsfall sehr rasch beerdigt.

So bleibt auch nach vielen Jahren Offline Pages die beste Wahl für Reisen durch internetfreie Gegenden, wenn man die eigene Rezeptsammlung nicht missen möchte.

Zufallskunde

Apple erntet Anerkennung für die Re-Implementierung einer Serienbrieffunktion, zeigt aber in iOS Mail nach wie vor nicht ohne Weiteres die Empfängeradresse einer E-Mail an und entfernt Python und nano aus seinem Betriebssystem. Deutlicher kann das Unternehmen nicht machen, dass ich eigentlich nicht zu seiner Zielgruppe zähle.

Gesteuerte Digitalisierung

Meine Experimentierfreude in technischen Zusammenhängen endet bei der Steuererklärung. Weil das Elster-Projekt der Finanzbehörden bis 2013 eine Windows-Umgebung und/oder Oracle Java voraussetzte, nutze ich seit 2002 einen Online-Dienst, dessen einzige Funktion darin besteht, mich durch den Hauptvordruck und diverse Anlagen zu geleiten und anschließend ein PDF-Dokument zum Ausdruck zu generieren. Obwohl der Postversand einer unterschriebenen Steuererklärung zunehmend archaisch ist, halte ich an diesem Verfahren fest, bis die Finanzbehörden ein klares Zeichen setzen: Ab dem Veranlagungszeitraum 2021 werden papierne Erklärungen nicht mehr akzeptiert.

Zunächst versuche ich, dem vertrauten Online-Dienst ein Mandat für den Belegabruf und die digitale Übermittlung der Steuererklärung erteilen. Dieser Weg scheitert, weil ich in einem (verdrängten) Anflug von Digitalisierungsbereitschaft offenbar vor einigen Jahren bereits ein Mandat erteilt habe, das nicht zum jetzigen Projekt Steuererklärung 2021 passt (ERR-DIO-MISMATCH). Der Support des Online-Dienstes schlägt vor, das vorhandene Mandat über das Elster-Portal zu löschen. Das ist eine gute Gelegenheit, meinen elektronischen Personalausweis zum Einsatz zu bringen. Ich registriere mich mit dem Ausweis, lösche das Mandat und beantrage (innerhalb des Online-Dienstes) ein neues Mandat. Nun erscheint für mich eine neue Fehlermeldung (offener Genehmigungsantrag, ERR-APP-OPEN), während für die mit mir zusammenveranlagte Person weiterhin ERR-DIO-MISMATCH angezeigt wird.

Weil ich nun schon im Elster-Portal registriert bin, erteile ich Elster (und damit mir selbst) die Berechtigung zum Belegabruf. Der Belegabruf für die mit mir zusammenveranlagte Person funktioniert nicht, weil sie keinen elektronischen Personalausweis nutzt und die Freigabe daher über einen Schlüssel bestätigen muss, der ihr per Post zugeschickt wird. Ich kann ihre Daten allerdings auch (wie bisher beim Online-Dienst) manuell eingeben und die fertige Steuererklärung nach etwa 20 Minuten in elektronischer Form einreichen. Sogar eine Zustellung des Steuerbescheids per E-Mail wird mir in Aussicht gestellt. Wer hätte gedacht, dass mich ausgerechnet die deutschen Steuerverwaltungen zur Digitalisierung zwingen?

(Dieser Beitrag wurde auch im Techniktagebuch veröffentlicht.)

Nachtrag: Als Tierschutzverein mit stillgelegtem Postfach hätte ich vor 2022 bei meinen Elster-Aktivitäten größere Schwierigkeiten gehabt, aber die Finanzbehörden haben freundlicherweise Privatpersonen – anders als Tierschutzvereinen – eine vollständig digitale Steuererklärung erst nach der Beseitigung aller potentiellen Hürden abverlangt.

Backup 2022

Nach mehreren Ermahnungen auf Twitter ergänze ich meine allzu optimistische Datensicherung um einen weiteren Server für das CoreBackup und verschiebe das verschlüsselte CoreBackup.sparsebundle nach /Users/jan/Library/Mobile Documents/com~apple~CloudDocs, auf dass ein auf Europa begrenzter nuklearer Krieg meine Daten nicht hinwegfegt.

Schlüsseldienst

Ab einer bestimmten Anzahl von PGP-Schlüsseln wird die manuelle Veröffentlichung in einem Web Key Directory unpraktikabel. Das GnuPG-Paket enthält daher mit gpg-wks-client ein Werkzeug, das eine automatische Veröffentlichung ermöglicht. Ich beschränke mich auf die lokale Generierung der erforderlichen Dateien mit der Option --install-key. Durch den Aufruf –

gpg --list-options show-only-fpr-mbox -k '@eden.one'

– kann man den Input für gpg-wks-client erzeugen. Der Befehl liefert eine Liste von Fingerprints und UIDs für alle Schlüssel, in denen mindestens eine UID das Muster @eden.one enthält. Wenn also die Schlüssel weitere Domains erfassen, genügt @eden.one als einigendes Band. Allerdings werden so bekanntlich auch Schlüssel mit dem Status expired oder revoked berücksichtigt. Das Ergebnis muss daher durch einen invertierten grep-Aufruf laufen, der den unerwünschten Schlüssel ausfiltert:

gpg --list-options show-only-fpr-mbox -k '@eden.one' | grep -v xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | gpg-wks-client -v --directory /var/www/html/site/.well-known/openpgpkey --install-key

Im Prinzip ließen sich beliebig viele grep-Aufrufe verketten, aber in der Praxis ist dieser Workaround nur für einen oder zwei ungültige Schlüssel hilfreich. Das Ergebnis der obigen Befehlskette ist jedenfalls eine Ordnerstruktur für die fortgeschrittene WKD-Methode, und so verzichte ich schweren Herzens auf die direkte WKD-Methode und passe nginx.conf entsprechend an. Dank gpg-wks-client ist die dreijährliche Verlängerung von Schlüssellaufzeiten (mit dem expire-Kommando) nun auch unter WKD-Aspekten handhabbar.

Authentisch gesichert

Zwar gibt es keinen Grund, an der Authentizität meiner Backup-Benachrichtigungen zu zweifeln, aber nach der Wiedereingliederung von OpenPGP in den Mailstack möchte ich natürlich auch skriptbasierte E-Mails signieren. Um wohlgeformte E-Mails des MIME-Typs multipart/signed zu versenden, beschäftige ich mich noch einmal sehr intensiv mit den passenden Python-Modulen, akzeptiere nach einigen erfolglosen Bemühungen, dass das aktuelle API fehlerhaft/ungeeignet ist und verwende das legacy API auf Basis eines 10 Jahre alten Code-Schnipsels. Die Schmach wird etwas gemildert durch das Eingeständnis der Python-Dokumentation, dass mindestens email.mime nicht völlig überholt ist:

This module is part of the legacy (Compat32) email API. Its functionality is partially replaced by the contentmanager in the new API, but in certain applications these classes may still be useful, even in non-legacy code.

Das Versandskript benötigt neben diversen email-Modulen natürlich python-gnupg:

#!/usr/bin/env python3 import os import datetime import __main__ as main import smtplib from email.message import Message from email.mime.multipart import MIMEMultipart from email import charset from email.utils import make_msgid import keyring import gnupg smtp_server = 'mail.eden.one' smtp_user = 'user@eden.one' port = 587 localhost = 'client.eden.one' pgp_entry = 'PGP' pgp_user = pgp_entry def send_message(subject, body): now = datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S') subject = f'{os.path.basename(main.__file__)}: {subject}' body = f'{body}\n\n{now}' basemsg = Message() basemsg.set_payload(body, charset='utf-8')

Ohne den Parameter charset an dieser Stelle besteht basemsg nur aus dem Inhalt der Variablen body, die Angabe eines character sets erzeugt dagegen ein vollwertiges MIME-Objekt:

MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGV4dCBtaXQgw5xtbMOkdXRlbi4=

Nun ist es so, dass mutt (u.a. im Zusammenhang mit dem Parameter pgp_strict_enc zur obligatorischen Kodierung von Nachrichten mit trailing whitespace), der RFC 2045 für Text –

The Quoted-Printable encoding is intended to represent data that largely consists of octets that correspond to printable characters in the US-ASCII character set. [...] The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.

Rspamd sowie der RFC 2015 (etwas weniger deutlich sein Nachfolger RFC 3156) –

Though not required, it is generally a good idea to use Quoted-Printable encoding in the first step (writing out the data to be signed in MIME canonical format) if any of the lines in the data begin with "From ", and encode the "F". This will avoid an MTA inserting a ">" in front of the line, thus invalidating the signature!

– die platzsparende Kodierung quoted-printable bevorzugen. Um mich nicht des verschwenderischen Umgangs mit Speicherplatz und Bandbreite bezichtigen lassen zu müssen, erweitere ich das Skript um ein entsprechendes Charset()-Objekt und den charset-Parameter

base_charset = charset.Charset('utf-8') base_charset.body_encoding = charset.QP basemsg = Message() basemsg.set_payload(body, charset=base_charset)

– und erhalte:

MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Text mit =C3=9Cml=C3=A4uten.

Dasselbe Ergebnis erzielt man übrigens auch, wenn man basemsg das Charset()-Objekt nicht im Rahmen von set_payload(), sondern nachträglich zuweist (basemsg.set_charset = base_charset). Eine vorzeitige Zuweisung führt dagegen wieder zu einer base64-Kodierung, weil set_payload() den Effekt von set_charset überschreibt (anders als bei MIMEText()-Objekten, die mit vorzeitigen replace_header()- und set_charset()-Anweisungen offenbar besser umgehen können). Weiter im Skript:

basetext = basemsg.as_string().replace('\n', '\r\n')

Hier sind sich RFC 2015 und RFC 3156 einig:

The data to be signed MUST first be converted to its content-type specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence.

Nun muss eine Signatur erzeugt und in ein Message()-Objekt umgewandelt werden:

gpg = gnupg.GPG(gpgbinary='/opt/homebrew/bin/gpg') pgp_passphrase = keyring.get_password(pgp_entry, pgp_user) signature = str(gpg.sign(basetext, keyid='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', passphrase=pgp_passphrase, detach=True)) signmsg = Message() signmsg['Content-Type'] = 'application/pgp-signature; name="signature.asc"' signmsg['Content-Description'] = 'OpenPGP digital signature' signmsg.set_payload(signature)

Der Parameter gpgbinary für gnupg.PGP() ist bei einem Aufruf des Skriptes über eine Shell mit wohlgefülltem $PATH tückischerweise entbehrlich, aber spätestens bei der Einbettung via launchctl zwingend erforderlich. Schließlich werden die beiden Message()-Objekte in einem MIMEMultipart()-Objekt zusammengeführt:

msg = MIMEMultipart(_subtype="signed", micalg="pgp-sha512", protocol="application/pgp-signature") msg.attach(basemsg) msg.attach(signmsg) msg['From'] = 'Sender <sender@eden.one>' msg['To'] = 'Recipient <recipient@eden.one>' msg['Subject'] = subject msg['Message-ID'] = make_msgid(domain=localhost) smtp_password = keyring.get_password(smtp_server, smtp_user) s = smtplib.SMTP(host=smtp_server, local_hostname=localhost, port=port) s.starttls() s.login(smtp_user, smtp_password) s.send_message(msg) del msg

Der Datenverkehr wächst durch die Signatur und den MIME-Overhead je Nachricht (dank quoted-printable nur) um rund 600 Bytes, aber im Gegenzug gewährt Rspamd ein zusätzliches Symbol (SIGNED_PGP (-2)). Und ich kann sicher sein, dass mir niemand ein erfolgreich durchgeführtes Backup vorgaukelt.

Sommerputz

Dank der Entkopplung von Homebrew und uwsgi ist ein Update der Homebrew-Pakete (brew update; brew upgrade) kein Grund zur Nervosität mehr, auch wenn uwsgi wegen der veränderten Umgebung neu gestartet werden muss:

snafu % launchctl unload -w ~/Library/LaunchAgents/localhotel.snafu.uwsgi.plist snafu % launchctl load -w ~/Library/LaunchAgents/localhotel.snafu.uwsgi.plist

Allerdings benötigt das erneuerte Python frische Zugriffsrechte auf meinen Schlüsselbund, andernfalls scheitern alle Skripte, die das keyring-Modul verwenden.

Sicherheitsmail IV: Web Key Directory

Obwohl die PGP-Gemeinde eine gesunde Paranoia auszeichnet, wird PGP weiterhin regelmäßig für unsicher oder sogar obsolet erklärt, nicht zuletzt nach der Entdeckung der EFail-Schwachstelle. Interessanterweise setzt auch Apples Produktsicherheitsteam auf PGP für eine sichere Kommunikation, kann aber die für Apple Mail zuständigen Entwicklerinnen offensichtlich nicht bewegen, PGP nativ zu unterstützen.

Da mein MUA nicht (oder kaum) von EFail betroffen ist, vervollständige ich meinen überkomplexen Mailstack dennoch mit einer jahrelang vernachlässigten Komponente und richte trotz der fehlgeschlagenen Schlüsseldistributionsinitiativen der vergangenen Jahre ein OpenPGP Web Key Directory ein, denn:

Im Unterschied zu den bisher genutzten öffentlichen Key Servern werden beim integrierten Web Key Directory nur authentifizierte E-Mail Adressen inklusive des öffentlichen Schlüssels veröffentlicht. Über das integrierte WKD wird der E-Mail-Server des jeweiligen Anbieters zum maßgeblichen und zuverlässigen Bezugspunkt für den richtigen öffentlichen Schlüssel der jeweiligen E-Mail-Adresse. Denn durch ein Verifizierungsverfahren, idealerweise über die explizite Bestätigung des E-Mail-Nutzers selbst, werden öffentlicher Schlüssel und E-Mail-Adresse fest verknüpft. Eine Verwechselung kann somit weitestgehend ausgeschlossen werden.

Die WKD-Anleitung von Mike Kuketz ist sehr hilfreich, verführt mich aber an einer entscheidenden Stelle dazu, sämtliche Schlüssel zu einer E-Mail-Adresse zu exportieren/veröffentlichen (gpg --no-armor --export user@eden.one > ke39y8fkyw5j8uubuicshffo9hhudk4j), was zu verwirrenden Effekten führt. Andererseits kann ich diese Situation dazu nutzen, sauber signierte Nachrichten an gnugpg-users@gnupg.org zu senden (und sofort Hilfe zu bekommen). Werner Koch selbst nimmt meine Anfrage sogar zum Anlass, das Zusammenspiel von GnuPG und WKD zu überdenken. Ich fühle mich sehr geehrt.

Dank Homebrew verfüge ich bereits über ein aktuelles GnuPG und ein entsprechend kompiliertes mutt, gpgme funktioniert mittlerweile reibungslos, die Generierung modern gekurvter-Schlüssel ist rasch erledigt (gpg --full-gen-key), und da meine Domain zertifikatsbewehrt ist, gestaltet sich auch die WKD-Konfiguration denkbar einfach. Zunächst wird ein Verzeichnis im Webroot-Verzeichnis auf dem Webserver angelegt und innerhalb des neuen Verzeichnisbaums eine (leere) Policy-Datei erzeugt:

mkdir -p /var/www/html/mysite/.well-known/openpgpkey/hu touch /var/www/html/mysite/.well-known/openpgpkey/policy

Anschließend werden der WKD-Hash und der Fingerabdruck des PGP-Schlüssels ausgelesen –

gpg --with-wkd-hash --fingerprint user@eden.one

– um den öffentlichen Schlüssel dann im Binärformat in eine Datei zu schreiben, die den Namen des WKD-Hashes trägt:

gpg --no-armor --export $fingerprint > /var/www/html/mysite/.well-known/openpgpkey/hu/$wkd_hash

Zum Schluss benötigt nginx.conf eine Ergänzung –

location ^~ /.well-known/openpgpkey { default_type application/octet-stream; add_header Access-Control-Allow-Origin * always; }

– für die WKD-konforme Auslieferung des Schlüssels. Und schon:

snafu ~ % gpg -v --locate-external-key user@eden.one gpg: Note: RFC4880bis features are enabled. gpg: using pgp trust model gpg: pub ed25519/7CD6651792B3D1F8 2022-06-06 Snafu <user@eden.one> gpg: key 7CD6651792B3D1F8: "Snafu <user@eden.one>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: auto-key-locate found fingerprint xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx gpg: automatically retrieved 'user@eden.one' via WKD pub ed25519 2022-06-06 [SC] [expires: 2024-06-05] xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx uid [ultimate] Snafu <user@eden.one> sub cv25519 2022-06-06 [E] [expires: 2024-06-05]

Die WKD-Spezifikation unterscheidet zwischen einer direkten und einer fortgeschrittenen Methode –

The benefit of the advanced method is its greater flexibility in setting up the Web Key Directory in environments where more than one mail domain is hosted.

– und obwohl ich nur eine Domain abdecken muss, möchte ich mich nicht auf eine lediglich rückwärtskompatible Variante stützen, sondern den Fortschritt implementieren. Zu diesem Zweck werden ein DNS-Eintrag (A) für die Subdomain openpgpkey.eden.one und ein Zertifikat für die Subdomain benötigt:

certbot certonly -d openpgpkey.eden.one --nginx

Um die Pflege separater Verzeichnisstrukturen für advanced und direct zu vermeiden, ergänze ich nginx.conf so, dass Anfragen an https://openpgpkey.eden.one/.well-known/openpgpkey/eden.one/hu auf das bestehende Verzeichnis abgebildet werden (alle anderen Anfragen an die Subdomain werden auf die reguläre Website umgeleitet):

server { listen 443 ssl http2; server_name openpgpkey.eden.one; ssl_certificate /etc/letsencrypt/live/openpgpkey.eden.one/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/openpgpkey.eden.one/privkey.pem; location / { return 301 https://eden.one; } location ^~ /.well-known/openpgpkey/eden.one { alias /var/www/html/mysite/.well-known/openpgpkey; default_type application/octet-stream; add_header Access-Control-Allow-Origin * always; } }

Ab sofort können die vielen Menschen, die statt eines sicheren Messengers lieber einen WKD-fähigen MUA nutzen, mir mit etwas geringerem Aufwand verschlüsselte E-Mails senden und bei fehlerfreier Konfiguration und Anwendung etwas sicherer sein, den richtigen Schlüssel zu verwenden.

The Right Kind of Secure

Apple kündigt Unterstützung für den WebAuthn-Standard in einer künftigen macOS-Version an, und Mike Peterson ist noch etwas unschlüssig, wie die vielen Vorteile von passkeys widerspruchsfrei zu bewerben sind:

Also, passkeys can be backed up to iCloud and synced across your iPhone, iPad, and Mac devices in an end-to-end encrypted fashion. [...]

Passkeys also can't be phished or stolen in a data breach as easily as passwords can. Because they're stored on your device instead of a web server, they're much more resistant to data breaches.

In scharfem Kontrast zu Mr. Petersons Vertrauen in die iCloud steht die Perspektive der Debian-Gemeinschaft auf den Umgang mit PGP-Primärschlüsseln:

You should keep your private primary key very, very safe. However, keeping all your keys extremely safe is inconvenient: every time you need to sign a new package upload, you need to copy the packages onto suitable portable media, go into your sub-basement, prove to the armed guards that you're you by using several methods of biometric and other identification, go through a deadly maze, feed the guard dogs the right kind of meat, and then finally open the safe, get out the signing laptop, and sign the packages. Then do the reverse to get back up to your Internet connection for uploading the packages.

Behördenoptimismus

Unter den bundesweit verfügbaren Diensten, die mit einem elektronischen Personalausweis genutzt werden können, ist auch das Stasi-Unterlagen-Archiv, und so wird mir am 2022-06-07 (nach sorgfältiger Prüfung meines Antrags vom 2021-11-13, dessen Eingang am 2021-11-16 bestätigt wurde) politische Irrelevanz bis 1989 aus Sicht des MfS bescheinigt:

Die Recherchen in allen nach Ihren Angaben infrage kommenden Karteien haben ergeben, dass zu Ihrer Person keine Hinweis auf Unterlagen vorliegen.

Die Mitarbeiterin des Archivs weist mich allerdings darauf hin, es sei nicht gänzlich auszuschließen, dass bei weiteren Arbeiten noch Unterlagen zu Ihrer Person aufgefunden werden. Ich möge mich in etwa zwei Jahren erneut an sie wenden. Für diese ungebrochene Zuversicht, dass sich immer noch eine Akte finden lassen könnte, sollte es ein Wort geben.

Große Politik

Die Nuancen des diplomatischen Balletts sind mir fremd, aber die Tatsache, dass die klein gewachsenen Staats- und Regierungschefs der Ukraine und Deutschlands im Kontext des russischen Angriffskrieges von ausnehmend großen Herren (Wladimir Klitschko, Friedrich Merz, Ruslan Stefantschuk) aus dem jeweils anderen Land besucht werden, ist sicher kein Zufall.