[#218] Add check content sha256 header #264
No reviewers
Labels
No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-s3-gw#264
Loading…
Reference in a new issue
No description provided.
Delete branch ":feature/218-Add_check_content_hash_header"
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?
Closes #218
The X-Amz-Content-Sha256 header check is done only for unencrypted payload.
More information here.
Signed-off-by: Roman Loginov r.loginov@yadro.com
Please update changelog
@ -215,1 +241,4 @@
func checkFormatHashContentSHA256(hash string) error {
if !IsStandardContentSHA256(hash) {
re := regexp.MustCompile(`^(?:[0-9a-fA-F]{64})?$`)
It's better to compile regexp once rather than on every request.
By the way, it seems we can use
hex.DecodeString
and check length after successful decoding (as alternative to regexp)@ -249,0 +246,4 @@
Header: metadata,
Encryption: encryptionParams,
ContentMD5: r.Header.Get(api.ContentMD5),
ContentSHA256Hash: r.Header.Get(api.AmzContentSha256),
Shouldn't we use the same check also for
UploadPart
(and maybe some other methods where this hash be for general body rather than just payload? or it's invalid scenario?)95290b2445
to3a7eee90d9
3a7eee90d9
to2653f8fc0a
@ -216,0 +244,4 @@
if _, err := hex.DecodeString(hash); err != nil {
return apiErrors.GetAPIError(apiErrors.ErrContentSHA256Mismatch)
}
if len(hash) != 64 && len(hash) != 0 {
Actually sha256 size is
32
(not64
). And it's better to use standard constantsha256.Size
Yes, but in this case, I am checking the hash length in string representation in 16-bit format, and the number of characters should be 64 for 32 bytes, so it works correctly. But it may be worth checking the length of the slice of bytes received before decoding at this point?
Oh, sorry. Yes, I thought we check length of decoded slice of bytes.
I would suggest to check for length of decoded slice of bytes instead of length of hex-encoded string (though the last approach can be faster in case of invalid hash format)
2653f8fc0a
to8662b12fdc