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

[Sylvain Beucler]

Hello again,


Here're some more thoughs:


1) We need a canonical version of each revision to sign.

I figure one could get that canonical version using binary mode ('cvs
update -kb'). When the file is ready to be commited, it should match
that canonical version, except for line endings. Afaics keyword
substitution didn't occur yet, it's rather done at update time (if we
consider that 'cvs ci' performs an update after the commit per se).

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.


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?)


2) We need to specify the checksum

a) I though that we could directly use what GPG uses when 'gpg -a
-b'. I could not find what checksum is used exactly though. The
advantage is that we seamlessly follow GPG's evolution and don't have
to bother updating the checksum in use over the years.

b) Else we can use whatever checksum is considered secure today. We
just need to explicitely state what checksum was used in case it
changes in the future.


3) We need to sign more than the checksum,

else an attacker could put an old vulnerable version back to HEAD.

So we need to state different "assertions" about the code: the
checksum, the filename, the path, the revision, the date, the author,
the commit message. Maybe also the new commitid you mentioned.

With this the revision should be difficult to move around without
notice.

To avoid reply attacks, I see two ways to combine the information:

a) Sign a canonical representation of all these informations at
once. This may generate troubles later: for example if we want to add
the commitid to the signed informations, that requires a change to the
canonical representation (which maybe can be induced by the precense
of the commitid field).

b) Assign a unique ID to the revision and include it in all signed
information; still following the example of Monotone, this implies we
use solution b) for point 2), and that we include this checksum in all
signed information. The advantage is that we can put each information
as a separate signature, pile them up and hence add any new
information at any time in the future. the drawback is that it's more
easy to remove part of the signed information, and we lose the
maintenance ease from 2a).

It would also be good to consider multiple signatures of the same
revision (signed again by the package maintainer after an old key
expired or was revoked, for example)

We're still vulnerable to 'cvs admin -b' that changes the HEAD of a
given file to apparently any revision. Not sure how we can fix that
point :/


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.

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


5) Command line options

> True. You could also add somekind of a new cvs command to perform the
> checksum validation after checkout has finished on demand rather than
> doing it all of the time.

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.

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


Comments? :)

-- 
Sylvain


On Fri, Aug 19, 2005 at 06:50:07PM -0700, Mark D. Baushke wrote:
> Sylvain Beucler <address@hidden> writes:
> 
> > I wondered whether it would be possible to simply add commit
> > signatures to CVS (I'm getting challenged about that when trying to
> > improve the CVS installation at Savannah).
> 
> I am in favor of having gpg signed commit information to CVS.
> 
> > The simplest way I though of, would be to sign my commit message, with
> > additional 'Headers' specifying the user name and a SHA-1/MD5 hash of
> > the file in the current revision (without keyword expansion).
> 
> I believe that MD5 is not secure enough. I would suggest SHA-1 (or
> SHA-256) would be better.
> 
> Other than that, yes adding such a signature to your log message would
> be the easiest method to get the information to the CVS server. As you
> say, you would need to play some games to get around keyword expansion
> problems.
> 
> One gotcha might be that the log message itself may be changed at a
> later time using the 'cvs admin' command.
> 
> > Or more generally, perform something similar to Monotone, that is, add
> > a concatenation of signed assertions about the code.
> 
> Hmmm... Well, monotone has a slightly different model and I am not sure
> that the same assertions are as easy to find.
> 
> > The commit message would be bigger, but GPG-signed message are
> > 'blocks' that can easily be ignored or simplified by 3rd-party
> > software such as ViewCVS.
> 
> Agreed.
> 
> > A complete check would be long, with the need to compute each revision
> > and test it against the checksum, but we can't sign deltas, since CVS
> > uses (changing) reverse deltas. That check would be possible anyway,
> > and is usually needed only for the latest revision.
> 
> True. You could also add somekind of a new cvs command to perform the
> checksum validation after checkout has finished on demand rather than
> doing it all of the time.
> 
> > Does this sound plausible?
> 
> Yes.
> 
> > How much time do you think it would take to a good CVS hacker to
> > implement this in CVS (or even code this as an external wrapper?). If
> > you think that's possible maybe I could implement a prototype myself.
> 
> I am not sure how long it would take to hack CVS changes into place.
> 
> Having a signature for a given file as an attribute part of the delta
> record should not be that hard to do (we just recently added the
> commitid without too much trouble).
> 
> Doing it as an external wrapper should be fairly straight forward.