It failed once in a full run: a token change also starts the organization
lookup, whose changes arrive from another thread, and the test collected the
names in a plain list.
Refs #182
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>
- The first version refused the name in RepositoryPathResolver, which made the
whole sync throw where on Windows only that row failed before. The resolver
is as it was; the sync fails that row on every platform, and the WSL clone
refuses the name.
- A folder's own http.followRedirects is refused with its proxy settings; the
message names the setting found.
Refs #184
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>
Two small hardening items from the security review of 1.1.1. Neither exposed
a token; both make a rule that is already stated hold everywhere.
- A folder's own git configuration must not decide where a sync's fetch goes
(#139). That was enforced for URL rewrites and the SSH program; a proxy
named there (http.proxy, http.<url>.proxy, remote.<name>.proxy) was still
honored. It is refused now, with a message that names the setting. A proxy
in the user's global configuration is theirs and still applies.
- RepositoryPathResolver.TryValidateName refuses git's own folder name, in any
spelling Windows opens as that folder, on every platform. Until now only the
Windows sync path refused it, so the WSL clone and the library elsewhere
did not.
Threat model: T3 and T4 say so.
Closes#184
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>
james.maesandClaude Fable 5.2