chore(deps): Update Rust dependencies

[reneleonhardt]

Features

• Update Rust dependencies (tempdir was deprecated)

[felixfontein]

Thanks for your contribution!

[felixfontein]

This change is unrelated.

[reneleonhardt]

Unrelated? Did you ever wonder why there have been no updates in https://github.com/getsops/sops/commits/main/.release? 😉

[felixfontein]

This has nothing to do with Rust. This PR is for updating Rust dependencies.

[felixfontein]

Why you are removing the patch versions for most of the dependencies? Did you verify that the tests also work fine with lower patch versions?

[reneleonhardt]

It seems best practice for Rust dependencies to require always the latest patch version in every build.
How does this affect your tests results?
I tested what I could, your project doesn't provide e2e test scripts for developers, so the 2 vault tests failed, therefore contributors have to rely on your CI pipelines.

Wouldn't it be much better for your users if you would care more for build security than allegedly incompatible patch versions of test dependencies? 🤔
https://blog.rust-lang.org/2023/08/03/cve-2023-38497.html
Why are you using an ancient rust 1.70.0 toolchain since 2 days?

[felixfontein]

It seems best practice for Rust dependencies to require always the latest patch version in every build.

Sounds good to me.

Wouldn't it be much better for your users if you would care more for build security than allegedly incompatible patch versions of test dependencies? 🤔

I'm not sure what you're trying to imply here. I asked a simple question here, I didn't say you have to revert to the previous state. I personally do care for build security, but I'm not that familiar with all the tools used in the SOPS build pipeline.

https://blog.rust-lang.org/2023/08/03/cve-2023-38497.html Why are you using an ancient rust 1.70.0 toolchain since 2 days?

How come you assume we're using it since 2 days? We have been using Rust 1.70.0 for a long time already, the only thing that changed is the place where 1.70.0 is configured. (Which makes it easier to update that version to something less ancient.)

[felixfontein]

Also in CI one often pins all dependencies, and uses things like Dependabot to update them. That prevents random CI failures due to updated dependencies that sneaked in without explicit approval.

Since you added a Dependabot config for Cargo in this PR, I don't really understand why you remove the patch versions here.

[felixfontein]

@reneleonhardt ping

[felixfontein]

Can you please either remove the Dependabot config for Rust, or re-add the full version numbers in Cargo.toml (the second is preferable from my side)? And remove the Docker dependabot config from this PR? Thanks.

[felixfontein]

Why did you remove the Dependabot config for Rust/Cargo?

[felixfontein]

(Also note that with commit messages like that, the chance that I will merge this are pretty much zero. Maybe someone else will merge it, but I definitely will not.)

[reneleonhardt]

You required me to remove the Dependabot config for Rust, even if it makes no sense for an Update Rust dependencies PR, if I want to have a slight chance to get my contribution to your project merged.
So I did against my better judgement, that's why I had to phrase those commits accordingly about the consequences for the maintainers who didn't configure working Dependabot rules yet and made this PR necessary in the first place because no one stepped up and replaced tempdir for example which has been deprecated 6 years ago.
Then you copied my contribution to rip it out-of-context without asking for my permission or if that even would make sense, an Update PR should update and configure Dependabot to update automatically int the future to avoid bugs and security vulnerabilities 🤷

[felixfontein]

You required me to remove the Dependabot config for Rust, even if it makes no sense for an Update Rust dependencies PR, if I want to have a slight chance to get my contribution to your project merged.

I hope you're not actively trying to misinterpret what I wrote:

Can you please either remove the Dependabot config for Rust, or re-add the full version numbers in Cargo.toml (the second is preferable from my side)?

There is an EITHER-OR condition. That means, either do the first, or the second. I also explicitly wrote that I would prefer the second, not the first.

You decided to do both, which is not what I asked you to do, and what we both agree is not a good idea.

Then you copied my contribution to rip it out-of-context without asking for my permission

I did not copy your contribution, I simply recreated parts of it since a) it was no longer part of this PR, and b) it was something I would have liked to merge already in June. Also if you compare the Cargo part of your commit (11ebfc2) with my commit (576f809), you can see that I did not copy your contribution, but based it on the existing entry for GH Actions.

[felixfontein]

Also, according to the official Cargo documentation (https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-cratesio), serde_json = "1.0.128" allows all versions of serde_json that are >= 1.0.128 and < 2.0.0, while serde_json = "1.0" allows all versions that are >= 1.0.0 and < 2.0.0. So there's no good reason to shorten version numbers, unless you want to allow even older versions of the dependencies to match.