Please add amazonka-s3-encryption to stackage

[andreyk0]

Most (all?) of the other amazonka-* packages can be found there but this one seems missing. Thanks!

[brendanhay]

Hi @andreyk0, the reason amzonka-s3-encryption (#309) hasn't been released to Hackage is I'm unconvinced about using the underlying cryptographic libraries. If I had time, I would improve or contribute more full-featured libsodium / NaCl bindings and rely on those instead.

As it is, I'd like at least a code audit at the minimum before releasing amazonka-s3-encryption to the wider public.

[andreyk0]

Got it, thanks for taking a look! For what it's worth I found it to be pretty useful even as is, just relying on server-side encryption provided by S3 APIs. E.g. https://github.com/andreyk0/kms-s3/blob/master/Main.hs#L50

We started using S3/KMS combo for managing application secrets and keeping them outside of any app repositories. Seems easy and useful. I imagine others would find these APIs useful too, perhaps you could release it with a big "experimental API, may change in the future" warning or something, just to simplify build setup for those who'd like to use it anyway.

[brendanhay]

Thanks for sharing your code. It's somewhat ironic then that I actually wrote amazonka-s3-encryption to back credentials, but ultimately ended up using DynamoDB since a) secrets were small b) low latency was required.

I'd though I'd actually re-add the S3 backing storage to credentials at some point as either an option, or intelligent switch based on encrypted size.

Either way I'll certainly revisit amazonka-s3-encryption now that I know others are interested.

[andreyk0]

Cool! Thanks for pointing out your package, didn't notice it existed.

Our use case is very pedestrian, no latency constraints, just dealing with the usual "read a few secrets when an application starts up" situation. S3 is good enough for that and super easy too. Versioning and replication can just be configured on the bucket level and the fact that encryption happens on the S3 back end makes language interoperability easy. E.g. secrets managed with Haskell CLI can be picked up by JVM with no worries about syncing up encryption implementations. Doesn't apply to all scenarios but where it does - it's an easy way out.

BTW, if you are looking for a consistently low latency storage - be careful with DDB, their SLAs and marketing materials specify avg numbers as we've found out after actually measuring them and following up with the team. If you are not managing millions of secrets you may find elasticache/redis combo to be an interesting alternative, especially if there's a possibility of one of those secrets becoming 'hot', DDB doesn't like 'hot keys' very much.

Anyways, thanks for all your efforts on this project!

[endgame]

Removing "needs triage" since it's not going into the amazonka 2.0 RC. I see three broad possibilities for this:

1. it goes onto hackage as "no warranty"
2. it gets audited and goes onto hackage
3. it lives on in this repo, and people add it as experimental using source-repository-package or whatever

@brendanhay do you have a plan in mind for this?

[endgame]

Looks like it went to Hackage as part of the 2.0 release. Whether it goes into stackage is stackage's business.