[Savannah-hackers-public] Re: GPG-Signed Commits proposal

[Derek Price]

Sylvain Beucler wrote:

>I had in mind to sign what is stored in the RCS file, that is the
>commit-time content minus EOL conversions under MS Woe. AFAICS, that
>commit-time content is what you get using '-kb' later on. The verifier
>would check the signature before to perform keyword substitution (I
>assumed the client did the substitution, but maybe I'm wrong. In the
>worst case the file could be checked out twice, one in -kb for
>signature-checking and the other one with any keyword substitution).
>  
>

I forgot you had specified that the "Header" information would also be
signed.  As long as anything that could appear in a keyword also
appeared in the header, this is fine.

>I think the user can be trusted for maintaining the keyring, but I
>think a keyring could be specified, to avoid accepting signatures from
>people who have nothing to do in the development of the current
>repository.
>  
>

Perhaps the most generic thing to do would be to implement the gpg
command as a template in a config file (or on the command line).  Thus,
--gpg-sign "/usr/bin/gpg --keyring XXXX --sign %s", could allow the user
to set arbitrary settings, subbing the filename for %s?  Something
similar could be done for --gpg-verify.

>So the only work to get a canonical version just before the commit is
>to convert line endings on non-Unix platforms, except if we deal with
>a real binary file. Even a wrapper should be able to reimplement that
>transformation easily, shouldn't it?
>  
>

Yes.

>The verification, if done by a wrapper, needs to checkout the file
>twice (the normal checkout and the canonical/binary one), hopefully
>this could be optimized with a builtin solution.
>  
>

Checking out the file twice is definitely wrong.  A compromised server
can serve the "correct" file for signature checking and a corrupted file
for use.  If keyword substitution is to be allowed, any data to be
substituted into a keyword must also be signed and the client must do
the substitution.

>Is there something else than can change the content of a revision? Are
>there server-side hooks that can modify the content of the file
>itself? (as verifymsg does for the commit message?)
>  
>

There used to be a way to do that, and commitinfo probably could, but I
think it is mostly disabled or not used because of other problems it
caused (at the least, the committing user's sandbox becomes invalidated).

>4) Where to store the information?
>
>If the signature can be added as a new field in the RCS file without
>breaking backward compatibility, that would be great. The commit
>message is subject to modification by the verifymsg hook, so it be
>better to avoid it, I guess. The fact the commit log is changeable via
>'cvs admin' is not really an issue, since it would allow later
>additional signatures, though it would be better if such changes were
>append-only. If we store the information somewhere else, then a new
>'cvs admin' command would be needed so as to change the related
>signature as well.
>  
>

Again, any allowed keyword substitution who's source data is not signed
opens the client up to the attack I mentioned.  In this case it would be
the $Log$ keyword which could be used to insert arbitrary data.

>Do you think it's possible and reasonable to store all the signatures
>as a new RCS field?
>  
>

Yes.

>I think a 'cvs' (or an 'update/co/export') option would also be
>good. It needn't be default, and could be easily added to
>~/.cvsrc. Another tool to apply batch validation would be needed as
>well indeed.
>  
>

This would be nice.

>Another configuration option would be to specify which set of
>signatures you trust for a given repository.
>  
>

I like the idea of specifying a separate keyring via the gpg-verify
template.  This minimizes the amount CVS has to know about GPG.  It
would only need to know the (configurable) gpg-sign and gpg-verify
templates and pass a path to a file to them.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:address@hidden>