fix: compute Content-MD5 for all S3 write paths on Object Lock buckets - #19
Open
swatiganesh wants to merge 5 commits into
Open
fix: compute Content-MD5 for all S3 write paths on Object Lock buckets#19swatiganesh wants to merge 5 commits into
swatiganesh wants to merge 5 commits into
Conversation
…pport
In the 2021 fix, SendContentMd5 was added to PutObject to support
Object Lock enabled S3 buckets. However, CompleteMultipartUpload was
passing an empty PutObjectOptions{} struct, so no Content-MD5 header
was sent to AWS. AWS requires this header for Object Lock buckets and
rejects the request without it, causing backups to fail for large
objects that go through multipart upload.
Fix: pass PutObjectOptions{SendContentMd5: true} in CompleteMultipartUpload,
identical to how PutObject already handles it.
Fixes: CHEF-37621
Signed-off-by: swatign <SwatiGanesh.Naik@Progress.com>
…r Object Lock buckets Core.PutObject bypasses SendContentMd5:true and passes md5Base64 directly. When OpenSearch sends PUT requests via streaming SigV4 (no Content-MD5 header), md5Base64 is empty and AWS rejects with 400 InvalidRequest. Using Client.Client.PutObject (high-level API) ensures the SDK buffers the data and computes MD5 itself when SendContentMd5:true is set. Signed-off-by: swatign <SwatiGanesh.Naik@Progress.com>
…ckets When callers use streaming SigV4 chunked transfer (e.g. OpenSearch Java SDK), no Content-MD5 header is sent so MD5Base64String() returns empty string. AWS S3 requires Content-MD5 on Object Lock buckets (400 InvalidRequest). Buffer the body and compute MD5 ourselves when missing, pass it explicitly to Core.PutObject. Keeps Core API (no validate() side-effects on UserMetadata) while ensuring Content-MD5 is always present for Object Lock buckets. Signed-off-by: swatign <SwatiGanesh.Naik@Progress.com>
AWS S3 requires Content-MD5 on every UploadPart request for Object Lock buckets. When the caller uses streaming SigV4 (no Content-MD5 header), MD5Base64String() returns empty. Buffer the part and compute MD5 ourselves when missing, same pattern as the PutObject fix. Signed-off-by: swatign <SwatiGanesh.Naik@Progress.com>
Signed-off-by: swatign <SwatiGanesh.Naik@Progress.com>
swatiganesh
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Chef Automate backups fail when the target S3 bucket has Object Lock enabled.
AWS S3 Object Lock buckets require a
Content-MD5header on every write. OpenSearch uses the AWS Java SDK with streaming SigV4, which never sendsContent-MD5. The gateway was forwarding these requests to AWS as-is, causing AWS to reject them.Three write paths were all affected:
PutObject—Core.PutObjectignoresSendContentMd5: true; when MD5 is missing the gateway was forwarding an empty value to AWSPutObjectPart— same issue for each part of a multipart uploadCompleteMultipartUpload— was called with emptyPutObjectOptions{}The 2021 fix (50a68a1) only patched the surface of
PutObjectbut none of these three paths were actually sendingContent-MD5to AWS.Fix
PutObject+PutObjectPart: WhenMD5Base64String()returns""(streaming SigV4), buffer the body/part and compute MD5 ourselves before forwarding to AWS.CompleteMultipartUpload: PassPutObjectOptions{SendContentMd5: true}.Testing
Verified on EC2 against a real AWS S3 Object Lock (COMPLIANCE) bucket (
ap-south-1):chef-automate backup createcompletes successfully for all servicesupload-part× 2 →complete-multipart-upload) succeeded on Object Lock bucketRelated
Fixes: CHEF-37621
without this changes backup was not getting created for S3 bucket with Object Lock enabled-
with this changes backup is getting created for S3 bucket with Object Lock enabled