I was looking into optimizing S3 presigned_url generation too, so was very excited when Julik brought my attention to this gem, y'all have already done a bunch of solid work on it, awesome!

I'm interested in using the gem, and also potentially sending some PR's to add some features I might need. And/or forking if the features I need aren't compatible with the gem's ultra-optimization (like, I need per-url additional query params, like response_content_disposition).

Unfortunately, I'm a bit concerned about the "Hippocratic License". I understand and sympathize with the motivation to prevent sharing the fruit of your labors with entities that will use it to do harm. But I think this license would be incompatible with many projects I work on.

The license says that I can use this software only so long as I don't do harm "in violation of the United Nations Universal Declaration of Human Rights".

It also says if the software is used to provide a service to others, I have to also require any users of the service not to use the service in a way that violates human rights.

This seems to say that if I use your gem in software I provide as a service, I have to get all of my users to promise not to violate human rights. Which doesn't sound so bad -- except who decides what constitutes violating human rights? I am pretty sure the legal departments of any potential customer would be unwilling to sign such a thing.

If I write a gem which has this gem as a dependency -- then anyone using my gem to provide such a service becomes bound by this too? If I write a gem which has this gem as a dependency -- does my gem need to insist on this "do no harm" license too, "virally"?

I know that if I wanted to fork this gem to add features incompatible with it (say those custom headers ) -- I'd have to use this same 'hippocratic license' on my fork. That makes me worried about even looking at your source code anymore -- maybe I should remain ignorant of it, so I can write it from scratch based on the Amazon python example as you did, and apply a different license.

Note that the Hippocratic License is not compatible with the popular GPL. You can't combine code copied from a project licensed by 'hippocratic license' and code copied from a project licensed by GPL into a new project (or each into the other) -- the licenses are incompatible. EthicalSource/hippocratic-license#6

I understand and sympathize with the intent of this kind of license, but Idon't think it works out very well in practice. The key thing is "who gets to decide if something violates the UN Declaration of Human Rights"? Which gets especially complicated when you re-mix software into multiple projects, as we do with open source. For a tiny project it might not matter, but for lots of large/serious projects, it's not really feasible to incorporate code that requires you promise your whole project (and any of it's users!) won't do something that's pretty general/vague without being sure who decides what counts. Some projects I work on, including open-source non-commercial ones, would not allow incorporating code with such a license.

Would you be willing to consider using a more common license that is more compatible with existing code? It's your code, so it's up to you! If not, I will consider looking into reimplementing from the Amazon python example, instead of PR'ing or building on the great work you have done here, which is sad, but it happens.

It is common in ruby (and suggested as common in https://semver.org/) to add a git tag for a released version. There is one rubygems release, 0.1.0 of wt_s3_signer, so it would be nice to have a v0.1.0 tag in this repo.

One thing we could easily do with it is see how much (if anything?) has changed in master since the last/first 0.1.0 release. Without that tag, it's cumbersome/infeasible to figure that out. (Looking at the commit history it looks like there are few significant commits since the date of 0.1.0 release, so probably not?)

Would you consider using version tags in the future? If you use the rake release task that can be provided by bundler to do your releases, it adds and pushes a git tag automatically.

If it's still retrievable what git sha corresponds to the 0.1.0 release, it would still be helpful to tag!

The signer has a runtime dependency on the aws-sdk-s3 gem
The only place where this is (explicitly) used is here https://github.com/WeTransfer/wt_s3_signer/blob/master/lib/wt_s3_signer.rb#L138 Which is needed to get the bucket endpoint on line 44

What if we pass the bucket endpoint to the initialize ? Or is the aws-sdk-s3 gem doing anything else behind the scene?

It suggests passing in an instance of Aws::S3::Client into the for_s3_bucket method, yet the client keyword has since been removed from the for_s3_bucket method.