aws-beam/aws-erlang

Any reason for aws-erlang to not use aws_signature?

onno-vos-dev opened this issue · 4 comments

Hi there,

TLDR:
Is there any reason why aws-erlang does not use aws_signature?

At my company we use aws-erlang extensively to interact with S3 and we've had several issues with aws-erlang over the past month or so leading us to consider erlcloud which is a shame 😞

The problems seem to stem from aws-erlang implementing it's own version of aws_signature natively inside aws_request:sign_request/5 rather than use aws_signature.

List of issues that have been discovered with signatures:
#61
#62

Both of the above issues are fixed in aws_signature which is also the library of choice for aws-elixir as can be seen here: mix.exs#L30.

In general it seems that there are a few diffs between aws-elixir and aws-erlang where fixes in one, are not ported to the other or even at the very least opened up as an issue for someone to grab. The further this goes, the more problematic it will be to figure out the diff and apply those to get back in line with eachother. I for one am not even sure if the fixes that we (from Klarna) have implemented on aws-erlang are ported to aws-elixir for example and if they're even applicable there since we don't use Elixir and have no good way of testing this either.

If there's no good reason for aws-erlang having it's own implementation, I'd like to really comb the code of aws_signature and see if there are any differences that could lead to a regression and if it's feasible to simply replace aws_request:sign_request/5 with a call to aws_signature:sign_v4/10 with the respective option dance of uri_encode_path for S3 as that's apparently special :-)

My hazy memory is that I implemented the first signature logic in aws_erlang and then it was later extracted to aws_signature to be shared with aws_elixir and, I think, to maybe grow some other features. I think the current situation is more about the history of events than an explicit decision to do things this way. It sounds like having aws_erlang depend on aws_signature would solve the issues you're seeing and also improve the maintainability of the project, so I'd say go for it if you have the time and energy to do so.

I'll take a stab at it 👍 Thank you for your fast reply and good to know the history behind it ❤️

Any more momentum on this issue?

Any more momentum on this issue?

Not yet, it's on my todo list but there's a few other things but since it's a tad of a scary change to roll out, ideally I'd like to robustify the testing a tad prior to making this change so I haven't quite figured out how to tackle this "safely" yet.

If you have any ideas or would like to co-operate on this task together, I'd be happy to pair up with you and take a stab at it together?