On Tue, Mar 30, 2010 at 2:17 PM, Hyrum K. Wright <[email protected]> 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/
