dangtony98

9 ms·

91.
by dangtony98 4y ago
In many cases, your infrastructure may be sprawled from local development to cloud providers and CI/CD pipelines like you mention; you may have many environments each requiring their own set of secrets. This phenomenon is known technic
92.
by dangtony98 4y ago
I definitely share the concerns/thoughts around open core and keeping too many features closed source here; it's a very difficult thing for companies to figure out what the right balance is for public/closed-source features.
93.
by dangtony98 4y ago
Open source is a lot to unpack haha — There's a ton there but yea I think giving the ability for people to self-host the solution is a really important in our mission to increase access to secret management tools to all developers. Inf
94.
by dangtony98 4y ago
Yup! We appreciate feedback we can get across all aspects including security but employ a security policy of reporting any security concerns via email - this is pretty standard practice we've seen.
95.
by dangtony98 4y ago
Ack. Thanks for the points. Un-packing a few things: 3. Definitely — We're working to cut our dependencies in the coming months. Most existing dependencies (the backend at least - I focus more on this area) we stick to those widely use
96.
by dangtony98 4y ago
Yeah that's correct. The permissions switch can only be on the client because that's where sharing the vault key with Infisical by encrypting it under one of its public keys occurs.
97.
by dangtony98 4y ago
This has to do with how our underlying cryptography works; it's end-to-end encrypted by default with opt-out ability for integrations that need it. You'd have to manually login to Infisical and grant that permission but the platfo
98.
by dangtony98 4y ago
We received a ton of feedback since our last HN post regarding many aspects of Infisical. We've had to prioritize user feedback in the last month, and one of the decisions we made together with our community was to move robust testing