Hallo Konrad,

Konrad Rosenbaum wrote:

On Friday 20 January 2006 22:52, Erik Schanze wrote:

...

ich bin gerade über einen Bug in KMail gestolpert, bei dem man E-Mails nur mit Schlüsseln verschlüsseln kann, die man auch signiert hat, und bin erstaunt, wie bockig die KMail-Entwickler mit dem Wunsch der Nutzer umgehen, diese Einschränkung einstellbar zu machen.

Falls Du mir einen wirklich guten kryptographischen Grund nennen kannst warum man das braucht, dann überlege ich mir, ob es sich lohnt sich mit Mark Mutz anzulegen... (er weiß normalerweise was er tut)

Ich finde es nicht im geringsten falsch, an jemanden verschlüsselt Emails schicken zu können, dessen Schlüssel ich nicht selbst signiert habe. Manchmal hatte man noch keine Gelegenheit, den Schlüssel persönlich zu überprüfen ($Empfänger wohnt halt zu weit entfernt oder sowas) und ich habe nur einen Trust-Path zum Schlüssel des Empfängers, kann ihm also für die Verschlüsselung trauen, aber das Vertrauensniveau reicht halt noch nicht zur Signierung des Schlüssels.

Ich verwende hin und wieder durchaus nicht von mir signierte Schlüssel zur Verschlüsselung einer Mail, aber das funktioniert mit mutt ja auch prima ;)

Konrad

Ciao, Thomas

Hi Erik, Liste,

Am Samstag, 21. Januar 2006 18:24, schrieb Erik Schanze:

Abgesehen von der frechen Bevormundung, die dem OpenSource-Gedanken, Software nicht nur nach eigenen Maßstäben, sondern nach den Wünschen der Nutzer zu entwickeln,

[widerspricht?]

In welchem Manifest steht denn so'n Quark? "Selber machen, bezahlen oder hoffen" ist eigentlich die Devise.

Wunschzettel werden ansonsten unter http://bugs.kde.org ausgefüllt... Am besten mit nem Patch als Bestechung...

Ja, das Leben ist so gemein. Bin aber nur der Bote, bitte nicht erschlagen.

Gruß Friedrich :)

On Saturday 21 January 2006 18:24, Erik Schanze wrote:

...

Falls Du mir einen wirklich guten kryptographischen Grund nennen kannst warum man das braucht, dann überlege ich mir, ob es sich lohnt sich mit Mark Mutz anzulegen... (er weiß normalerweise was er tut)

Warum muss der Grund "kryptographisch" sein?

Weil es gute kryptographische Gründe gibt genau das was Du willst nicht zu tun. (siehe unten)

Abgesehen von der frechen Bevormundung, die dem OpenSource-Gedanken, Software nicht nur nach eigenen Maßstäben, sondern nach den Wünschen der Nutzer zu entwickeln,

"Der" Open Source Gedanke ist eigentlich: wenn es Dir nicht gefällt kannst Du es fixen oder jemanden dafür bestechen/bezahlen. (Im Gegensatz zu: Du hast keine Chance je einen Fix zu bekommen.)

finde ich es sicherheitstechnisch bedenklich, den Vertrauensstatus eines Schlüssels im Schlüsselbund lokal anzuheben, nur um einen Bug einer Software zu umgehen.

Welcher Bug? ;-)

Wenn ich dann signierte Dokumente dieser Person erhalte, wird die Signatur als Vertrauenswürdig eingestuft, obwohl es eigentlich nicht so ist.

Dann solltest Du den Schlüssel nicht signieren. Im Übrigen sind Signaturen nicht vertrauenswürdig (trusted), sondern gültig (valid). Vertrauen kannst Du nur Personen (falls Konqueror das im Deutschen so anzeigt mach' bitte einen Bug auf).

Ich habe in diesem Fall den Schlüssel noch nicht selbst signiert, weil ich die Person noch nicht persönlich getroffen habe (und sicher auch nie werde),

Ja, das ist ein guter Grund nicht selbst zu signieren.

aber ich halte den Schlüssel zum Verschlüsseln für nutzbar,

Wie kommst Du auf diese Idee? Warum ist der Schlüssel für Dich authentifiziert? Wer/Was hat Dir die Identität bestätigt?

weil er über einen Vertrauens-Pfad mit meinem Schlüssel verbunden ist, nur nicht auf direktem Wege.

Path-of-Trust ist in OpenPGP ein prinzipiell mögliches, praktisch aber nicht vorhandenes Konzept, da die meisten Implementationen nicht zwischen "Identity-Signature" und "Trust-Signature" unterscheiden können oder diese Werte zumindest nicht exportieren. Aus dem selben Grund ist Web-of-Trust nur eine nette Illusion.

Falls der Schlüssel von jemandem signiert ist, dem Du vertraust, dann füge doch einfach so eine Zeile in Deine .gnupg/gpg.conf ein:

trusted-key 12345678abcdefgh

Du kannst diese IDs verwenden: * kurze KeyID (i.d.R. identisch mit den letzten 8 Stellen des Fingerprint) * lange KeyID (letzte 16 Stellen des Fingerprint) * kompletter Fingerprint

(Hinweis: Keys bei denen KeyID und Fingerprint nicht übereinstimmen sind v2 oder v3-Keys und 1. viel zu alt, um noch als sicher zu gelten, 2. in einem Format gespeichert, das Angriffe relativ einfach macht und deswegen nicht mehr sicher sind.)

Alternativ trag' es in Deine TrustDB ein (Beispiel: der Key der c't):

------------ $gpg --edit-key B3B2A12C [...] Command> trust ...: 4 ------------

"full" trust ist normalerweise der angemessene Wert dafür.

VORSICHT: Trust bedeutet dass Du dem Besitzer dieses Keys zutraust für Dich die Entscheidung zu fällen, ob ein Key wirklich dem behaupteten Besitzer gehören. Sprich: Du erkennst seine Signaturen genauso an, als ob es Deine eigenen wären.

Anderer Fall: Du bist dem Empfänger Deiner Mail noch nie selbst begegnet, aber Du bist aus einem anderen Grund (z.B. Telefonat mit Fingerprintaustausch) sicher, dass es der Richtige Key[tm] ist - was hält Dich noch von der Signatur ab? Persönliche Treffen sind die einfachste, aber nicht die einzige Methode einen Key zu checken.

Grund genug? ;-)

Nein.

Vielleicht setz' ich mich mal selbst ran, man braucht vielleicht bloß das Ausgrauen des "OK"-Knopfes zu verhindern. ;-)

Klingt logisch. Viel Glück. (Aber mach' Dir keine Hoffnung, dass Mark den Patch akzeptiert.)

Konrad

Hallo Rainer,

On Sat, 2006-01-21 at 14:08 +0100, Reiner Klaproth wrote:

Mein Workaround ist, die Schüler stets möglichst gestaffelt anmelden zu lassen, aber auf Dauer ist das keine Lösung.

Warum Legst du nicht einen Symlink an, der dafür sorgt, dass Zugriffe auf ~/.xsession-errors auf der lokalen Platte landen (z.B. in /tmp) ?

Ist zwar auch nur ein Workaround aber einer der keine Interaktion der Nutzer (gestaffeltes Anmelden) braucht.

Grüße Christoph

On Sat, Jan 21, 2006 at 02:08:14PM +0100, Reiner Klaproth wrote:

Hallo!

Hi Reiner,

Im Prinzip läuft es gut, aber: Seit KDE 3.4.3 oder KDE 3.5 wird bei vielen gleichzeitigen Anmeldungen der Server komplett überlastet. Das war vorher nicht. Ursache wahrscheinlich: Die Homeverzeichnisse sind per NFS eingebunden. Startet KDE, meldet der NFS-Server mehrere(!) Versuche, dass root auf die .xsession-errors des anzumeldenden Nutzers schreiben will, was der Server natürlich blockt (ich will auch keinen root-Squash haben!). Noch nicht herausgefunden habe ich, welche Prozesse hier offenbar suid root laufen.

Also, ein find über /opt/kde/bin liefert bei mir die folgende Liste der suid Programme:

fileshareset kcheckpass kdesud kgrantpty kpac_dhcp_helper

Ich würde ja mal auf kgrantpty tippen.

Ciao, Tobias