Re: [task #4633] GPG-Signed Commits

[Derek Price]

Jim Hyslop wrote:

> Sequence ID 1 is unused, but 2 is used, so the server can't decrement
> the counter. It wouldn't be too difficult to mount a DoS attack on
> this scenario.
>
> I suppose there probably won't be more than a few (dozen? hundred?)
> users accessing the repository simultaneously, so it shouldn't be
> _too_ difficult to keep track of unused ids.


This is exactly what I had in mind - let the server remember what
sequence IDs it has handed out in a DBM or whatever, and only decrement
the counter when there are no higher numbers in the DBM.  i.e. if the
server hands out 1, 2, 3, 4, & 5, and 4 gets used, then when session 5
exits, the server decrements the counter back to 4, but simply ignores
sessions 1, 2, & 3 exiting.  Should be simple enough.  Not sure what
would happen with a really heavily loaded system.  Sylvain, can you give
us any statistics on Savannah?  Average number of concurrent users,
frequency of commits, frequency all users exit, etc.?

> And, of course, this means the numbers won't necessarily be sequential. 


This is not as important.  As long as the server verifies that the
session number returned signed by the client is the same as it handed
out (or completely ignores any client session numbers, forcing the one
it handed out), then a replay attack won't work unless the client
happened to get the same session number from the previous commit, which
shouldn't be possible with the same CVS server, as currently designed.

> Another possibility would be to add a new request/response command to
> the protocol, so a client explicitly requests a commit id. OTOH, this
> is, if anything, even more vulnerable to a DoS attack.


This is a good point, and I hadn't considered it.  That's an extra point
in favor of the previous idea.

> How does CVSNT generate its commit-id?


The same way we do, or at least, this was so until Mark committed some
code to make ours even more portable and secure.

It is a good point that commit IDs could be reused as session IDs, and I
had considered it but not made a final decision on it yet.  This may be
the way to go, as Mark Baushke, Paul Eggert, and I went to some lengths
to come up with a method of generation that is unlikely to generate
duplicates, but it still falls back on the PID when it can't find the
time and can't find a way to generate random numbers quickly.  This
isn't sure enough to generate unique IDs for portable use as signed
session IDs, I think - we just didn't think commit-IDs were worth the
trouble yet.

Mark, conversely, if a max-session ID does start getting used for the
signed-session ID, it could be reused as a commit-id guaranteed to be
unique.

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>