From 88ca1d8d56482221ca8eee5a89867ac485645b73 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 15 Aug 2017 15:31:01 -0400 Subject: hmm --- ...ent_1_c9095cf16c9b044a4eae6b9b445b2512._comment | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_1_c9095cf16c9b044a4eae6b9b445b2512._comment diff --git a/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_1_c9095cf16c9b044a4eae6b9b445b2512._comment b/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_1_c9095cf16c9b044a4eae6b9b445b2512._comment new file mode 100644 index 000000000..611508b6b --- /dev/null +++ b/doc/bugs/external_special_remote_protocol_broken_by_key_with_spaces/comment_1_c9095cf16c9b044a4eae6b9b445b2512._comment @@ -0,0 +1,60 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2017-08-15T18:45:21Z" + content=""" +It would be kind of nice to not have to worry about keys containing spaces. +(Only space is allowed currently, not other whitespace.) But that ship has +long sailed and it would be very ugly to force changing repositories using +WORM keys with spaces to WORM keys without spaces. About as ugly as +entirely dropping WORM, which might not be a bad long-term goal. + +Here's a few approaches for fixing this in the external special remote protocol: + +1. Mangle keys containing spaces as they are sent via the protocol + and de-mangle as they're received. + Eg, convert ' ' to 's' and convert 's' to 'ss' etc. + (Perhaps pick a better letter than 's' -- '%' and ',' and '&' are + already used for other escaping.) +2. Make "VERSION 2" be the same as the current protocol, except Key + (and other parameters) are quoted in some way. +3. Make "VERSION 2" be the same as the current protocol, except using NUL + rather than space to separate parameters. Perhaps also to separate + protocol commands from their parameters, but then "VERSION 2" would + be an exception to the rule. + +Of course the advantage of #1 is that it doesn't need any modifications to all +the external special remotes. Such modifications would take quite a while, +and probably wouldn't even start until a git-annex supporting "VERSION 2" +was widely available, ie years even to start. + +Using NUL is conceptually the simplest implementation, but it may cause +issues for implementing external special remotes in some languages. Shell +scripts are probably not good at NULs, for example. + +One problem with approach #1 is, what if a key containing a space in the +protocol happened to already work with the protocol parser in an external +special remote? This seems at least possible. And so content would already +be stored on the external special remote under the real key, not the +mangled key. When git-annex starts mangling the key, retreiving the content +from the special remote would then fail. + +For that to happen, the external special remote would need a parser that +when it sees "TRANSFER STORE Key File", parses it with File as the last +word, so supporting multi-word Key. The documentation does currently say +that "The filename will not contain any whitespace." Actually, I tested it, +and with a WORM key with spaces, that documentation is generally wrong, +since the File is based on the Key, it also contains whitespace, most of +the time. One exception is when using direct mode, if the work tree file +has been renamed to not contain whitespace. + +So, approach #1 seems to call for auditing of external special remotes +and/or a warning to their implementors about that issue. This would also +be an opportunity to correct the documentation about spaces in the +filename, and make sure that they all support that. + +Another problem with key mangling is if an external special remote takes +the mangled key, and passes it to some other git-annex command, like `git annex +setpresentkey` or something. I seem to remember datalad doing this kind of +thing. +"""]] -- cgit v1.2.3