Es wird ja immer wieder gerne darauf hingewiesen dass mit gnupg ein Tool für die Verschlüsselung der Massen existiert. Allerdings mehren sich seit längerem die Stimmen dass gnupg viel zu kompliziert und benutzerunfreundlich für den normalen Benutzer ist, und dem muss ich zustimmen. Ich will gar nicht erst mit Sachen wie dysfunktionalen Keyservern, der praktischen(!) Unmöglichkeit den Key zu validieren (keybase.io hat eine halbwegs praktische Lösung) und den mehr als umständlichen command-line-Parametern anfangen, ich gebe mal einfach ein konkretes Beispiel für meinen Anwendungsfall:

Ich habe mehrere Yubikeys auf denen sich u.A. sowohl Subkeys für SSH (jeweils separate pro Yubikey), Signing Keys (ditto) wie auch ein und der selbe Encryption Key (u.A. für https://www.passwordstore.org/) befindet. Die Idee ist es - egal mit welchem der Yubikeys - die Passwörter zu entschlüsseln, egal ob PC, Laptop oder Handy. Funktioniert an sich auch OK, wäre da nicht eine Kleinigkeit: gnupg tackert die Keys (genauer: Die Keystubs) an die ID der Smartcards (den Yubikeys) fest. Das bedeutet: Wenn ich nun die Yubikeys austausche und versuche auf den Key zuzugreifen, meckert GPG herum, ich solle doch die Smartcard mit der ID xyz einlegen, trotz der Tatsache dass sich der gewünschte Key auf dem angeschlossen Yubikey befindet.

Dafür gibt es einen Workaround: einfach ins .gnupg Verzeichnis gehen und die secret key stubs löschen (Verzeichnis private-keys-v1.d). Dabei natürlich aufpassen dass man nicht aus Versehen die falschen secret keys löscht - z.B. lokal generierte Schlüssel. Danach einen gpg --card-status machen und schon funktioniert es wieder (bis zum nächsten Wechsel des Yubikeys). Umständlich? Ja. Gefährlich? Ja. Dämlich? Mehr als das.

Dieser Bug existiert schon lange - und scheint nun endlich seit kurzem behoben zu sein (in 2.3). Die Begründung ist auch faszinierend (https://dev.gnupg.org/T4301):

In long-standing smartcard practice, one raw private key material should be only on a single physical device, no where other than that. This practice is still valid, I suppose. In other words, this even makes sense these days, because the purpose of having a private key on a dedicated device is to control it better, securely. You know, having more places means (in many cases) increasing attack surface despite the purpose.

Noch schöner:

Brains may be easily confused when same private key material exists in multiple similar devices.

Meine Reaktion darauf: WOLLT IHR MICH VERARSCHEN?

Es soll unsicherer sein den Schlüssel auf mehreren Hardwaretokens zu speichern - die gegen das Auslesen von den Schlüsseln geschützt sind usw - das Gehirn ist nicht in der Lage sich zu merken dass man Besitzer von mehreren Yubikeys (nebst Backup) ist und die benutzerfreundlichere Alternative zu dem ganzen Herumgehampel mit Löschen der secret key-Stubs wäre dann den entsprechenden Key nicht auf - den bedeutend sicheren - Hardwaretokens zu speichern sondern lokal überall zu verteilen? Soll das wirklich der Ernst von den gnupg-Leuten sein?

Himmel, ja es wird wirklich Zeit gnupg abzuschaffen und etwas benutzerfreundlicheres und praktischeres einzusetzen.


#gnupg #gnupgsucks

A Soyuz-2.1a rocket carrying the Yuri Gagarin manned spacecraft (Soyuz MS-18) and the crew of the long-duration expedition ISS-65 were launched from Baikonur Cosmodrome at 10:42 Moscow time on April 9.


#space #spaceshuttle #Gagarin #russian #First #astronaut #history

Hubzilla 5.4.2
- Fix translation plural variable
- Fix issue with following/unfollowing a thread
- Fix rendering of long text in xchan vcard
- Fix local link for rss content if rewrite author is sets
- Fix regression in mod display

Addons
- Pubcrawl: fix issue with following/unfollowing a thread
- Pubcrawl: more robust implementation of mastodon remote reply
- Photocache: remove suffix from the cached photo URL

This update contains security fixes. Please update ASAP!