Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Ok, here's an example with enough tools to handle most of the common cases. For now you can get these tools from svn://svn.kitenet.net/joey/trunk/src/packages/unreleased/jetring/ [EMAIL PROTECTED]:~ls jetring changeset-accept* changeset-review* keyring-gen* changeset-apply* keyring-explode* [EMAIL PROTECTED]:~export PATH=$PATH:~/jetring [EMAIL PROTECTED]:~cd ~/tmp/debian-keyring-2005.05.28/keyrings [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringskeyring-explode emeritus-keyring.pgp emeritus-keyring emeritus-keyring/add-17D57681 emeritus-keyring/add-6F7267F5 emeritus-keyring/add-B269698D emeritus-keyring/add-647B8331 emeritus-keyring/add-64433805 [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringshead emeritus-keyring/add-001B3BA1 Comment: extracted from emeritus-keyring.pgp by keyring-explode Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.6 (GNU/Linux) mQBtAzI+bhkAAAEDAOn0rvREGipkloa17NRJcSHweJJuhGo5EIPM3XDXbfXF4j18 TBWgGisic/QqtGvOwVVgQitS1evqOHgcRrNOPc/0tOuruR8qtEX33ypwjiZlK30M evm8E9wUEkkpABs7oQAFEbQnQmpvcm4gQnJlbmFuZGVyIDxiam9ybkBicmVuYW5k ZXIucHAuc2U+iQB1AwUQM9T0FhQSSSkAGzuhAQEJTQL9FF2qV4aBYgWKdKu4MdG6 [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringshead emeritus-keyring/index 9c55ce36c00df3d6edec08106db06be1 add-17D57681 9316b0b1f37b97d99336df760deac6ef add-6F7267F5 e2480c78d9b39694775f6bec21023e9b add-B269698D f868db4c2eff8751e8fdc53d6b105c0b add-647B8331 c68795f636ecf52fa6cdff7e71b18915 add-64433805 0836a942d9aa1ca54c9976969a26380c add-DEA67011 5f1af519711e704104550ce984d6033c add-B1CE8961 7c646b8bb334684d164147221c407424 add-5BB0DA6D 4627e1f9cc0c91cfbb5e2c5a3adb45b9 add-FA00F50D 6e64f607284940c6842932f1bf55b4bc add-ABB90E15 keyring-explode is a one-time operation, so a bit slow, but now the changesets are ready for use. First, let's rebuild the keyring from them, and compare to make sure no data is being lost (or added!): [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringskeyring-gen newring.gpg emeritus-keyring Applying emeritus-keyring/add-17D57681 ... gpg --import gpg: key 17D57681: public key Joel Klecker [EMAIL PROTECTED] imported gpg: key 17D57681: Joel Klecker [EMAIL PROTECTED] not changed gpg: Total number processed: 2 gpg: imported: 1 (RSA: 1) gpg: unchanged: 1 gpg operation complete ... Applying emeritus-keyring/add-F9033421 ... gpg --import gpg: key F9033421: public key Herbert Xu [EMAIL PROTECTED] imported gpg: key F9033421: Herbert Xu [EMAIL PROTECTED] 2 new signatures gpg: Total number processed: 2 gpg: imported: 1 (RSA: 1) gpg: new signatures: 2 gpg operation complete All changesets applied ok. [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsls -l newring.gpg emeritus-keyring.gpg -rw-r--r-- 1 joey joey 167537 Feb 24 02:03 emeritus-keyring.gpg -rw-r--r-- 1 joey joey 94855 Feb 24 02:06 newring.gpg [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsgpg --no-default-keyring --keyring ./emeritus-keyring.gpg --list-keys a [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsgpg --no-default-keyring --keyring ./newring.pgp --list-keys b [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsdiff -u a b --- a 2007-02-24 02:15:29.0 -0500 +++ b 2007-02-24 02:15:35.0 -0500 @@ -1,5 +1,5 @@ -./emeritus-keyring.pgp --- +./newring.gpg +- pub 1024R/17D57681 1996-06-26 uid Joel Klecker [EMAIL PROTECTED] uid Joel Klecker [EMAIL PROTECTED] @@ -161,10 +161,10 @@ pub 1024R/22714B25 1998-08-30 uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] -uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] uid Stephen Crowley [EMAIL PROTECTED] +uid Stephen Crowley [EMAIL PROTECTED] pub768R/21978C61 1996-08-13 uid Hubert Weikert [EMAIL PROTECTED] @@ -347,7 +347,6 @@ pub 1024R/8F23DC91 1994-12-20 uid Joe Reinhardt [EMAIL PROTECTED] uid Joe Reinhardt [EMAIL PROTECTED] -uid Joe Reinhardt [EMAIL PROTECTED] uid [EMAIL PROTECTED] uid [EMAIL PROTECTED] uid Joseph M. Reinhardt [EMAIL PROTECTED] Ok, no significant changes, only id rearrangement and dup removal. I've done the same for debian-keyring.gpg, with similar results, just took a bit longer. On to making changes.. [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringscat joeyh.retired Changed-By: Joey Hess [EMAIL PROTECTED] Comment: had to happen some day Date: Sat, 24 Feb 2007 02:18:51 -0500 Action: delete-key 788A3F4C Data: y [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-review newring.gpg joeyh.retired y gpg
Re: gpg changesets
On Sat, Feb 24, 2007 at 12:54:41AM -0500, Joey Hess wrote: I'm not sure what classes of changes keyring-maint typically makes so it seemed best to cover all of them. Please note that this is a direct cause of keyring-maint not communicating with the outside. The absence of documentation makes it awfully hard to produce things that actually help. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets
* Joey Hess: * Each change to the gpg keyring is stored in a separate changeset file. Changesets can reflect any set of changes to the keyring. Changesets can also include arbitrary metadata. * Changesets are never removed or modified, only new ones added. * There's an ordering of the changesets. This ordering is stored in an index file. The index file isn't necessary if you use hash-based chaining, like several SCMs relying on hash functions do (Monotone, GIT, probably Mercurial, too). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On Sat, Feb 24, 2007 at 12:54:41AM -0500, Joey Hess wrote: Sure, I just wanted to show it can be used for anything you'd do via --edit-keys. I'm not sure what classes of changes keyring-maint typically makes so it seemed best to cover all of them. There's a fairly detailed changelog in the debian-keyring package. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On Sat, Feb 24, 2007 at 01:59:07AM -0500, Joey Hess wrote:
How would you convert gpg --refresh-keys into changeset based
operations, I wonder? Maybe you could do it by something like: [...]
That's beautiful, if we can figure out what changed-keys is. :-)
Two ways: either parse the output of gpg as it's running:
gpg: requesting key CA57AD7C from ldap server keyserver.pgp.com
gpg: key CA57AD7C: PGP Global Directory Verification Key not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: requesting key DDD11D8A from hkp server subkeys.pgp.net
gpg: key DDD11D8A: Ted Percival (midg3t) [EMAIL PROTECTED] 74 new
signatures
gpg: Total number processed: 1
gpg: new signatures: 74
or run gpg --list-keys --verbose on the old and new keyring, and see
what differences you find.
I guess we need something that'll do that anyway, though. How about the attached
as a proof of concept?
] $ ./diffring.pl ./debian-keyring.list ./debian-keyring-aj.list
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -181)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -86)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +0, -191)
] Removed uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: 173)
or
] $ ./diffring.pl ./debian-keyring-aj.list ./debian-keyring.list
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +181, -0)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +86, -0)
] Updated uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: +191, -0)
] Added uid 1024D/788A3F4C-Joey Hess [EMAIL PROTECTED] (sigs: 173)
It works on the output of `gpg --verbose --list-sigs', which is a bit
slow on a full keyring. Oh well.
On Sat, Feb 24, 2007 at 03:04:57AM -0500, Joey Hess wrote:
[EMAIL PROTECTED]:~ls jetring
May Manoj's typos live forever :)
[EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringshead
emeritus-keyring/add-001B3BA1
Comment: extracted from emeritus-keyring.pgp by keyring-explode
Action: import
Data:
-BEGIN PGP PUBLIC KEY BLOCK-
No import date?
Ok, no significant changes, only id rearrangement and dup removal.
diffring.pl should deal with those fwiw. Doesn't deal with revocations, and
may not deal well with subkeys.
Cheers,
aj
#!/usr/bin/perl -w
# Copyright (c) 2007 Anthony Towns
# GNU GPL; v2 or later
# Gives an overview of what changed between two keyrings
use strict;
my $l = parse_keyring($ARGV[0]);
my $r = parse_keyring($ARGV[1]);
foreach my $ku (sort keys %{$l}) {
if (not defined $r-{$ku}) {
my $n = @{$l-{$ku}};
print Removed uid $ku (sigs: $n)\n;
} else {
my $a = $l-{$ku};
my $b = $r-{$ku};
my ($i, $j) = (0,0);
my ($del, $add) = (0,0);
while() {
my $A = $a-[$i] || G;
my $B = $b-[$j] || G;
# avoid dupes:
if ($i 0 $A ne G $A eq $a-[$i-1]) { $i++; next; }
if ($j 0 $B ne G $B eq $b-[$j-1]) { $j++; next; }
# compare:
my $x = $A cmp $B;
if ($A eq G and $B eq G) { last; }
if ($x == 0) { $i++; $j++; next; }
if ($x 0) { $add++; $j++; next; }
if ($x 0) { $del++; $i++; next; }
}
if ($add or $del) {
print Updated uid $ku (sigs: +$add, -$del)\n;
}
}
}
foreach my $ku (sort keys %{$r}) {
if (not defined $l-{$ku}) {
my $n = @{$r-{$ku}};
print Added uid $ku (sigs: $n)\n;
}
}
sub parse_keyring {
my $k = shift;
my $fd;
#open $fd, gpg --no-default-keyring --no-auto-check-trustdb --keyring $k --verbose --list-sigs | or die couldn't open keyring $k: $!;
open $fd, $k or die couldn't open gpg--list-sigs-output $k: $!;
my $x = build_key_hash($fd);
close($fd);
return $x;
}
sub build_key_hash {
my $f = shift;
my $keys = {};
my ($k, $u);
while ($f) {
chomp;
if (m/^\s*$/) {
# skip
} elsif (m/^pub/) {
$k = substr($_,6);
$k =~ s/\s.*//;
$u = undef;
} elsif (defined $k m/^sub/) {
$u = substr($_,6);
$u =~ s/\s.*//;
$keys-{$k-$u} = [];
} elsif (defined $k m/^uid/) {
$u = substr($_,21);
$keys-{$k-$u} = [];
} elsif (defined $k m/^rev/) {
# skip
} elsif (defined $k defined $u m/^sig/) {
push @{$keys-{$k-$u}}, substr($_, 13, 19);
} else {
#print XXX: $_\n;
}
}
foreach my $ku (keys %{$keys}) {
$keys-{$ku} = [ sort( @{$keys-{$ku}} ) ];
}
return $keys;
}
signature.asc
Description: Digital signature
Re: gpg changesets
* Anthony Towns: Two ways: either parse the output of gpg as it's running: gpg: requesting key CA57AD7C from ldap server keyserver.pgp.com gpg: key CA57AD7C: PGP Global Directory Verification Key not changed gpg: Total number processed: 1 gpg: unchanged: 1 Uh-oh. You really, really should use --with-colons --fixed-list-mode. In addition, you should keep an explicit list of primary user IDs; I don't think you should trust GnuPG's choice for this application (which will be poor unless you've assigned a lot of trust values, for which there isn't a real basis). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets
Florian Weimer wrote: The index file isn't necessary if you use hash-based chaining, like several SCMs relying on hash functions do (Monotone, GIT, probably Mercurial, too). True. The index file seems nice as a single file that can be signed, rather than needing to do (slow) signature checking on every changeset, though. -- see shy jo signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On 2/24/07, Joey Hess [EMAIL PROTECTED] wrote: Anthony Towns wrote: That's a technical issue, however -- one that seems like it should be emminently solvable. Ensuring that any such solution is written in a way that encourages auditability (of the code, of the input and of the output) is an important part though, and I don't know that anyone even has a good understanding of how that would be achieved. That probably means someone needs to try to implement it, and then we can see what doesn't work. Perhaps something like this: [ Very elaborate scheme snipped ] I would have though that the keyring maintenance needs much simpler tools. Is there really a need for editing individual keys? Looking at the quote ] (c) right now changes to the keyring are fundamentally unauditable ] unless they're done by a single person on a trusted machine with ] trusted scripts. There are a bunch of ways to solve this, but ] the best suggestion I've heard so far is something that breaks ] down the 17Mb binary blob of 'debian-keyring.gpg' into single key ] auditable chunks that can then be managed in a sane way. The ] scripts to do these would have to be simple first and foremost so ] they could be audited. it seems to me that a very simple solution would need 1. A trusted machine with a subversion (say) repository, to which only the keyring-assistants have access. 2. A directory in this repository with one *.key file for each key in the keyring. The *.key files should of course be in ACSII-armored format. 3. A three-liner script that creates the keyring by importing all the *.key file into an empty keyring, as AJT suggested. So when a keyring-assistant processes a keyring request, like My old key 0xDEADBEEF is obsolete, here is my new one 0x12345678, the assistant removes DEADBEEF.key and adds 12345678.key to the repository with a commmit messages including the email with the request. When the keyring maintainer has time, she verifies the commits, runs the script, and uploads the new keyring. The commits can be sent to a mailing list (or whatever) and other can see that things are moving along, and verify the keys if they are so inclined. Or... is my understanding of what kinds of requests the keyring maintainer gets wrong? Cheers, Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On 2/25/07, Joey Hess [EMAIL PROTECTED] wrote: Jens Peter Secher wrote: it seems to me that a very simple solution would need 1. A trusted machine with a subversion (say) repository, to which only the keyring-assistants have access. 2. A directory in this repository with one *.key file for each key in the keyring. The *.key files should of course be in ACSII-armored format. 3. A three-liner script that creates the keyring by importing all the *.key file into an empty keyring, as AJT suggested. Since that could be set up in 15 minutes, and this has been an unresolved for a year or two, I assume it doesn't meet keyring-maint's needs, and so I prefer to develop something that meets all needs I can envision. So, I am obviously missing some requirements here. I will very gladly help out if there is anything else that needs to be coded up. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Anthony Towns wrote: I guess we need something that'll do that anyway, though. How about the attached as a proof of concept? Nice output, but a bit buggy in my tests. I've changed it to use --with-colons, and keep the --with-colons output, so it looks like a diff. (I also added caching for speed.) [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringsdiffring foo3.gpg foo4.gpg -pub:-:1024:17:826FCAC21E880A84:1047319183:::-:::scESC: -uid:-1047319184::2993CFDACF30643F1A22EBD25A0E28086FD157B2::Frans Pop (Debian) [EMAIL PROTECTED]: -uid:-1116808856::16874BA594735C2647F63A853EFBAA373FD2E0FE::Frans Pop [EMAIL PROTECTED]: pub:-:1024:17:DADA79CD788A3F4C:-:::-:::scESC uid:--::558865A42A128E974449AF46596C86154E3F63B4::Joey Hess [EMAIL PROTECTED] uid:--::0D93ACA144ADD501DD5A3372FA0FCFD1E5DE3B29::Joey Hess [EMAIL PROTECTED] -uid:--::ECD310B7100369A24C3AA0FC4CC2A9D5DC74629B::Joey Hess [EMAIL PROTECTED] uid:--::4A5F289163A83EABBEA512B09FC99AE21947EE06::Joey Hess [EMAIL PROTECTED] sub:-:2048:16:3880BC071950ED18:-::e A switch could be added to futher process and prettify that, but as it is, it's useful for input to other tools, and it allows display of even the most obscure changes. Rather than a specialised tool to refresh keys from a keyserver, I wrote a more general tool that uses diffring to generate changesets between two keyrings. [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-gen foo3.gpg foo4.gpg merging my random changes delete-D523A6E660062884 modify-DADA79CD788A3F4C [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-accept debian-keyring delete-D523A6E660062884 [EMAIL PROTECTED]:~/tmp/debian-keyring-2005.05.28/keyringschangeset-accept debian-keyring modify-DADA79CD788A3F4C -- see shy jo signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Anthony Towns wrote:
On Fri, Feb 23, 2007 at 11:15:00PM -0500, Joey Hess wrote:
Changed-By: Joey Hess [EMAIL PROTECTED]
Comment: Removing an old email address.
I'm not sure that's plausible -- afaik the keyring gets synced to the
real keyservers for new signatures and uids, so removing addresses
doesn't work; though iirc you can do a revocation of a uid these days.
Sure, I just wanted to show it can be used for anything you'd do via
--edit-keys. I'm not sure what classes of changes keyring-maint
typically makes so it seemed best to cover all of them.
There should be some way of getting back to the original conversation
in case something goes wrong. I guess a field containing a URL to an rt
entry or similar would work?
Could be an url or even the whole message included, sure. I also left
out a Date field, which should be included.
Note that this is a relative changeset: its action depends on the
keyring it's run on, since it deletes uid 3 of 788A3F4C.
That means you can't reorder changesets easily. I wonder if it'd be
better say del uid [EMAIL PROTECTED] 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.
[EMAIL PROTECTED]:~cmp input.gpg TESTRING.gpg
[EMAIL PROTECTED]:~
Didn't you delete a uid as well as add and remove a key? Why aren't
there differences?
Because it's a review tool, so it's not intended to actually change the
input keyring. For that something like the attached would be used.
--
see shy jo
#!/usr/bin/perl
# Applies a changeset to a keyring.
use warnings;
use strict;
use File::Temp;
my @allowed_actions=qw(import edit-key delete-key);
my @gpgopts=qw(--command-fd 0 --no-auto-check-trustdb --no-default-keyring);
my $keyring=shift || usage();
my $changeset=shift || usage();
push @gpgopts, --keyring, $keyring;
my %fields;
my $field;
open(CHANGESET, , $changeset) || die $changeset: $!;
while (CHANGESET) {
chomp;
if (/^([^\s]+):(?:\s+(.*))?/) {
$field=lc $1;
if (defined $2) {
$fields{$field}=$2;
}
else {
$fields{$field}='';
}
}
elsif (/^\s+\.$/ defined $field) {
$fields{$field}.=\n;
}
elsif (/^\s+(.*)/ defined $field) {
$fields{$field}.=\n if length $fields{$field};
$fields{$field}.=$1;
}
elsif ($_ eq ) {
process() if defined $field;
%fields=();
}
else {
die parse error on line $. of $changeset;
}
}
close CHANGESET;
process() if defined $field;
sub process {
if (! exists $fields{action}) {
die $changeset missing action field;
}
my @action=split(' ', $fields{action});
my $command=shift @action;
if (! grep { $_ eq $command } @allowed_actions) {
die $changeset contains disallowed action \$command\;
}
if (! exists $fields{data}) {
die $changeset missing data field;
}
my $pid = open(GPG, |-);
$SIG{PIPE} = sub { die whoops, pipe broke };
if (! $pid) {
print gpg --$command @action\n;
exec(gpg, @gpgopts, --$command, @action) ||
die(failed to run gpg);
}
$|=1;
GPG-autoflush(1);
foreach my $line (split(\n, $fields{data})) {
print $line\n if $command ne 'import';
print GPG $line\n || die failed talking to gpg;
}
close GPG || die gpg exited nonzero;
print gpg operation complete\n\n;
}
sub usage {
die Usage: changeset-apply keyring changeset\n;
}
signature.asc
Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
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 [EMAIL PROTECTED] 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 signature.asc Description: Digital signature
Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
Anthony Towns wrote: 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. Ah, sure, as an optimisation it could be useful. However, I think that letting the keyring build tool operate in incremental mode during maintenance sessions (with one noninremental build at the end if desired) will make it fast enough. 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 :) That's beautiful, if we can figure out what changed-keys is. :-) BTW, I have a keyring-explode script that does similar for converting an existing monlithic keyring into changesets. (attached) -- see shy jo #!/bin/sh # Converts a keyring into a bunch of changesets, one per key. # Only intended to be used for initial import of keyring. set -e if [ -z $1 ] || [ -z $2 ]; then echo Usage: keyring-expode keyring changesetdir 2 exit 1 fi keyring=$(readlink -f $1) # gpg works better with absolute keyring paths changesetdir=$2 basename=$(basename $keyring) mkdir -p $changesetdir touch $changesetdir/index for key in $(gpg --no-default-keyring --keyring $keyring --list-keys|grep '^pub' | sed -e 's!.*/!!' -e 's/ .*//'); do out=$changesetdir/add-$key echo $out echo Comment: extracted from $basename by keyring-explode $out echo Action: import $out echo Data: $out gpg --no-auto-check-trustdb --keyring $keyring -a --export $key | sed 's/^/ /' $out echo $(md5sum $out | cut -d -f 1) add-$key $changesetdir/index done signature.asc Description: Digital signature
