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. 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 ... > 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. 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. > 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. -- see shy jo
Attachment:
signature.asc
Description: Digital signature