Bump `rpassword` to `7.5.2`

[Bravo555]

There is a security advisory for rpassword where entered password is revealed if it's been typed and the process is SIGKILLed.

https://github.com/thin-edge/thin-edge.io/security/dependabot/39

We are affected by this in tedge cert upload c8y and tedge cert download c8y commands where we prompt for a password to the C8y account.

This bug happens in rpassword@7.4.0 and the fix is in 7.5.0. However, 7.5.0 also contains other features and bumps its MSRV, using features that have been stabilized in Rust 1.88 (1, 2), which is more recent than our MSRV of 1.85, so we can't update the dependency without changing our MSRV.

Since tedge cert download/upload are rarely used commands and the issue is unlikely to happen in practice (Ctrl+C uses SIGINT which doesn't reveal the password, one would have to kill the process deliberately with SIGKILL or SIGTERM), we won't be prioritizing it and we'll upgrade the dependency if we decide to bump the MSRV of thin-edge.

[reubenmiller]

@Bravo555 Are you sure that you have the right dependencies here, as the rpassword crate seems to have different versions linked there, e.g. 7.5.2 and it only has a MSRV of 1.85 (not 1.88)

[Bravo555]

Indeed the version with the fix is 7.5.0, not 0.5.0 😅 Fixed the description. 7.5.2 is the latest version.

and it only has a MSRV of 1.85 (not 1.88)

I think it declares 1.85, but it's not actually correct. In tests it uses the current stable (1.95), so as far as I'm aware it seems it doesn't even get built in CI using MSRV: https://github.com/conradkleinespel/rpassword/blob/main/.github/workflows/rust.yaml#L30

conradkleinespel/rpassword#130

[reubenmiller]

I don't get Rust then. It just makes this field completely pointless and simply misleading...and considering that newer cargo versions are also meant to to be MSRV aware then such a feature/check is even more useless

[Bravo555]

Well, to discover that rust-version field is set incorrectly one would have to compile it with that version first, but it's not enforced because there might be benefits to compiling with the latest version. You could argue that something like https://docs.rs should compile using MSRV if a project declares it, but they might also want to compile with latest stable because of new features of rustdoc that they wan't to use and if they still want to check MSRV then that's twice the compilation compute.
So while there's nothing preventing from setting the wrong MSRV, there are some nice features that work properly when it's set correctly: https://doc.rust-lang.org/cargo/reference/rust-version.html
Out of curiosity, is there something enforcing the use of declared language toolchain version in, e.g. go? I'm not sure if I'm looking at the right thing but it seems not (https://stackoverflow.com/questions/65137235/can-i-require-a-minimum-go-version-when-compiling-an-app#65137236):

Starting in Go 1.21, the Go distribution consists of a go command and a bundled Go toolchain, which is the standard library as well as the compiler, assembler, and other tools. The go command can use its bundled Go toolchain as well as other versions that it finds in the local PATH or downloads as needed.
In the standard configuration, the go command uses its own bundled toolchain when that toolchain is at least as new as the go or toolchain lines in the main module or workspace. For example, when using the go command bundled with Go 1.21.3 in a main module that says go 1.21.0, the go command uses Go 1.21.3. When the go or toolchain line is newer than the bundled toolchain, the go command runs the newer toolchain instead

also: https://stackoverflow.com/a/77632986