Bug#474553: jetring-gen support for updating keys
Anthony Towns wrote:
The following changes Action: import to Action: import
--import-options=merge-only for patches that just modify a key
Good idea.
and introduces a Key-Info: section to make it easier to find a changeset
just by grepping.
Some overlap with d-m keycheck info, though I don't think I've ever
grepped that.
If you have a use case that involves grepping them all, wouldn't it be
better (though perhaps not easy to implement) for jetring-accept to add
the field, so it's consistently added to all changesets?
For checking keyservers for updated keyrings, this means we then say:
# save current keyring
cp $KEYRING ${KEYRING}.old
# get updated keys safely
gpg --no-default-keyring --keyring $KEYRING --list-keys --with-colons |
grep ^pub: | cut -d: -f5 | sort |
xargs -n 15 gpg --no-default-keyring --keyring $KEYRING \
--keyserver-options honor-keyserver-url=no \
--import-options=merge-only --recv-keys
# split out the changes
jetring-gen ${KEYRING}.old $KEYRING
# commit them
for x in modify-*; do
[ -e $x ] || continue; # maybe there weren't any changes
y=$(date +%Y%m%d)-$x
mv $x $y
jetring-accept $JETDIR $y
done
modify-0123456789ABCDEF will get repeated everytime new signatures
get added, so prefixing by date seems a reasonable way of avoiding it.
Perhaps it would be better for jetring-gen to optionally include a
datestamp in the output filenames. Or even do it by default for
modifiy-*. (The only one that's likely to occur multiple times for a
given key.) OTOH, jetring-accept will already suffix a changeset with
.$x if necessary to make it unique.
Anyway, the jetring-specific part of this can be simplified to:
for c in jetring-gen ${KEYRING}.old $KEYRING | grep '^modify-'; do
jetring-accept $DIR $c
done
(I wonder a bit why we went with a signed index instead of having patches
applied in filename order, and all prefixed by a date.)
Mostly, I think, so that it can be signed.
--
see shy jo
signature.asc
Description: Digital signature
Bug#474553: jetring-gen support for updating keys
On Mon, Apr 07, 2008 at 05:19:15PM -0400, Joey Hess wrote: and introduces a Key-Info: section to make it easier to find a changeset just by grepping. Some overlap with d-m keycheck info, though I don't think I've ever grepped that. Opaque files just bother me. If you have a use case that involves grepping them all, wouldn't it be better (though perhaps not easy to implement) for jetring-accept to add the field, so it's consistently added to all changesets? Hrm. We'd get that behaviour if jetring-accept worked something like: jetring-build -I $KEYRING $DIR jetring-review $KEYRING $CHANGESET $CHANGESET jetring-accept $DIR $CHANGESET I think. OTOH, jetring-accept will already suffix a changeset with .$x if necessary to make it unique. Oh, that sounds sufficient then. (I wonder a bit why we went with a signed index instead of having patches applied in filename order, and all prefixed by a date.) Mostly, I think, so that it can be signed. Hrm, we could equally well have just signed the output of find $DIR -maxdepth 1 -mindepth 1 | sed 's,^.*/,,' | grep '^[a-zA-Z0-9-.]*$' | sort too, though the only thing that buys us is having the index implicit in the directory. Heh, maybe what we really should be doing is treating the changesets as a linked list: add-foo: -BEGIN PGP SIGNED MESSAGE- Action: import Data: blah -BEGIN PGP SIGNATURE- ... -END PGP SIGNATURE- add-bar: -BEGIN PGP SIGNED MESSAGE- Previous-Changeset: add-foo Action: import Data: blahblah -BEGIN PGP SIGNATURE- ... -END PGP SIGNATURE- LAST-CHANGESET add-bar then you have ordering implied by the changesets themselves, so you get direct tracability for every changeset, and an authenticated ordering just falls out. Which means you don't have to sign two files when adding a changeset, and you never have to reconstruct anything from the VCS history -- so rather than having to find the commit that included the add-evilcracker changeset, and then see who signed index.gpg, you just have too look at who signed that changeset in the current tree. Which is to say you could implement jetring-blame without having to integrate it with a VCS. Inserting at the end is trivial (add a new signed changeset, and update LAST-CHANGESET), removing from the middle is easy-ish (replace the old changeset with a new, empty one), and changing stuff in the middle is possible but annoying, which seems entirely reasonable. You don't strictly need LAST-CHANGESET, you could just do a tsort on all the changesets, and check for: loops (x Prev-Changeset: y, y Prev-Changeset: x) branches (x Prev-Changeset: z, y Prev-Changeset: z) multiple heads (nothing has Prev-Changeset: x _or_ Prev-Changeset: y) Actually, that's trivial -- you just need to check: - the number of files referenced as prev-changesets is one less than the number of files you have - no file is referenced twice - all referenced files exist FWIW, attached is something that'll take a directory of changesets (.) and either die with an error if there's a problem, or print out the order they should be applied in. OTOH, for jetring-gen, you'd have to sign every changeset individually, rather than just do one signature. Maybe in that case it'd make sense to give it an option to dump a single changeset for all the updates (though keeping additions/removals in distinct changesets, I guess). Hrm, that might not be entirely as whacky as I first thought... Cheers, aj signature.asc Description: Digital signature
Bug#474553: jetring-gen support for updating keys
On Tue, Apr 08, 2008 at 01:45:30PM +1000, Anthony Towns wrote:
FWIW, attached is something that'll take a directory of changesets
(.) and either die with an error if there's a problem, or print out
the order they should be applied in.
*sigh*
Cheers,
aj
#!/usr/bin/perl -w
use strict;
my $dir = .;
my $head = undef;
my %next = ();
my %prev = ();
opendir DIR, $dir or die can't opendir $dir;
while (my $chset = readdir DIR) {
next if ($chset eq . || $chset eq ..);
my $path = $dir/$chset;
next if (! -r $path);
open CHSET, $path or die can't open $path;
while(CHSET) {
chomp;
next unless /^Prev-Changeset:\s*(\S.*)$/;
my $p = $1;
$prev{$chset} = $p;
if (defined $next{$p}) {
die branch: $p - $chset and $next{$p};
}
$next{$p} = $chset;
last;
}
if (not defined $prev{$chset}) {
if (defined $head) {
die multipled heads: $chset, $head\n;
}
$head = $chset;
}
close CHSET;
}
my @res = ($head);
for (my $c = $head; defined $next{$c}; $c = $next{$c}) {
push @res, $next{$c};
}
if (scalar(@res) lt scalar(keys %prev)) {
die some changesets in a loop;
}
print join(,, @res).\n;
signature.asc
Description: Digital signature
Bug#474553: jetring-gen support for updating keys
On Tue, Apr 08, 2008 at 01:45:30PM +1000, Anthony Towns wrote: add-bar: Previous-Changeset: add-foo Inserting at the end is trivial (add a new signed changeset, and update LAST-CHANGESET), removing from the middle is easy-ish (replace the old changeset with a new, empty one), and changing stuff in the middle is possible but annoying, which seems entirely reasonable. OTOH, in order to merge two trees, you'd need to go from: d---e / a---b---c and a---b---c \ x---y to d---e / \ a---b---c \ \ x---y (requiring resigning x) or d---e / \ a---b---c M \ / x---y with c having two descendents, and M having two parents; and possibly being able to have M as a no-op otherwise, so you can do merges without having to have an additional changeset. You'd also have to pull out a distinct ordering from that (presumably based on the order of the children in M -- an ordered, depth-first descent would probably be all it'd take). That assumes merging is actually something we care about, which it might not be. Cheers, aj signature.asc Description: Digital signature
Bug#474553: jetring-gen support for updating keys
Package: jetring
Version: 0.12
Severity: wishlist
Tags: patch
The following changes Action: import to Action: import
--import-options=merge-only for patches that just modify a key, and
introduces a Key-Info: section to make it easier to find a changeset
just by grepping.
For checking keyservers for updated keyrings, this means we then say:
# save current keyring
cp $KEYRING ${KEYRING}.old
# get updated keys safely
gpg --no-default-keyring --keyring $KEYRING --list-keys --with-colons |
grep ^pub: | cut -d: -f5 | sort |
xargs -n 15 gpg --no-default-keyring --keyring $KEYRING \
--keyserver-options honor-keyserver-url=no \
--import-options=merge-only --recv-keys
# split out the changes
jetring-gen ${KEYRING}.old $KEYRING
# commit them
for x in modify-*; do
[ -e $x ] || continue; # maybe there weren't any changes
y=$(date +%Y%m%d)-$x
mv $x $y
jetring-accept $JETDIR $y
done
modify-0123456789ABCDEF will get repeated everytime new signatures
get added, so prefixing by date seems a reasonable way of avoiding it.
(I wonder a bit why we went with a signed index instead of having patches
applied in filename order, and all prefixed by a date.)
I wonder if there should be a jetring command that just does the above?
jetring-update-from-net or whatever.
--- jetring-gen 2007-12-10 03:04:01.0 +1000
+++ jetring-gen 2008-04-06 23:31:57.0 +1000
@@ -29,17 +29,20 @@
if (/-pub:/) {
genchangeset(delete-$fields[4],
delete-key $fields[4],
- y);
+ y,
+ getlistkey($fields[4], $old));
}
elsif (/\+pub:/) {
genchangeset(add-$fields[4],
import,
- getkey($fields[4]));
+ getkey($fields[4]),
+ getlistkey($fields[4]));
}
elsif (/ pub/) {
genchangeset(modify-$fields[4],
- import,
- getkey($fields[4]));
+ import --import-options=merge-only,
+ getkey($fields[4]),
+ getlistkey($fields[4]));
}
}
close DIFF;
@@ -48,6 +51,12 @@
my $fn=shift;
my $action=shift;
my $data=shift;
+ my $desc=shift;
+
+ chomp($desc);
+ $desc=~s/^$/./mg;
+ $desc=~s/^/ /mg;
+ chomp($desc);
if ($data=~/\n/) {
$data=~s/^/ /mg;
@@ -59,6 +68,8 @@
Comment: $comment
Date: $date
Action: $action
+Key-Info:
+$desc
Data: $data
EOF
close OUT;
@@ -66,6 +77,13 @@
print $fn\n;
}
+sub getlistkey {
+ my $id=shift;
+ my $kr=shift || $new;
+ my $listkey=`gpg --no-auto-check-trustdb --option /dev/null
--no-default-keyring --keyring $kr --list-keys $id`;
+ return $listkey;
+}
+
sub getkey {
my $id=shift;
my $key=`gpg --no-auto-check-trustdb --options /dev/null
--no-default-keyring --keyring $new -a --export $id`;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
