`-V` prints no actual version
svenstaro opened this issue · 6 comments
❯ cargo run -- . -V
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/proximity-sort . -V`
Proximity Sorter
I think this should print the actual current version.
Released in 1.2.0 🎉
Thanks, though the tag isn't signed unlike most of the others! Could you look into that?
Yeah, that's on purpose. I've stopped signing my commits. My old PGP key expired, and it's just not worth the hassle to correctly keep a PGP up to date these days. Maybe once GitHub supports signing with SSH keys I'll start signing them again.
Alright, but you could always just have a GPG key with a really long life time. Arguably that's still better than not signing at all. :)
I don't actually think it's true that that's better — it effectively gives a false sense of security. A signature from a private key is only as valuable as the care with which that private key is handled. And maintaining a very-long-lived key is sort of opposed to that key being (relatively) secure — especially once you take encrypt/sign scheme evolution into account. Not to mention making a PGP key convenient to access and easily verifiable (now that all the key servers have ~= gone away) is a hassle, so it ends up being a fair amount of pain.
Realistically, I think what we should want longer term here is crates.io package signing, which I know is a thing that many people have their eyes on, though it doesn't currently exist. In the interrim though, grabbing the artifact from crates.io and comparing its source against the source of the repo at the appropriately-tagged commit would be the best way to have a sanity check.
Yeah, all of that is fair enough. Good point about the possible mismatch of versions of git tags and crates.io versions - I'm personally really worried about that being exploited and there's not really any great tooling to deal with that at all times.