Interaction between 'safe.directory' and trust level and remotes.

[TyberiusPrime]

Current behavior 😯

(version 0.70.0)

When a .git is not owned by the current user,
but is listed in safe.directories,
open(repo).remote_names() returns an empty list.

bail_if_untrusted(true) does not seem to make a difference.

See jj-vcs/jj#6155

Expected behavior 🤔

If the directory is in safe.directories, I'd expect it to be trusted.
Or, if gitoxide doesn't read safe.directories, I'd expect it to fail if bail_if_untrusted is set.

Git behavior

Git lists the remotes in both cases.

Steps to reproduce 🕹

1. git init owned; cd owned; git remote add https://github.com/GitoxideLabs/gitoxide; cd ..
2. git init non_owned; cd non_owned; git remote add https://github.com/GitoxideLabs/gitoxide; cd ..; sudo chown <somebody_else> non_owned -R

fn main() {
println!("using owned repo");
{
let repo_owned = gix::open("owned").expect("could not opon owned repo");
let rn = repo_owned.remote_names();
println!("found {} remotes", rn.len());
for remote in rn {
println!("remote: {}", remote);
}
}

println!("\n\n");
{
    println!("using non-owned repo, which is in .gitconfig/safe.directories");
    let repo_non_owned = gix::open("non_owned").expect("could not opon non-owned repo");
    let rn = repo_non_owned.remote_names();
    println!("found {} remotes", rn.len());
    for remote in rn {
        println!("remote: {}", remote);
    }
}

println!("\n\n");
{
    println!(
        "using non-owned repo, which is in .gitconfig/safe.directories, + bail_if_untrusted"
    );
    let repo_non_owned =
        gix::open_opts("non_owned", gix::open::Options::default().bail_if_untrusted(true))
            .expect("could not opon non-owned repo wit bail-if-untrused");
    let rn = repo_non_owned.remote_names();
    println!("found {} remotes", rn.len());
    for remote in rn {
        println!("remote: {}", remote);
    }
}

}

[Byron]

Thanks a lot for bringing this to my attention.

Interestingly just a couple of days ago I thought about this for no apparent reason and I wondered the same - does safeDirectories affect the current implementation in terms of trust?

And even though something is implemented in that regard (I'd have to check for details), I don't think that configuration files are affected enough, or it's a bug.

I put this on my list, but it's long and any help is appreciated.