Live data from Hacker News

Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

news.ycombinator.com

51–60 of 124 posts

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#51
post #44

> All content that resides under any "ee/" directory of this repository, if such directories exists, are licensed under the license defined in "ee/LICENSE". Man I really hate how the term "Open Source" is used nowadays.

We provide all the main functionality completely for free under the MIT license. What this means is that all the integrations (Docker, AWS, Vercel, Kubernetes, Terraform, etc) are available completely to everyone. Next to that, all the features related to secret sharing, and security are also available under MIT. ee is only reserved for some features that are (mostly) needed by enterprises (e.g., audit logs, sso, adv…

https://sso.tax/

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#52

Earlier quoted context omitted.

Would you say GitLab didn't manage to keep it right over the period of many years? I agree that it's very hard but that's also why we talk to our community and wee what they say about what features they need. I really happy hope that we can create a great open product for small teams and individuals over a long term too.

Actually, Gitlab used to be my go-to example of "Open Core done right", but now they have so many closed source features mixed in with open source features it is hard to use the open source product at all. I am either looking for a smaller product with fewer features anyway, or a product with more features (like maybe Gitlab tries to be) and the ones I want are the ones Gitlab happens to keep proprietary! Ultimately,…

I will definitely echo everything said here. Gitlab used to be an amazing example of doing it right but nowadays looking at their release notes, they sprinkle in one or two free features while the vast majority are locked away.

They do sometimes give the peasants access to the features months or years later, but the majority of features are still locked away.

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#54

Why should someone use this when there are options within each Cloudprovider as well as Github and the like as well?

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 technically as "secret sprawl" (see here for a fuller read: https://www.conjur.org/blog/what-is-secrets-sprawl-how-to-av...).

There's a lot of issues with secret sprawl but I think the relevant one to your specific question mentioning other cloud providers would be having missing secrets across infrastructure (you introduce a new secret to the codebase and forget to update it everywhere else, as well as communicate it or sync it through to other developers on your team) — applications crash, you lose time.

A big idea in secret management amongst others is the idea of *centralizing* your secret management in one place — update here, update everywhere. We help achieve that across your entire infrastructure and have a handy dandy CLI that also helps you inject secrets back into your programs (achieving secret management for local development with zero application dependencies) if you need that :D

I may be misinterpreting your question actually — Unless you mean why use Infisical versus other alternatives on cloud providers like AWS Secret Manager / Parameter Store, Azure Key Vault, etc?

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#58
post #29

Earlier quoted context omitted.

You open-sourced your code - isn't this scrutiny exactly what you would want to achieve? Alternatively, I would expect these reports to be reported via your issues tracker.

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.

> employ a security policy of reporting any security concerns via email

You don't have a security.txt, https://infisical.com/docs/security/overview doesn't mention it and it's not on your FAQ, so I don't blame ianpurton for not finding it. You have a 'Report a vulnerability' issue template on GitHub (https://github.com/Infisical/infisical/security/advisories/n...) but then your readme points to a security policy which says to email: https://github.com/Infisical/infisical/security/policy

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#60
post #44

> All content that resides under any "ee/" directory of this repository, if such directories exists, are licensed under the license defined in "ee/LICENSE". Man I really hate how the term "Open Source" is used nowadays.

We provide all the main functionality completely for free under the MIT license. What this means is that all the integrations (Docker, AWS, Vercel, Kubernetes, Terraform, etc) are available completely to everyone. Next to that, all the features related to secret sharing, and security are also available under MIT. ee is only reserved for some features that are (mostly) needed by enterprises (e.g., audit logs, sso, adv…

Audit logging and SSO is pretty basic functionality that requires very little (many people would argue no) additional effort or cost to maintain on the development side.
Post reply on HN