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
