[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GPG-Signed Commits proposal
Re: GPG-Signed Commits proposal
Mon, 29 Aug 2005 22:20:30 -0400
Mozilla Thunderbird 1.0.6 (Windows/20050716)
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
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?
>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
>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?
>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
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.
Derek R. Price
CVS Solutions Architect
v: +1 717.579.6168
f: +1 717.234.3125