Mark D. Baushke wrote: > - GPG-signed feature. > > + This means some way to have the server manage GPG key > material in some kind of a cvs server 'web-of-trust'.
Actually, I've only drawn up server verification of committers as an optional part of GPG-signed commits, and even if this is made part of the code, I don't think CVS needs to be aware of the key management (http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits#Server_Receives_Signature). CVS will know what command to run to verify the revision. If it returns an error then the commit is disallowed. The server administrator (and/or developers) would be made responsible for making sure the server's key ring has the correct keys, or even a configurable retry step introduced that allows gpg --recv-keys to be run to update a key ring if CVS encounters an unknown key, but the most important step is the client verification, I think. The server authorization already probably depends on SSH keys or somesuch. > + There is a need to deal with expired keys and revoked > keys as well as with successor keys. Yes, again, this is in my design document, though I chose to deal with expired and revoked keys by allowing users to resign old revisions if they wish: <http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits#New_Sign_Command>. It should be fine to just leave old (expired/revoked/whatever) signatures in place, and allow the newer signatures to provide verification, but I also noted a -d option for the resign command to allow expired/revoked/whatever signatures to be deleted. > + There may need to be a new way for a client to obtain > the public keys related to all files in the repository > as a part of a 'verify' operation... would this imply > running an hkp: or ldap: server on the cvs host, or > would cvs have additional client/server protocol put > in place to handle this? Neither. I would let the client configure whether they wish to automatically run `gpg --recv-keys' to receive unknown keys and what the exact command to do so would be. Thus, they could point their gpg at MIT's keyserver, www.keyserver.net, their CVS administrator's keyserver, or whereever they thought best. > + Client-side user-requested 'diff' replacement (to > allow validation of all versions related to a 'diff' > as well as to provide a replacement of 'diff' with > graphical or special-purpose comparisons (e.g., binary > difference engines or xml difference engines). This was noted in the design document <http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits#In_Conjunction_with_a_Merge>. It was also mentioned that a beneficial side-effect is that diffs against the BASE revision, a common operation, will no longer need to connect to the server <http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits#cvs_diff_against_Base_Revisions_can_Disconnect>. > + Client-side user-requested 'diff3' replacement (to > allow validation of all versiosn related to a 'merge' > operation as well as to provide a replacement 'diff3' > with a graphical or special-puposes merge operation > (e.g., allow a special-purpose program to merge > graphics or other 'binary' files). See above. Please, read the design document <http://ximbiot.com/cvs/wiki/index.php?title=GPG-Signed_Commits>, and if you still have further comments and questions, please let me know, or update the document. It's in a wiki. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
