StreamSigner uses signingTime.UTC()

[rb-kurrent]

The workaround for the sdk consumer is easy (always apply .UTC() before passing signingTime), but this feels like an unnecessary footgun. It cost me a couple of hours, at least.

[lucix-aws]

Is the event stream signer broken in the context of using an actual AWS service (i.e. not using the signer directly)?

[rb-kurrent]

Based on my own grep'ing around the code, it looks like all the cases where I see StreamSigner.GetSignature() called in the sdk, they're all using date := time.Now().UTC() to pick a signingTime, so I would guess the answer is "no".

[lucix-aws]

So what is the context you're using this in where not using UTC() is broken? More specifically, what concrete issue is this patch addressing?

[rb-kurrent]

I'm using the signing logic directly to write an S3 proxy, which uses a custom external authn / authz mechanism. The proxy is meant to be transparent to the s3 client in question, so the s3 client is configured with an endpoint pointed at the proxy and some fake credentials. When the proxy accepts a request, it forwards the request to s3 signed with its own aws credentials.

The reason the stream signing is important is that the proxy must not require buffering an entire blob upload (which might be huge) before signing and forwarding the request.

The failure observed is that if you use signingTime := time.Now() then the seed signature is valid but the chunk signatures will be off. The s3 API responds with what it thinks the string to sign is, and if you compare that to what the StreamSigner actually signed, you'll see that the dates can be off if utc time is on a different day of the month than you are at the moment. For me, that happens when I test my code late in the evening.

[lucix-aws]

OK, so it's basically because the short date gets formatted wrong (compared to the full version that's used elsewhere in the signature which I guess the format string forces to be UTC).

I also see we're doing this in request-response sigv4 so this should be fine really.

[lucix-aws]

codegen/integration tests fail in forks, those can be ignored

[rb-kurrent]

Cool. I rebased my work onto main. Is there anything else I can do, or is the rest up to you?

[rb-kurrent]

thank you!