"The request signature we calculated does not match the signature you provided." when uploading with Aws::S3::Object#upload_file

[BanzaiMan]

This is possibly a variation of #923. With 2.1.30, a user reports that uploading file results in signature mismatch. The back traces are almost identical:

Before:

/home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.20/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call': The request signature we calculated does not match the signature you provided. Check your key and signing method. (Aws::S3::Errors::SignatureDoesNotMatch)
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.20/lib/aws-sdk-core/plugins/s3_sse_cpk.rb:18:in `call'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.20/lib/aws-sdk-core/plugins/param_converter.rb:21:in `call'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.20/lib/seahorse/client/plugins/response_target.rb:21:in `call'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.20/lib/seahorse/client/request.rb:70:in `send_request'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.20/lib/seahorse/client/base.rb:207:in `block (2 levels) in define_operation_methods'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.20/lib/aws-sdk-resources/services/s3/file_uploader.rb:42:in `block in put_object'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.20/lib/aws-sdk-resources/services/s3/file_uploader.rb:49:in `open_file'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.20/lib/aws-sdk-resources/services/s3/file_uploader.rb:41:in `put_object'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.20/lib/aws-sdk-resources/services/s3/file_uploader.rb:34:in `upload'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.20/lib/aws-sdk-resources/services/s3/object.rb:210:in `upload_file'

After:

/home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.30/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call': The request signature we calculated does not match the signature you provided. Check your key and signing method. (Aws::S3::Errors::SignatureDoesNotMatch)
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.30/lib/aws-sdk-core/plugins/s3_sse_cpk.rb:18:in `call'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.30/lib/aws-sdk-core/plugins/param_converter.rb:21:in `call'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.30/lib/seahorse/client/plugins/response_target.rb:21:in `call'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.30/lib/seahorse/client/request.rb:70:in `send_request'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-core-2.1.30/lib/seahorse/client/base.rb:207:in `block (2 levels) in define_operation_methods'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.30/lib/aws-sdk-resources/services/s3/file_uploader.rb:42:in `block in put_object'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.30/lib/aws-sdk-resources/services/s3/file_uploader.rb:49:in `open_file'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.30/lib/aws-sdk-resources/services/s3/file_uploader.rb:41:in `put_object'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.30/lib/aws-sdk-resources/services/s3/file_uploader.rb:34:in `upload'
    from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/aws-sdk-resources-2.1.30/lib/aws-sdk-resources/services/s3/object.rb:209:in `upload_file'

[awood45]

We're taking a look at this, may not be related to the previous issue.

[awood45]

I'd recommend, if possible, using Signature Version 4 signing in these cases and seeing if that helps to resolve the issue. We're working right now on a 2.2.0 release that will make this the default behavior, but you can also do this right now:

client = Aws::S3::Client.new(signature_version: 'v4')

[awood45]

I'd strongly suspect that our most recent release (2.2.0) will resolve this problem. Can you confirm?

[BanzaiMan]

@awood45 Funny you should mention! I just updated https://github.com/travis-ci/travis-ci/issues/4776.

Unfortunately, I've had a few reports (from our customers using private repositories, so I don't have direct links) that 2.2.0 is breaking their deployment with S3. I haven't been able to reproduce this myself, but in one case forcing 2.1.36 fixes the problem.

[awood45]

Do you have any information about those breakages?

[awood45]

Let me know if there's any information you can share - I haven't heard of breakages yet, would love to jump on any issues people are seeing immediately.

[awood45]

@BanzaiMan do we have any updates on 2.2.x helping this issue? I know in the other thread we seemed to be near a resolution to the Python packages issue, but have other customers seen this issue resolve with 2.2.x?

[BanzaiMan]

@awood45 Thanks for the update. Not sure yet whether 2.2.2 or 2.2.3 is helping yet. I also tested on Python, but couldn't reproduce, either.

[awood45]

@BanzaiMan should I leave this open, or do we think this has brought a resolution to the problem?

[BanzaiMan]

@awood45 Sorry for the delay in update. I'll ask users to see where we are. I haven't noticed any recent report of failures, but I'd like to be certain.

[awood45]

@BanzaiMan - It's looking like this update has likely fixed the issue, and that this is just a hard one to confirm (understandably). I'm going to close this for now, but I'm still monitoring the TravisCI issue, and please feel free to reopen or to open a new issue if there is any sign that this issue persists (or has recurred in yet another form).