Re: [task #4633] GPG-Signed Commits

[Derek Price]

Another RFC re Signed Commits follows:

Sylvain Beucler wrote:

>Malicious people
>could resubmit old commits (with known security issues),
>  
>

It has been brought to my attention that I missed an obvious counter to
the replay-attack.  I propose simply having the client sign a sequence
number (probably delivered by the server at the time of commit) along
with committed data.  The server will then require that the sequence
number returned with the commit data be the same as it sent to the
client before it accepts each file.

I've come up with a few other ideas that avoid introducing the
additional client/server communication turn-around, but they all have
other flaws:

   1. Using timestamps in place of server-generated sequence ID: 
      Requires client clocks to be at least approximately in sync with
      the server.  Disallows more than one commit a second from clients
      without high-resolution clocks.
   2. Signing a random number which the server requires to be unique for
      all commits in its repository.  False-positives, which can break a
      commit, should be fairly rare with, say, a 64-bit random
      identifier, but portable methods of generating large,
      reliably-random numbers quickly appear to be rare.  This could
      also require many more resources on the server since it would have
      to store each of these identifiers and search the list for each
      new commit.  Over time, searching a list of thousands of commit
      ids could be cumbersome on a busy server.  Also, this does not
      address replay-attacks which originate from data in a second
      repository, with a separate list of commit identifiers.
   3. Have the server deliver a sequence id with every single client
      contact, including the read-only ones, before it is known what
      sort of request the client will deliver.  Even on a system with a
      32 bit unsigned long int (I think the maximum we can presume since
      long int is not actually required to be bigger that int by C89 and
      we can probably ignore 16-bit porting targets), it should take
      some time to reach the nearly 4.3 billion operation limit imposed
      by ULONG_MAX, but this does open the possibility of a DoS attack
      using read-only operations to attempt to max-out the sequence id. 
      (If no protection for overflow were built-in, this DoS could
      instead be a way to wrap the sequence id and trick a server into
      allowing old commits again, as well.)


One thought is to combine my original idea with #3 above, so that the
server hands out sequence-ids with every connection but decrements the
max-sequence-id counter when a client disconnects without using the id
for a commit.  This would require a little bit of complex code including
locks, DBM use, and additional cleanup handlers, but should be doable
and fairly fast on the server end.

None of this is quite as aesthetically pleasing as the original design
both because it may introduce an extra turn-around in the client/server
communication and because it will require that some additional signed
data be stored, so an external gpg/diff combination cannot be used to
verify files stored in a CVS workspace without some additional file
processing, but I am afraid this will be necessary.

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>