Create a new release that includes the libgit2 fixes

[dbrgn]

Problem

The currently released cargo version transitively depends on a libgit2-sys version that segfault in combination with the current stable libgit2 release (1.4.2). This was fixed in #10442, but wasn't released yet.

Because projects can only link against one version of a -sys crate, projects that depend on cargo cannot bump the dependencies themselves, because otherwise there is a linker conflict.

Affected projects are cargo-outdated, cargo-crev and others. All these projects segfault when being used on an up-to-date Arch Linux system, and the maintainers of these cargo plugins can't do anything about it until a new cargo release is out.

Steps

1. Install cargo-outdated on an up to date Arch Linux system
2. Run cargo outdated in a repository that contains git dependencies
3. Segfault

Possible Solution(s)

Publish a new patch release containing the fix from #10442.

Notes

No response

Version

cargo 0.60.0

[alerque]

Also affected, cargo-edit (I'm the Arch packager)

@Frederick888 did that downgrade patch you did on cargo-outdated actually work?

It seems like besides the immediate fix of getting everybody on the save version of libgit2, this is a bit of a bug in the whole ecosystem. Why is it even possible to build something depending on both cargo and libgit2-sys in such a way that is just going to segfault?

[Frederick888]

No :( I thought I magically fixed it somehow cos my debug build didn't segfault, but --release just brought it back.

If this is really urgent, I guess you can vendor a copy of patched cargo and update cargo-edit's manifest.

[Mrmaxmeier]

Note: v0.61.0 was released recently. Unfortunately though, it looks like dd701a1 is not in the rust-1.60.0 branch, which the 0.61.0 cargo release is based on.

[dbrgn]

@Mark-Simulacrum any chance for a 0.61.1 release that contains this fix? A lot of cargo plugins are broken on distros with a recent libgit2 😕

[Mark-Simulacrum]

The Cargo team would need to decide whether that makes sense ultimately.

To clarify, we'd just need a crates.io release, right? The published cargo binaries built on our infrastructure aren't affected by this? That makes it pretty easy to do a backport and release I think.

[kpcyrd]

To clarify, we'd just need a crates.io release, right?

I think so, yes.

[ehuss]

We'd be fine making a new release. Someone needs to post a PR to backport the change to the rust-1.60.0 branch, and bump the version. I can publish a new release after that.

[ehuss]

I have published v0.61.1.