put_bucket_cors fails with boto3 >= 1.36 due to unsupported checksum algorithms (CRC32)

[claudiu-muresan-pfa]

When using boto3 v1.36 or newer, the default checksum algorithm used for the put_bucket_cors request has changed. Boto3 no longer relies solely on the standard Content-MD5 header by default . Instead, it defaults to using alternative checksum algorithms like CRC32 (using headers such as x-amz-checksum-crc32 and x-amz-sdk-checksum-algorithm).

Currently, CloudServer strictly validates requests against the MD5 checksum provided via Content-MD5 header and rejects requests using these newer algorithms. As a result, any boto3 client using version >= 1.36 fails the PutBucketCors call against CloudServer with an error similar to:

<ClientError>
  <Code>BadDigest</Code>
  <Message>The Content-MD5 you specified did not match what we received.</Message>
</ClientError>

Is there a plan to support other checksum algorithms besides MD5 in CloudServer?
If not this will be painful as we can't upgrade anymore the boto client to latest versions.

[myntlabs]

Also have the same issue - downgrading boto3 = ">=1.0.0,<1.36.0" resolved it. Would be good to support later versions.

[extua]

I'm having a similar problem trying to change CORS policy on Scality with the AWS CLI.

After running

aws s3api put-bucket-cors --bucket <bucket name> --cors-configuration=file://cors_rules.json

I'm getting this error

An error occurred (BadDigest) when calling the PutBucketCors operation: The Content-MD5 you specified did not match what we received.

[extua]

It looks like the hash is checked in this block

cloudserver/lib/api/bucketPutCors.js

Lines 36 to 44 in e41e0b8

	if (request.headers['content-md5']) {
	const md5 = crypto.createHash('md5')
	.update(request.post, 'utf8').digest('base64');
	if (md5 !== request.headers['content-md5']) {
	log.debug('bad md5 digest', { error: errors.BadDigest });
	monitoring.promMetrics('PUT', bucketName, 400, 'putBucketCors');
	return callback(errors.BadDigest);
	}
	}

There might be a complication because the crypto.createHash function relies on OpenSSL, and at least on my system (Debian 13) CRC32 isn't in the list of supported algorithms.