mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-07-15 18:12:14 -05:00
Checksum for 1.20 archive changed : is this expected ? #1016
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vaultwarden#1016
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alexAubin on GitHub (Apr 28, 2021).
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
Expected behaviour
the expected sha512 value is:
96fc0c3d55ed770af7209f881e107c33cf8ddf5179c504eacbc155dcb0f28641e5d28dd9cbd4f071540a7aac3d0e40b519de1fb85a523c6b74fb91a930d329a8Actual behaviour
the actual current sha512 value is:
ffe64a8783594b8dc5d4415f3f6898108f6ca38b48e17cdba3d7390c406462abf415cf7d99bfe45e80487ac35488e0022c47af38555c3cd8d956a936d0a38a11Troubleshooting data
@dani-garcia commented on GitHub (Apr 28, 2021):
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 (
fd27759a95), 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 commented on GitHub (Apr 28, 2021):
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 commented on GitHub (Apr 28, 2021):
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 commented on GitHub (Apr 28, 2021):
@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-VERSIONas it's main folder name.