What I meant to say in my post above was: since restic uses SHA-256 for the file names in the repo, it has no knowledge of what the SHA-1 hash of the data looks like.
That’s not the case, the library we’re using (https://github.com/kurin/blazer) computes the SHA-1 hash of all data it sends to B2, as far as I’ve understood their API including the SHA-1 hash in the of the content in the HTTP request header is even mandatory. I suppose they compare the hash with what the server received.
That is the only way to ensure the data is accurate. For now, using restic you have to decide whether or not you trust the service (B2 in this case) to store your data. If you trust it, then just verifying that the files are there (this is what
restic check does) is sufficient. If you don’t trust it, you can use
check --read-data and actually retrieve the data to compute the hash locally.
What you’re proposing is something in between: Don’t download the data from the service, but trust it enough to compute a hash over the data. That’s not implemented right now. As far as I know there’s no way to tell B2 to compute a fresh hash,and not use a hash cached in a database from somewhere.
One practical aspect that would need to be solved is: Where is the SHA-1 hash of the data stored? We don’t have a place for that right now.
If we were to add such a feature, it’d need to accommodate all backends which may support a server-side hash. Likely this means computing not only SHA-1 but also MD5 and maybe others.
I hope this answers your questions.