[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] mutt und pgp



>From the keyboard of Janto,

> Hallo Daniel,
> 
> * Daniel Bayer <daniel.bayer@stud.uni-rostock.de> [03-10-01 09:25]:
> 
> > > Mir manuell ein bcc zu schicken vergess ich leider meist, und kann dann
> > > die eigenen Mails nicht mehr lesen ;)
> > 
> > Einfacher ist es "encrypt-to <keyid>" in die Datei ~/.gnupg/options zu
> > schreiben. Dann wird auch immer für diesen Schlüssel verschlüsselt.
> > Man kann natürlich auch die Befehle, die mutt verwendet um gpg
> > aufzurufen entsprechend abändern.
> 
> Guter Tip. Kann ich auch noch irgendwo festlegen welche Mailadresse
> verwendet wird? Normalerweise wird wohl die erste im Keyring
> genommen...
> 
> $ gpg --edit-key janto
> [...]
> (1)  Janto Trappe <janto@sylence.de>
> (2). Janto Trappe <list@sylence.de>
> 
> ...hier aber offenbar nicht:
> 
> gpg: encrypted with [...] "Janto Trappe <list@sylence.de>"
> 
> Any ideas?

gpg nimmt automatisch die primäre UID. Diese ist seit 1.0.6
hinzugekommen und wird automatisch auf die neueste UID gesetzt.
Das modifizieren der primären UID ist erst in der nächsten Version
möglich. Da die cvs-version ziemlich viele Veränderungen mit sich
bringt, empfiehlt Werner Koch aber, diese auf garkeinen Fall im
Produktivbetrieb einzusetzen. 

Es gibt einen Workaround, der bei mir und einem Freund problemlos
funktioniert hat. 

Ich paste mal die Mail von Werner Koch aus der gnupg-user-ML:
Date: Tue, 1 May 2001 19:53:21 +0200
From: Werner Koch <wk@gnupg.org>
User-Agent: Mutt/1.3.16i
To: gnupg-users@gnupg.org
Subject: Ugly way to change the primary UID

On Tue, 1 May 2001, Waldemar Brodkorb wrote:

> Is it possible to change the primary uid?

We can't yet set the primary key id flag.  I think this ugly
workaround should help:

 1. Make a local copy of your public and your secret key.
   (use --export and --export-secret-key)
 2. Use deluid to remove all non-primary user IDs
 3. Use expire to change the expiration time of the main key
 4. Save
 5. Optional: Edit key again and change expiration time back to the
    old value.
 6. Wait one second (in case you are using a script)
 6. Use --import --allow-secret-key-import to import your
    backup public and secret key from step 1 again.

The newer signatures should take precedence over the ones from the
backup key and therefore you have one user ID with a newer timestamp
and in absence of a primary key flag, this one will count as primary
key.

I have not tested this and I know that it is ugly.

The plan is to have a self-signature update capability per user ID
which can the be used to change such things.  This will probably not
update the timestamp of the self-signature but just set it one
second ahead.  I am not sure on this point, though.

   Werner
------------------------------------------------------------------

bye
    Waldemar


Reply to: