Re: [task #4633] GPG-Signed Commits

[Derek Price]

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:derek@ximbiot.com>