[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Security implications of fetching server content via checksum

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 30 Mar 2010 14:36:47 -0400

On Tue, Mar 30, 2010 at 14:33, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Mar 30, 2010 at 2:17 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> [I'm writing this now because the thoughts are fresh, and the list archive lasts forever.  This isn't really an issue until later releases, since we've currently no way to achieve this theoretical behavior.  Feel free to comment, but it won't hurt my feelings if this languishes for a while.]
>>
>> In New York last week, we talked a little bit about Editor v2 (Ev2), and the fetching of content from the server by SHA-1.  One of the benefits of wc-ng, and something that will be enabled by Ev2, is the ability for the client to request, and the server to send, content out-of-band.  By using SHA-1 hashes for content identification, clients will only need to request content they don't already have, such as the case where a pristine store already has most of the required content for an update or a checkout.
>>
>> This works fine when the repository is considered world-readable, but what happens for a repository with path-based access control?  What will prevent a reader from requesting content via SHA-1 that is should not have access to?  Sure, the odds of randomly guessing the SHA-1 for a protected path are pretty low, but some of our more paranoid users would prefer that it isn't even a possibility.  What if said content were both readable, as well as protected by path-based authz?
>>
>> Anyway, just some thoughts, and if my logic has some gaping holes, I'd love to know about 'em!
>
> I thought the process was going to work a little differently:
>
> * Client requests checkout/update of some path
>
> * Server responds with a skeleton of paths for the client to GET.
> These paths include the SHA1 (in addition to the name).
>
> * Client can now look into his cache to skip retrieving the file
> content for any SHA1 it already has
>
> * For other items client is still fetching the file based on the path name
>
> This would not have new security ramifications that I can see.

Agreed.

The SHA-1 is simply used to eliminate/constrain paths-to-fetch.

Cheers,
-g
Received on 2010-03-30 20:37:15 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.