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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2010-03-30 20:33:27 CEST