In restore.go, downloadBlob() calls FetchAndDecryptBlob() and returns the data without verifying that the hash of the downloaded encrypted blob matches the expected blobHash.
If the storage returns corrupted data or the wrong blob, restore will silently produce corrupted output. The blob hash should be verified after download, similar to how verify.go does it with a TeeReader + sha256.
In `restore.go`, `downloadBlob()` calls `FetchAndDecryptBlob()` and returns the data without verifying that the hash of the downloaded encrypted blob matches the expected `blobHash`.
If the storage returns corrupted data or the wrong blob, restore will silently produce corrupted output. The blob hash should be verified after download, similar to how `verify.go` does it with a `TeeReader` + `sha256`.
Ref: parent issue #1
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In
restore.go,downloadBlob()callsFetchAndDecryptBlob()and returns the data without verifying that the hash of the downloaded encrypted blob matches the expectedblobHash.If the storage returns corrupted data or the wrong blob, restore will silently produce corrupted output. The blob hash should be verified after download, similar to how
verify.godoes it with aTeeReader+sha256.Ref: parent issue #1
Taking this on now. Will add hash verification after blob download during restore.