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

[gulbanana]

Current behavior 😯

In the function is_path_owned_by_current_user at https://github.com/GitoxideLabs/gitoxide/blob/3f2be402e20f7642f89721a6a7b9ce7e833dfce7/gix-sec/src/identity.rs#L83, 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!