Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null pointer dereference in git_remote_fetch #819

Open
demurgos opened this issue Mar 10, 2022 · 3 comments
Open

Null pointer dereference in git_remote_fetch #819

demurgos opened this issue Mar 10, 2022 · 3 comments

Comments

@demurgos
Copy link

demurgos commented Mar 10, 2022

The following Rust programs triggers a segfault due a null pointer dereference in git_remote_fetch:

use git2::{AutotagOption, FetchOptions, Repository, RepositoryInitOptions};
use std::path::PathBuf;

fn main() {
    let input_path = PathBuf::from("./git2");
    let remote_url = "https://gitlab.com/eternaltwin/popotamo/popotamo.git".to_string();
    let commit = "d48338d82864679ed3bc656d7f7d1c445ac991b2".to_string();

    std::fs::create_dir_all(input_path.as_path()).expect("create_dir");

    let mut init_opts = RepositoryInitOptions::new();
    init_opts.mkpath(false);
    init_opts.mkdir(false);
    init_opts.external_template(false);
    let repository = Repository::init_opts(&input_path, &init_opts).expect("init repp");

    let mut remote = repository.remote_anonymous(&remote_url).expect("create remote");
    {
        let mut fetch_opts = FetchOptions::new();
        fetch_opts.download_tags(AutotagOption::All);
        let all_refs: [&str; 3] = ["master", "develop", &commit];
        remote.fetch(&all_refs, Some(&mut fetch_opts), None).expect("fetch");
    }
    eprintln!("done");
}

I initially thought it to be related to #813 as the problem only appeared recently: everything worked fine a few days ago. Since then I updated my system but did not touch my cargo lock file or config. However, according to @saethlin, this is a different bug.

@ehuss
Copy link
Contributor

ehuss commented Mar 11, 2022

Thanks for putting together the reproduction. I have filed libgit2/libgit2#6243 with upstream.

A workaround is to use a refspec with a destination, as in +d48338d82864679ed3bc656d7f7d1c445ac991b2:d48338d82864679ed3bc656d7f7d1c445ac991b2.

davidB added a commit to ffizer/ffizer that referenced this issue Mar 13, 2022
- see rust-lang/git2-rs#819
- else segfault on `cargo run -- test-samples --source https://github.com/ffizer/template_sample.git --rev "3ab3bc67b5fab58ceecc031f7ed0eb29c0e0fff8" `
@demurgos
Copy link
Author

It looks like the issue is fixed in upstream libgit2, the vendored version needs to be updated:

  • git2 = { version = "0.14.1", features = ["vendored-libgit2"] } (original) -> failing
  • git2 = { version = "0.14.2", features = ["vendored-libgit2"] } -> failing
  • git2 = { version = "0.14.1" } (system libgit2 - up-to-date) -> passes now

@ehuss
Copy link
Contributor

ehuss commented Apr 19, 2022

Yep. I've been preparing a bump, but there are some snags that are delaying it. Hopefully soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants