use a hash of the lock token as the suffix for PUT/MOVE
PATCH 1/1 use a hash of the lock token as the suffix for PUT/MOVE
After 753bc91 ("Remove the requirement opaquelocktoken uri scheme"), lock tokens are in the URI forms in which they are received from the server, eg. 'opaquelocktoken:', 'urn:uuid:'.
However, "start_put" (and consequently "start_move"), which attempts to create a unique temporary file using the UUID of the lock token, inadvertently uses the lock token in its URI form. These file operations on the server may not be successful (specifically, in Windows), due to the colon ':' character from the URI form of the lock token in the file path.
This patch uses a hash of the lock token instead, guaranteeing only "safe" characters (a-f, 0-9) are used in the file path.
The token's hash is generated when the lock token is received from the server in handle_new_lock_ctx, minimizing the number of times of hashing.
---
This patch is a result of the discussion on "[PATCH] use lock token in non-URI form in start_put"; you can read it at
http://kerneltrap.org/mailarchive/git/2009/2/7/4922094.
The decision to use a hash of the token is so that one can avoid handling the URI scheme of the lock token, which may be a deeply nested URI, or (the more likely scenario) contain "unsafe" characters for a file name, such as colons, slashes and spaces.
http-push.c | 11 ++++++++++- t/t5540-http-push.sh | 7 +++++++ 2 files changed, 17 insertions(+), 1 deletions(-)
http-push.c +10 -1
@@ -153,6 +153,7 @@ struct remote_lockchar *url;char *owner;char *token; +char *token_sha1_hex;time_t start_time;long timeout;int refreshing;
@@ -558,7 +559,7 @@ static void start_put(struct transfer_request *request)append_remote_object_url (&buf, remote->url, hex,0 );strbuf_addstr (&buf,"_" ); -strbuf_addstr (&buf, request->lock->token); +strbuf_addstr (&buf, request->lock->token_sha1_hex); request->url =strbuf_detach (&buf,NULL ); slot =get_active_slot ();
@@ -1130,6 +1131,8 @@ static void handle_lockprop_ctx(struct xml_ctx *ctx, int tag_closed)static void handle_new_lock_ctx (struct xml_ctx *ctx,int tag_closed) {struct remote_lock *lock = (struct remote_lock *)ctx->userData; +git_SHA_CTX sha_ctx; +unsigned char lock_token_sha1[20 ];if (tag_closed && ctx->cdata) {if (!strcmp (ctx->name,DAV_ACTIVELOCK_OWNER )) {
@@ -1142,6 +1145,12 @@ static void handle_new_lock_ctx(struct xml_ctx *ctx, int tag_closed) }else if (!strcmp (ctx->name,DAV_ACTIVELOCK_TOKEN )) { lock->token =xmalloc (strlen (ctx->cdata) +1 );strcpy (lock->token, ctx->cdata); + +git_SHA1_Init (&sha_ctx); +git_SHA1_Update (&sha_ctx, lock->token,strlen (lock->token)); +git_SHA1_Final (lock_token_sha1, &sha_ctx); + + lock->token_sha1_hex =sha1_to_hex (lock_token_sha1); } } }
t/t5540-http-push.sh +7 -0
@@ -94,6 +94,13 @@ test_expect_success 'MKCOL sends directory names with trailing slashes' ' ' +test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' ' + + grep -P "\"(?:PUT|MOVE) .+objects/[\da-z]{2}/[\da-z]{38}_[\da-z\-]{40} HTTP/[0-9.]+\" 20\d" \ + < "$HTTPD_ROOT_PATH"/access.log + +' + stop_httpd test_done
Signature · 1 line
1.6.1.2.278.g9a9e.dirty
Quoted 11 lines · Tay Ray Chuan
After 753bc91 ("Remove the requirement opaquelocktoken uri scheme"), lock tokens are in the URI forms in which they are received from the server, eg. 'opaquelocktoken:', 'urn:uuid:'.
However, "
start_put" (and consequently "start_move"), which attempts to create a unique temporary file using the UUID of the lock token, inadvertently uses the lock token in its URI form. These file operations on the server may not be successful (specifically, in Windows), due to the colon ':' character from the URI form of the lock token in the file path.
Quoted 8 lines
This patch uses a hash of the lock token instead, guaranteeing only "safe" characters (a-f, 0-9) are used in the file path.
The token's hash is generated when the lock token is received from the server in
handle_new_lock_ctx, minimizing the number of times of hashing.Signed-off-by Tay Ray Chuan <[email protected]>
Thanks, very clearly written.
http-push.c struct remote_lock · line 156
Quoted 9 lines
http-push.c +1
-0@@ -153,6 +153,7 @@ struct remote_lockchar *url;char *owner;char *token; +char *token_sha1_hex;
At this point, this new field is only used as a unique suffix, and "sha1_hex" is a implementation detail of the mechanism to guarantee the uniqueness. Naming things for what they are is preferred over naming things for how they are crafted. Hence:
char tmpfile_suffix[41];
would be a better definition here.
http-push.c static void start_put(struct transfer_request *request) · line 562
Quoted 6 lines
http-push.c +1
-1@@ -558,7 +559,7 @@ static void start_put(struct transfer_request *request)append_remote_object_url (&buf, remote->url, hex,0 );strbuf_addstr (&buf,"_" ); -strbuf_addstr (&buf, request->lock->token); +strbuf_addstr (&buf, request->lock->token_sha1_hex,41 );
And replace these two strbuf_addstr() with:
strbuf_add(&buf, request->lock->tmpfile_suffix, 41);
Quoted 10 lines
http-push.c +2
-0@@ -1130,6 +1131,8 @@ static void handle_lockprop_ctx(struct xml_ctx *ctx, int tag_closed)static void handle_new_lock_ctx (struct xml_ctx *ctx,int tag_closed) {struct remote_lock *lock = (struct remote_lock *)ctx->userData; +git_SHA_CTX sha_ctx; +unsigned char lock_token_sha1[20 ];if (tag_closed && ctx->cdata) {if (!strcmp (ctx->name,DAV_ACTIVELOCK_OWNER )) {
http-push.c static void handle_new_lock_ctx(struct xml_ctx *ctx, int tag_closed) · line 1153
Quoted 9 lines
http-push.c +6
-0@@ -1142,6 +1145,12 @@ static void handle_new_lock_ctx(struct xml_ctx *ctx, int tag_closed) }else if (!strcmp (ctx->name,DAV_ACTIVELOCK_TOKEN )) { lock->token =xmalloc (strlen (ctx->cdata) +1 );strcpy (lock->token, ctx->cdata); + +git_SHA1_Init (&sha_ctx); +git_SHA1_Update (&sha_ctx, lock->token,strlen (lock->token)); +git_SHA1_Final (lock_token_sha1, &sha_ctx); + + lock->token_sha1_hex =sha1_to_hex (lock_token_sha1);
The last one is wrong because string returned by sha1_to_hex() is volatile.
lock->tmpfile_suffix[0] = '_';
memcpy(lock->tmpfile_suffix + 1, sha1_to_hex(sha1));Other than that, I think this is a good patch.
After 753bc91 ("Remove the requirement opaquelocktoken uri scheme"), lock tokens are in the URI forms in which they are received from the server, eg. 'opaquelocktoken:', 'urn:uuid:'.
However, "start_put" (and consequently "start_move"), which attempts to create a unique temporary file using the UUID of the lock token, inadvertently uses the lock token in its URI form. These file operations on the server may not be successful (specifically, in Windows), due to the colon ':' character from the URI form of the lock token in the file path.
This patch uses a hash of the lock token instead, guaranteeing only "safe" characters (a-f, 0-9) are used in the file path.
The token's hash is generated when the lock token is received from the server in handle_new_lock_ctx, minimizing the number of times of hashing.
---
This patch is a result of the discussion on "[PATCH] use lock token in non-URI form in start_put"; you can read it at
http://kerneltrap.org/mailarchive/git/2009/2/7/4922094.
The decision to use a hash of the token is so that one can avoid handling the URI scheme of the lock token, which may be a deeply nested URI, or (the more likely scenario) contain "unsafe" characters for a file name, such as colons, slashes and spaces.
* use tmpfile_suffix instead of token_sha1_hex in remote_lock, as suggested by Junio, and absorb '_' as a result
* memcpy string from sha1_to_hex to tmpfile_suffix
http-push.c | 13 +++++++++++-- t/t5540-http-push.sh | 7 +++++++ 2 files changed, 18 insertions(+), 2 deletions(-)
http-push.c +11 -2
@@ -153,6 +153,7 @@ struct remote_lockchar *url;char *owner;char *token; +char tmpfile_suffix[41 ];time_t start_time;long timeout;int refreshing;
@@ -557,8 +558,7 @@ static void start_put(struct transfer_request *request) request->dest =strbuf_detach (&buf,NULL );append_remote_object_url (&buf, remote->url, hex,0 ); -strbuf_addstr (&buf,"_" ); -strbuf_addstr (&buf, request->lock->token); +strbuf_add (&buf, request->lock->tmpfile_suffix,41 ); request->url =strbuf_detach (&buf,NULL ); slot =get_active_slot ();
@@ -1130,6 +1130,8 @@ static void handle_lockprop_ctx(struct xml_ctx *ctx, int tag_closed)static void handle_new_lock_ctx (struct xml_ctx *ctx,int tag_closed) {struct remote_lock *lock = (struct remote_lock *)ctx->userData; +git_SHA_CTX sha_ctx; +unsigned char lock_token_sha1[20 ];if (tag_closed && ctx->cdata) {if (!strcmp (ctx->name,DAV_ACTIVELOCK_OWNER )) {
@@ -1142,6 +1144,13 @@ static void handle_new_lock_ctx(struct xml_ctx *ctx, int tag_closed) }else if (!strcmp (ctx->name,DAV_ACTIVELOCK_TOKEN )) { lock->token =xmalloc (strlen (ctx->cdata) +1 );strcpy (lock->token, ctx->cdata); + +git_SHA1_Init (&sha_ctx); +git_SHA1_Update (&sha_ctx, lock->token,strlen (lock->token)); +git_SHA1_Final (lock_token_sha1, &sha_ctx); + + lock->tmpfile_suffix[0 ] ='_' ; +memcpy (lock->tmpfile_suffix +1 ,sha1_to_hex (lock_token_sha1),40 ); } } }
t/t5540-http-push.sh +7 -0
@@ -94,6 +94,13 @@ test_expect_success 'MKCOL sends directory names with trailing slashes' ' ' +test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' ' + + grep -P "\"(?:PUT|MOVE) .+objects/[\da-z]{2}/[\da-z]{38}_[\da-z\-]{40} HTTP/[0-9.]+\" 20\d" \ + < "$HTTPD_ROOT_PATH"/access.log + +' + stop_httpd test_done
Signature · 1 line
1.6.1.2.278.g9a9e.dirty
Hi,
Quoted 3 lines · Junio C Hamano
Other than that, I think this is a good patch.
thanks for the encouraging words, I've sent in the modified patch already.
Signature · 2 lines
Cheers, Ray Chuan