On Sat, Feb 24, 2007 at 12:54:41AM -0500, Joey Hess wrote:
> > That means you can't reorder changesets easily. I wonder if it'd be
> > better say "del uid joeyh@master.debian.org" and have the tool work out
> > which uid (if any) that is.
> I don't feel that reordering changesets is a good thing in general, since
> it can lead to other problems (for example, reordering a key deletion to
> come before a key addition), and it loses history that can be useful for
> reviewing why and when a given change was made.
I was more meaning it as an optimisation so you could ignore "key
add 0x7172daed" if there was a "key delete 0x7172daed" changeset
later. Likewise a "uid add" followed by a "uid del" or whatever.
How would you convert "gpg --refresh-keys" into changeset based
operations, I wonder? Maybe you could do it by something like:
cp real-keyring.gpg tmpkeys.gpg
gpg --keyring tmpkeys.gpg --refresh-keys
for x in $(changed-keys); do
(
echo "Changed-By: me"
echo "Comment: new signatures/uids for key $x"
echo "Action: import --keyserver-options merge-only"
echo "Data:"
gpg --keyring tmpkeys.gpg --ascii --armour --export "$x" | sed -e 's/^/ /'
) > changeset-refresh-$x
done
rm tmpkeys.gpg
echo "Now you just have to apply changeset-refresh-* to real-keyring.gpg :)"
?
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature