Re: Updated Debian Developers Keyring
Joey Hess wrote:
> Jonathan McDowell wrote:
> > jetring has some useful and interesting ideas, but the main
> > complaint I'd have about it as a method of managing keyrings is that
> > it takes on various roles that are already provided by the
> > underlying VCS and this duplication makes it more complex than
> > necessary.
>
> This is a complaint that I have about quilt and similar patch systems,
> but I do not call them a "mess" on #debian-devel. I accept that some
> people might have reasons to like these complications that do things
> that could be done by a VCS.
I don't frequent #debian-devel and I've never called jetring a mess; I
just wanted to point out that there may be reasonable arguments why
someone might choose not to use jetring (in the same manner people
choose not to use quilt or whatever). I think you've assumed I've been
derogatory about it in some manner that I haven't.
> Calling jetring "complex" is a bit of a mismoner, given that it
> consists of a mere 690 lines of code. That's 6x less code than ls.c;
> it's actually less code than is present in cat.c ...
I didn't call it complex either; I think the ideas in it are quite neat
and simple, I just said that /I/ think that some of its functions are
performed adequately by a VCS without the need for more help.
> > It also stores keys as their ASCII armoured versions, which I can
> > see little benefit to. If you store keys as individual binary blobs
> > then the process of assembling the complete keyring can be achieve
> > with cat.
>
> jetring changesets include various metadata. Storing binary blobs in
> files along with textual metadata is not very appealing.
That's not what I'd suggest; I'd suggest using the ability of the VCS to
store the metadata about who made the change and why, meaning the actual
object stored in the VCS is just the key itself.
> The concept of a changeset that represents any possible single change
> to a keyring is rather more useful than just catting binary files
> together. It allows for changesets that remove or modify keys, not
> just the addition of new keys. It allows workflows where changesets
> are created by third parties and mailed in for review.
If you have each key stored as a separate binary blob then you can use
the VCS to track changes, additions and deletions. cat is only used to
assemble a complete keyring for distribution, where gpg is used in
jetring (there's no reason you couldn't use gpg to assemble the binary
blobs except for the fact it doesn't buy you a whole lot and is slower).
> > jetring obviously works for the people managing the Debian
> > Maintainer's keyring, but that doesn't mean that it'll work for
> > everyone.
> That could be said about any tool ever developed. However, jetring was
> developed explicitly based on the ideas that James described for a
> tool to help manage the Debian keyring, and was initially tested using
> the Debian keyring, so I certianly believe it would be effective
> there. Unfortunatly, James has never replied to any of my mails about
> it.
I can't and don't speak for James (though I don't believe I've ever
heard him be negative about jetring). I really didn't intend to cause
offence in my suggestion that jetring might not be the answer, in the
same manner as I don't intend to cause offence because I use Debian
instead of Redhat.
J.
--
I like my copyright infringements to be patent free.
Reply to: