SQS Attributes Bug due to bad MD5 Hashing.

[phillip-haydon]

softwaremill/elasticmq#13 (comment)

I replied to an issue over at this ElasticMQ repo by mistake.

We are using the .NET SDK and have come across a problem with adding Attributes to messages. I can consistently reproduce this locally by creating messages with attributes that are keyed with lowercase and uppercase.

i.e

BANANA
apple
ZOO
grape

The message will be accepted and placed on the queue. But reading the message back will result in a MD5 mismatch.

Attribute MD5 hash mismatch

Attribute MD5 hash mismatch for message id 760349d3-0d7f-4593-bfa0-1a15cb0c6ca3

If I put invalid messages onto the queue, it prevents me from putting anymore on the queue that are valid. But also prevents me from reading the offending message from the queue.

This is the example I had.

The order of the attributes turns out to be different to the order they were added.

They were added in as

• DeadlineInt
• DistributionJobStatus
• ftpuser
• ftpaddress

So I assume that the MD5 hash created on the client is different to the hash done via validation afterward.

https://github.com/aws/aws-sdk-net/blob/master/AWSSDK_DotNet35/Amazon.SQS/Internal/ValidationResponseHandler.cs#L143

Which happens to sort them.

[PavelSafronov]

Thanks for reporting this. The line you are referencing is indeed the culprit here. The SQS reference does require the items to be sorted when calculating the MD5 digest, but it appears this sorting should be case-sensitive.
This issue will be fixed in the next update of the SDK.

[PavelSafronov]

We have just released version 2.3.24.3 of the SDK that resolves this issue.

[phillip-haydon]

Wow, wasn't expecting such a fast response! Thanks a lot @PavelSafronov <3 much love.