Hallo zusammen,

bei der letzten Änderung (24. März 2009 13:28: http://wiki.ubuntuusers.de/GnuPG?action=diff&new_rev=123213&rev=114372) wurden auch sämtliche manuellen Anker gelöscht.

Wie steht das Wiki-Team dazu? Sollten die Anker wieder rein?

die manuellen Anker sind ja eigentlich überflüssig geworden. Ist halt nur die Frage, ob jemand drauf verlinkt hat...

martingr schrieb:

die manuellen Anker sind ja eigentlich überflüssig geworden.

Die automatischen Anker haben gewisse Schwächen. Hier ist bereits darüber mal diskutiert worden: http://forum.ubuntuusers.de/topic/anker-in-artikeln-loeschen/
Mein Hauptproblem damit ist, dass der Anker sich ändert, wenn eine Überschrift einfach nur etwas umformuliert wird.

Ist halt nur die Frage, ob jemand drauf verlinkt hat...

Eben. Sollte man von daher existierende Anker grundsätzlich nicht löschen (sofern der Bezugspunkt des Ankers nach wie vor existiert)?

Hallo,

Sollte man von daher existierende Anker grundsätzlich nicht löschen (sofern der Bezugspunkt des Ankers nach wie vor existiert)?

Eben das kann man nicht prüfen...

Eigentlich löschen wir keine manuellen Anker, außer, wenn der Ankername exakt der Überschrift entspricht. Ebenso progagieren wir ja auch nicht das setzen von manuellen Ankern.

Gruß, noisefloor

noisefloor schrieb:

Sollte man von daher existierende Anker grundsätzlich nicht löschen (sofern der Bezugspunkt des Ankers nach wie vor existiert)?

Eben das kann man nicht prüfen...

Nicht das wir uns falsch verstehen: Ich meinte damit, dass man Anker nur dann entfernen sollte, wenn der Anker keinen Sinn mehr macht. Wenn ich z.b. aus einem Artikel den Abschnitt "Probleme" entferne, dann sollte ich auch den entsprechenden Anker entfernen dürfen...

Eigentlich löschen wir keine manuellen Anker, außer, wenn der Ankername exakt der Überschrift entspricht. Ebenso progagieren wir ja auch nicht das setzen von manuellen Ankern.

Und der Vorteil, dass manuelle Anker nach wie funktionieren, auch wenn die entsprechende Überschrift leicht manipuliert wird, überzeugt nicht? Hier versagen die automatischen Anker ja.

Hallo,

nee, wir verstehen uns.

Wie das genau ist, wenn jemand einen manuellen Anker löscht müssten mal die sagen, die im Wiki die "Letzten Änderungen" kontrollieren - zu denen gehöre ich aber nicht...

Gruß, noisefloor

Servus,

hab ne kleine Frage: Sollte man vielleicht erwähnen, dass es beim erstellen von Schlüsseln auch einen "Experten-Modus" gibt? Mit

gpg --expert --gen-key

ist es auch möglich RSA Schlüssel zu erstellen, die ebenfalls zum Verschlüsseln geeignet sind.

Gruß Anubis

Hallo zusammen

Ich finde die letzte Änderung von Dark Wolf etwas falsch plaziert: Unter "Schlüssel auflisten" wird niemand nachsehen, wenn er einen Schlüssel auf ein anderes System übertragen will.

Abgesehen davon: Lassen sich Schlüssel wirklich derart von System A auf System B bringen? Würde das nicht existierende Schlüssel auf System B löschen?

Was meint ihr?

DrScott schrieb:

Hallo zusammen

Ich finde die letzte Änderung von Dark Wolf etwas falsch plaziert: Unter "Schlüssel auflisten" wird niemand nachsehen, wenn er einen Schlüssel auf ein anderes System übertragen will.

Abgesehen davon: Lassen sich Schlüssel wirklich derart von System A auf System B bringen? Würde das nicht existierende Schlüssel auf System B löschen?

Ja übertragen geht auf diese Art und Weise und ja es löscht die Schlüssel auf System B.

martingr schrieb:

Ja übertragen geht auf diese Art und Weise und ja es löscht die Schlüssel auf System B.

Dann wäre ich dafür, diesen Hinweis an dieser Stelle zu entfernen:

1. Gefährlich

2. Falscher Platz

Ich werde mal Dark Wolf kontaktieren, ob er nicht Lust hat, einen kompletten Unterpunkt zu formulieren, in dem dann auch die Tragweite des Vorgangs verdeutlicht wird. Vielleicht ja auch umfangreicher, also z.B. Übertragung von Keys auf ein Zielsystem, ohne die dort existierenden Schlüssel zu löschen...

DrScott schrieb:

martingr schrieb:

Ja übertragen geht auf diese Art und Weise und ja es löscht die Schlüssel auf System B.

Dann wäre ich dafür, diesen Hinweis an dieser Stelle zu entfernen:

1. Gefährlich

2. Falscher Platz

Ich werde mal Dark Wolf kontaktieren, ob er nicht Lust hat, einen kompletten Unterpunkt zu formulieren, in dem dann auch die Tragweite des Vorgangs verdeutlicht wird. Vielleicht ja auch umfangreicher, also z.B. Übertragung von Keys auf ein Zielsystem, ohne die dort existierenden Schlüssel zu löschen...

+1 - die Lösung ist nur geeignet, wenn man die Keys auf ein neues System übertragen will

Hi, Leute

Sorry, war wohl etwas zu voreilig. Hatte mich nämlich so geärgert über GPG. Hatte seit Wochen ein Lösung für mein Problem gesucht: http://forum.ubuntuusers.de/topic/problem-mit-dem-import-von-privaten-schluesse/

Von der Kommandozeile aus kann man die Schlüssel ja überhaupt nicht übertragen. Laut Manpage kann man nur die Öffentlichen Schlüssel exportieren. Also gut finden wir zusammen ne brauchbare Lösung für den Artikel. Ich werde die Dinge nochmal selber ausprobieren, wie man die Schlüssel übertragen kann so das sie verifiziert werden können, wobei aber die sich auf dem Zielsystem befindlichen Schlüssel nicht gelöscht werden.

mfg Dark Wolf

Ok, so funktionierst: http://forum.ubuntuusers.de/topic/problem-mit-dem-import-von-privaten-schluesse/#post-2095069

mfg Dark Wolf

So, habe die Änderung von Dark Wolf wieder entfernt und eine Alternative eingeführt. Dank an Dark Wolf, der den Stein ins Rollen gebracht hat

DrScott schrieb:

Unter KDE starte ich den Daemon über eine Datei, die unter /home/<user>/.kde/env/ liegt. Dieses Verzeichnis wird nämlich beim Start von KDE herangezogen, um KDE-globale Umgebungsvariablen setzen zu können. Unter GNOME gibt es sicherlich einen gleichartigen Mechanismus... In diesem Verzeichnis liegt bei mir eine Datei 'gpgagent.sh' mit folgendem Inhalt:

eval "$(gpg-agent --daemon)"

Dadurch ist dann in der gesamten KDE-Umgebung (inklusiv aller daraus gestarteten Unterprozesse) z.b. die Umgebungsvariable "GPG_AGENT_INFO" gesetzt. Das führt dann dazu, dass ein gpg-Befehl, der in einer Konsole (aus KDE gestartet!) abgesetzt wurde, ein Passwort per Dialogbox abfragt und eine zeitlang hinterlegt wird.

Wichtig ist also, dass das Programm, welches den Agenten verwenden soll, den entsprechenden Zugriff auf den Agenten kennt. Diese Kenntnis wird über den Inhalt der Variable "GPG_AGENT_INFO" erreicht.

Wenn der Daemon noch nicht läuft, dann kann dieser mir

gpg-agent --daemon

gestartet werden. Man erhält daraufhin in etwas:

GPG_AGENT_INFO=/tmp/gpg-IO2JHw/S.gpg-agent:12781:1; export GPG_AGENT_INFO;

Diese Information ist nur ausgegeben worden, aber nicht gesetzt worden. Zum Setzen kann man die gesamte Zeile in einer Konsole als "Befehl" ausführen. Das Problem: Dies wirkt sich dann nur in dieser Konsole bzw. in Programmen die von dieser Konsole gestartet wurden aus. Und genau darin liegt der Trick mit dem oben erwähnten Mechanismus. Hier wird der gpg-Agent zu einem sehr frühen Zeitpunkt gestartet und die GPG_AGENT_INFO-Variable an alle KDE-Prozesse weitervererbt.

Erstmal danke für die aufklärenden Worte.

Mir ist nun wieder eingefallen, was ich eigentlich erreichen wollte. Anders als vorher behauptet lief bei mir der gpg-agent schon, aber mit für meine Bedürfnisse unpassenden Einstellungen. Außerdem wusste ich nicht, wer ihn gestartet hat. Und als ich ihn selbst neu starten wollte wurde er nicht "erkannt", weil die Umgebungsvariablen nicht übergeben wurden (mir war damals nicht klar, dass das passieren muss).

Jetzt habe ich herausgefunden: Bei mir wird der Agent von

/etc/X11/Xsession.d/90gpg-agent

gestartet. Also habe ich direkt dort die Optionen für den Agenten angepasst (längere Speicherung der Passphrase im Cache). Das war auch erfolgreich.

Nun noch eine Frage: Kann man auch nachträglich die Optionen vom Agenten ändern? Ansonsten muss ich ihn immer erst killen, neu starten und auch das Programm, welches ihn benutzen soll neu starten. Das ist zum Testen recht aufwändig.

edit: jetzt fehlt die Originalantwort im Thread