Define /unix
#174
Define /unix
#174
Conversation
Adds a protocol note for how to encode paths to Unix domain sockets as strings, that may include the delimiting character of `/`. This allows us to append other tuples to the multiaddr while also ensuring we can round-trip the address to a string and back. This doesn't affect the binary representation of the multiaddr since everything is length-delimited. Takes inspiration from #164 and proposes using URI encoding for the segment, the same as the `/http-path` component. One difference is if the path is to represent the filesystem root, it must be included in the value portion of the tuple, otherwise it can be omitted.
Need to resolve how to encode unix paths so peer ids can be appended to them - multiformats/multiaddr#174
|
Are there any backwards compatibility issues? Is anyone using this multiaddr currently? |
I'm not sure how heavily it's utilized, but kubo can use those addresses. e.g. https://github.com/ipfs/kubo/blob/4009ad3e5a502518ddc7d48a888707f812ddc629/docs/config.md?plain=1#L219 |
I haven't looked too deeply at usage, but I'd suspect so. The question is what to do about it. There are a bunch of issues that are basically about the failures related to protocols (like http or unix) in taking unescaped paths like #139 #55. They were also known from the earliest days multiformats/go-multiaddr#31. Maybe the answer is to just break it, or to say that implementations MAY/SHOULD/MUST preferentially try looking for the entire path as a socket and if that fails will try with just the first path segment as a socket. Not specific to this PR, but between http-path and this perhaps worth biting the bullet on specifying how "path" types should be done in general. Maybe the answer is just to require them all to be escaped, maybe it's something else (e.g. closer to @Stebalien's proposal in multiformats/multiformats#55). |
|
There will be backwards compatibility issues with the string representation of the path due to the escaping, though not with the binary representation. I think this is used but not very commonly. The js stack can also use unix addresses but currently only as a terminal element, that is no tuples can follow it. Arguably the lack of escaping has harmed it's use - I know I've tried to use it a few times over the years but always come up hard against the inability to append anything else to the address and the various issues asking for clarification etc speak to a need for this.
I wonder if this could get exploited by making longer paths with segments that mirror tuples after the unix section? Possibly with
I kind of think so. The original PR was merged in haste, the question about if we need to append things to it was unresolved. It was flagged as experimental and subject to change so..
It's interesting that - it seems to mandate parsing paths left to right, we recently switched multiaddr-to-uri to parsing right to left to support some forms of multiaddr. It also doesn't seem to say much about escaping so we'd probably still need to solve the same problem there. |
Summary
Adds a protocol note for how to encode paths to Unix domain sockets as strings, that may include the delimiting character of
/.This allows us to append other tuples to the multiaddr while also ensuring we can round-trip the address to a string and back.
This doesn't affect the binary representation of the multiaddr since everything is length-delimited.
Takes inspiration from #164 and proposes using URI encoding for the segment, the same as the
/http-pathcomponent.One difference is if the path is to represent the filesystem root, it must be included in the value portion of the tuple, otherwise it can be omitted.
Before Merge