Since this is what basically every secret-sharing system purports to do, and the major ones are all FOSS, I'm curious if you could tell me why someone would pay for a new commercial secret-sharing system.
This seems like the classic "OSS is free if you value your time at zero" answer, but I don't think it is wrong.
I think this is the type of tool which I model you as having relatively little need or use for (since you care very strongly about the details and are willing to burn N days on getting e.g. HashiCorp Vault working) and which I would adopt ~instantly rather than trying to again stitch together all of the Ansible scripts required to get Vault working properly.
"So I can give an external Rails contractor all the API keys they need to run the application without also giving them e.g. my payment processor secret key? And I don't have to configure their Macbook to make this happen or explain to them how to use a toolchain to get e.g. passwords out of an encrypted Ansible vault? Done." would be my approximate reaction here.
I'm looking at their integration guide and Vault's side-by-side and trying to model out installing them in a typical boring Rails app. My mental math is "~25 minutes and one deploy, maybe an hour if you want to monkeypatch Rails.secrets" versus "2~3 days, assuming you've already got a well-maintained Ansible All The Things setup running; a capital-P project otherwise."
It's my ambient impression that this would improve secret management at, hmm, 98% of Microconf attendees' shops. My estimate for e.g. software companies which have raised an A round is not lower than 50%.
I would probably be much closer to (my model of) your POV on this matter if I were making the decision on behalf of a company with elevated security requirements or which already had a staffed-up DevOps or security team.
Let me ask a question that is closer to the spirit of what I meant before:
Given that there are already carefully tested FOSS secret sharing systems, why should some other enterprising soul not just host one of them and compete, rather than building a new proprietary scheme?
This is a good question, and believe me, it's an approach I strongly considered.
In the end, I couldn't find a system that would work well as a base for the functionality I wanted to build. If I could have, I would have been all over it, but it would have required compromises to the simplicity and convenience of the service that I didn't want to make. No secret store that I know of is designed in a way that would make it scalable as a saas service like EnvKey without heavy retrofitting.
EnvKey's main focus is on convenience and speed of integration.
- As a hosted service, it offers a ~5-10 minute integration workflow, and doesn't require setting up/maintaining your own secrets server.
- Pulling secrets/config into an app is extremely simple vs. existing open source solutions. You set a single environment variable, add 1-2 lines of code, and you're done. There are a lot fewer hoops to jump through.
- It has a UI that makes it convenient to manage different environments (development, staging, production) right next to each other, and provides a quick visual overview of developer and server access levels. It also offers some other useful capabilities like YAML-style inheritance between environments and quick/secure invitations for collaborators.
In my experience, there are a lot of companies out there who are managing secrets poorly (email, Slack, Google Docs, etc.), but don't necessarily have the capability or desire to make a major DevOps investment in improving the situation. EnvKey offers a much quicker option.
As a side note, while EnvKey's server is not open source, the app and client libraries are all MIT-licensed, and they are designed specifically not to trust the server.
In the same vein, why should the client be closed sourced at all?
I skimmed through the source of the npm package and see that it's a shim for a binary blob for each target environment (linux32, linux64, windows, etc). It's 8MB per platform and the tarball has all the other platforms there as well so there's 52MB of junk added to each app build:
All the clients (including the app) are fully open-source. Both the npm package and the ruby gem wrap a lower-level library that is written in Go - https://github.com/envkey/envkey-fetch. This implements core OpenPGP logic in a cross-platform way. I'll try to make this clearer in the Readme.
I could also look at splitting out platform-specific packages for those who only need a subset of them, but the reason for including every binary is to make it plug-and-play for multi-platform teams.
> every secret-sharing system [...] and the major ones are all FOSS
Can you recommend a specific one? I'd like to integrate a secret-sharing system into my personal set of computers and applications.
In case you are wary of giving recommendations, perhaps you could just list the top three instead. But ideally I'd like to have a specific recommendation. Also, if said secret-sharing system is written in rust an is available as a library I'd be extra super happy.
Having just said that, I decided to do a search on crates.io. https://crates.io/search?q=secret. It seems that at least a couple of those are about the thing that we are talking about here.
