On Mar 30, 2010, at 1:36 PM, Greg Stein wrote:
> 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.
Ah, okay.
Though, if we ever *do* put content in the repository into a hash-addressable-store of some kind (such as is currently kind of implemented with rep-sharing), it would make sense to implement a 'fetch by hash' API. We could disable this if there was any read-based authz in place, but it sure makes more sense to be able to directly get content, rather than translate it from path to hash to path again.
Then again, if fetching via a hash, the server would have to send full-text, since it wouldn't know what, if any, content the client had that it could deltify against.
-Hyrum
Received on 2010-03-30 20:51:27 CEST