0.21.0 unable to fetch index

[dvzrv]

Steps to reproduce the bug with the above code

Hi! I'm currently trying 0.21.0 on Arch Linux, which is built using the Cargo.lock file of the project.

When trying to run it, the process errors on a TLS issue.
This is reproducible building using cargo (cargo install --locked cargo-semver-checks) and using the current distribution package.

FTR: 0.20.0 works as intended using the distribution package and building using cargo install --locked --version "0.20.0" cargo-semver-checks.

Actual Behaviour

cargo semver-checks check-release
    Updating index
Error: the server did not provide a certificate; class=Ssl (16)

Caused by:
    the server did not provide a certificate; class=Ssl (16)

Expected Behaviour

cargo semver-checks check-release
    Updating index
     Parsing alpm-types v0.2.0 (current)
     Parsing alpm-types v0.2.0 (baseline, cached)
    Checking alpm-types v0.2.0 -> v0.2.0 (no change)
   Completed [   0.026s] 43 checks; 42 passed, 1 failed, 0 unnecessary

Generated System Information

cargo semver-checks --bugreport

Software version

cargo-semver-checks 0.21.0 (c7102df-modified)

Operating system

Linux 6.3.6-arch1-1

Command-line

/home/user/.cargo/bin/cargo-semver-checks semver-checks --bugreport

cargo version

> cargo -V
cargo 1.70.0 (ec8a8a0ca 2023-04-25)

Compile time information

• Profile: release
• Target triple: x86_64-unknown-linux-gnu
• Family: unix
• OS: linux
• Architecture: x86_64
• Pointer width: 64
• Endian: little
• CPU features: fxsr,sse,sse2
• Host: x86_64-unknown-linux-gnu

Build Configuration

No response

Additional Context

For reference, this is how the Arch Linux package is built: https://gitlab.archlinux.org/archlinux/packaging/packages/cargo-semver-checks/-/blob/main/PKGBUILD

[dvzrv]

Downgrading git2 to 0.16.1 seems to fix this issue.

[obi1kenobi]

An issue like this has popped on and off for some users for a few versions now, and thus far we haven't been able to successfully diagnose the problem since it's coming via a transitive dependency (I believe via crates_index).

Some users were able to work around the problem by disabling the vendored-openssl feature on cargo-semver-checks. That might be worth a try.

It's also interesting that downgrading git2 seems to fix the problem. Would you mind opening an issue on that crate and linking to this one? I'd open it myself, but I'd just be copy-pasting what you said with no ability to help git2's maintainers if they need more information.

[dvzrv]

Sure.

For posterity, applying this fixes the build for me:

diff --git i/Cargo.lock w/Cargo.lock
index 6506df3..c4e7d90 100644
--- i/Cargo.lock
+++ w/Cargo.lock
@@ -638,9 +638,9 @@ dependencies = [

 [[package]]
 name = "git2"
-version = "0.17.2"
+version = "0.16.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "7b989d6a7ca95a362cf2cfc5ad688b3a467be1f87e480b8dad07fee8c79b0044"
+checksum = "ccf7f68c2995f392c49fffb4f95ae2c873297830eb25c6bc4c114ce8f4562acc"
 dependencies = [
  "bitflags",
  "libc",
@@ -879,9 +879,9 @@ checksum = "2b00cc1c228a6782d0f076e7b232802e0c5689d41bb5df366f2a6b6621cfdfe1"

 [[package]]
 name = "libgit2-sys"
-version = "0.15.2+1.6.4"
+version = "0.14.2+1.5.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "a80df2e11fb4a61f4ba2ab42dbe7f74468da143f1a75c74e11dee7c813f694fa"
+checksum = "7f3d95f6b51075fe9810a7ae22c7095f12b98005ab364d8544797a825ce946a4"
 dependencies = [
  "cc",
  "libc",
diff --git i/Cargo.toml w/Cargo.toml
index 4f8d751..2fe5b73 100644
--- i/Cargo.toml
+++ w/Cargo.toml
@@ -30,7 +30,7 @@ clap-cargo = { version = "0.10.0", features = ["cargo_metadata"] }
 ignore = "0.4.18"
 clap-verbosity-flag = "2.0.0"
 log = "0.4.17"
-git2 = { version = "0.17.0", default-features = false }
+git2 = { version = "0.16.1", default-features = false }
 crates-index = { version = "0.19.10" }
 human-panic = "1.0.3"
 bugreport = "0.5.0"

[DianaNites]

cargo install cargo-semver-checks --locked --no-default-features also works for me by using the system openSSL instead of vendored, from one of the previous issues for this problem

[obi1kenobi]

Soon — probably as soon as the next release — we plan on switching from git2 to gix for all our uses, so it's possible that whatever issue we were running into here goes away.

When that happens, I'd love it if you could try to reproduce this issue and let me know if it's still happening or can be closed as resolved.

Thanks for your patience on this!

[obi1kenobi]

In v0.23 we switched to gix for git use cases, so we're using completely different networking code and not using git2 at all.

When you have a second, would you mind taking a look and seeing if this issue has gone away, and if so letting me know if I can close it?

[obi1kenobi]

Closing on the assumption that the issue is probably gone. Happy to reopen if we have more evidence of the same problem happening.

[dvzrv]

Hey! Sorry for the late reply!

As I have not seen this problem resurface after patching the package for Arch Linux and later on upgrading it, I do believe this issue is indeed solved!

Keep up the good work! It's much appreciated! 🎉