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
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 f
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 fil
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)
> i
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 ou
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
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*
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
lett
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 gener
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 re
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; th
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 a
12 matches
Mail list logo
