Checksum for 1.20 archive changed : is this expected ?

[alexAubin]

Checksum for 1.20 archive changed : is this expected ?

Bitwarden / Vaultwarden is packaged as a Yunohost app here

Users started to notice ~24 hours ago that the installation did not work anymore because the checksum of the file is not the one expected anymore. This checksum was computed on March 29th and was still valid at least 4 days ago (we have automatic testing checking this among other things)

We're trying to make sure that it's not a malicious actor that modified the archive (instead of blindly updating the checksum on our side), considering the tagged commit on this repo is still from March 28th here: https://github.com/dani-garcia/vaultwarden/tree/1.20.0 and here: https://github.com/dani-garcia/vaultwarden/releases/tag/1.20.0

Shall we be worried ? Or is it expected and we should just update the checksum on our side ?

Deployment environment

Not sure if relevant, this is just about doing a curl/wget + sha512sum from any linux distro ... Debian in the context of Yunohost, but also reproduce from Linux Mint

Steps to reproduce

curl -sL https://github.com/dani-garcia/bitwarden_rs/archive/1.20.0.tar.gz | sha512sum

Expected behaviour

the expected sha512 value is: 96fc0c3d55ed770af7209f881e107c33cf8ddf5179c504eacbc155dcb0f28641e5d28dd9cbd4f071540a7aac3d0e40b519de1fb85a523c6b74fb91a930d329a8

Actual behaviour

the actual current sha512 value is:

ffe64a8783594b8dc5d4415f3f6898108f6ca38b48e17cdba3d7390c406462abf415cf7d99bfe45e80487ac35488e0022c47af38555c3cd8d956a936d0a38a11

Troubleshooting data

[dani-garcia]

The tar.gz file contains a directory with the name of the repo + the version so it makes sense that the checksum would change, those archives are generated by github directly and on the fly so it's nothing we can change on our side.

If you want to make sure that nothing is changed, you can clone the repository at the commit of that release (fd27759), verify it with my GPG key (https://pgp.mit.edu/pks/lookup?search=0xFC8A7D14C3CD543A), and then check that the files match between the git repo and the tar.gz

[alexAubin]

Alrighty, I guess that's okay then ... I was just thinking that the archives available in the release page https://github.com/dani-garcia/vaultwarden/releases/tag/1.20.0 are only generated once

But I noticed that the project rename happened recently, maybe this has something to do with it ?

[dani-garcia]

Yeah that's definitely the cause of the change, the folder inside the tar.gz went from bitwarden_rs-1.20.0 to vaultwarden-1.20.0, which is enough to change the hash. For what it's worth, I compared the content of the new tar.gz, with the same hash you mentioned, and the contents are identical to the commit of the 1.20.0 release, so everything seems okay.

Very strange of github to rewrite old releases like that instead of having them be static, yeah.

[BlackDex]

@alexAubin, yea that is probably the reason, as @dani-garcia also mentioned, the zip/.tar.gz contains the project name, and thus the checksum would change because of that, even though the code inside doesn't.

Same goes for all other previous release, they now have vaultwarden-VERSION as it's main folder name.