Trust checks don't work for UNC paths on Windows.

[gulbanana]

Current behavior 😯

In the function is_path_owned_by_current_user at

gitoxide/gix-sec/src/identity.rs

Line 83 in 3f2be40

pub fn is_path_owned_by_current_user(path: &Path) -> io::Result<bool> {

, gitoxide is calling GetNamedSecurityInfoW. This doesn't seem to work for UNC paths - repos located in WSL, or on network drives, or >255 character long paths.

I'm not quite sure what's broken. Maybe SE_FILE_OBJECT only works for regular files, or perhaps the to_wide_path() conversion is doing the wrong thing?

Expected behavior 🤔

Loading the repo, ideally.

Git behavior

It looks like git doesn't work out of the box, but provides an escape hatch:

fatal: detected dubious ownership in repository at '//wsl.localhost/Ubuntu/home/username/repo/.git'
To add an exception for this directory, call:

        git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu/home/username/repo/.git'

Steps to reproduce 🕹

1. Create a repository using a WSL shell gitoxide, git or anything else.
2. Open a non-WSL shell and navigate to the directory.
3. Call any function that checks repo trust (I did this using jj, which uses gitoxide for git repo access).

[Byron]

To summarise, it appears that neither Git nor gitoxide can correctly determine ownership when such paths like //wsl.localhost/Ubuntu/home/username/repo/.git are used.

Git suggests to add this directory to an allow-list like this:

git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu/home/username/repo/.git'

There are two things in my mind about this:

• Which error message does jj produce?
  • I am asking as gitoxide will actually open repositories that it doesn't trust, but it will avoid trusting any configuration inside of it that is related to executable paths.
  • If jj is aborting, then it might be related to jj enabling bail_if_untrusted()
• Does adding the path to the allow-list fix the issue?
  • gitoxide should respect safe.directory, and failing to do so might have to do with that %(prefix) variable, maybe some path substitution isn't working quite right so the paths never match.

Thanks for your help with this!