Remote requests to change your working directory now refuse network paths and hidden-character tricks.
What's wrong with this entry?
A request from a remote host to set the working directory is now screened for path shape before anything is resolved, using the same check already applied to remote reads. Paths that resolve to a network location, including obfuscated spellings of one, are refused, as are paths containing invisible characters. The offending path is never repeated back in the response.
- Rejections come back with the reason
unsafe_path. - The user-facing text is "The target is a network path or an obfuscated spelling, which cannot be set as the working directory from a remote host. The path is deliberately not echoed back."
- The existing rejection of paths containing invisible characters is unchanged and also withholds the path.
- Applies unconditionally on the remote set-working-directory path; there is no setting that turns it off.
The target is a network path or an obfuscated spelling, which cannot be set as the working directory from a remote host. The path is deliberately not echoed back., The target resolved to a network path or an obfuscated spelling, which cannot be set as the working directory from a remote host.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.