Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 124 posts

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

#81

Post by grinich »

pc86 wrote: post #60
vmatsiiako wrote: post #46

Earlier quoted context omitted.

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.

I'm the founder of https://WorkOS.com ("Stripe for SSO") and I can definitely say it takes a lot of eng work to build and maintain. The complexity is fractal as you scale to more and more enterprise users with esoteric systems.

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

#82

Post by brandonmenc »

s1k3s wrote: 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.

Why, what do you think it means?

https://www.gnu.org/philosophy/open-source-misses-the-point....

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

#83

Post by vmatsiiako »

brandonmenc wrote: post #82
s1k3s wrote: 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.

Why, what do you think it means? https://www.gnu.org/philosophy/open-source-misses-the-point....

Indeed! We are also planning to add the MIT-only copy of our repository that is going to remove all the ee licensed code.

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

#84

Post by nonethewiser »

dangtony98 wrote: post #19
nonethewiser wrote: post #12

Earlier quoted context omitted.

How does getting permission make you “able” to read secrets? It seems like maybe you can read everyone’s secrets but you’re promising not to.

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 platform itself would be unable to read your secrets otherwise. Technical details: In Infisical, secrets are stored in vaults (we call them projects). They are encrypted symmetrically by vault key…

Very well explained, thank you.

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

#85

Post by Implicated »

dangtony98 wrote: post #66
1ba9115454 wrote: post #61

Earlier quoted context omitted.

Standard practice is to do a full security audit before you onboard customers.

We're preparing to do a SOC2 with Vanta first followed by a security audit with some firm like Trail of Bits next. We're fortifying the codebase every day and would expect this process to be complete in the next 2 quarters.

> the next 2 quarters

6 months? I'm not being sarcastic here - I'm not on the security or enterprise side of things, but this seems like a long way off for something like a secrets manager. Just out of curiosity, what would hold you back from doing this _prior_ to launching?

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

#86

Post by Hansenq »

dangtony98 wrote: post #31
ianpurton wrote: post #11

Hi. I'm also working on an E2E secrets manager. https://github.com/purton-tech/cloak A few tips. 1. It looks like I'm able to do account enumeration on your login page. For a secure app you want to make sure this is not possible. 2. Your CSP https://csp-evaluator.withgoogle.com/ has unsafe-eval. I would lock that down. 3. Your app seems to be JS based, which is OK but it means you have a whole bunch of supply chain a…

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 used and those essential to the platform; there're also certain dependencies directly linked to integrations with third-party platforms (e.g. AWS, Octokit - GitHub, etc.). 4. We'll definit…

Check out https://socket.dev/ Been super impressed by their approach to identifying and securing codebases against supply chain attacks (and I believe they have a special deal for open source repos too!)

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

#87

Post by vmatsiiako »

Implicated wrote: post #85
dangtony98 wrote: post #66

Earlier quoted context omitted.

We're preparing to do a SOC2 with Vanta first followed by a security audit with some firm like Trail of Bits next. We're fortifying the codebase every day and would expect this process to be complete in the next 2 quarters.

> the next 2 quarters 6 months? I'm not being sarcastic here - I'm not on the security or enterprise side of things, but this seems like a long way off for something like a secrets manager. Just out of curiosity, what would hold you back from doing this _prior_ to launching?

I completely agree! I must say though, this is not fully dependent on us! SOC2 is a very lengthy process that also depends on auditors. This is one of our main priorities at the moment.

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

#88

Post by dangtony98 »

Implicated wrote: post #85
dangtony98 wrote: post #66

Earlier quoted context omitted.

We're preparing to do a SOC2 with Vanta first followed by a security audit with some firm like Trail of Bits next. We're fortifying the codebase every day and would expect this process to be complete in the next 2 quarters.

> the next 2 quarters 6 months? I'm not being sarcastic here - I'm not on the security or enterprise side of things, but this seems like a long way off for something like a secrets manager. Just out of curiosity, what would hold you back from doing this _prior_ to launching?

Getting certified is unfortunately not an overnight task … SOC2 alone will likely take months and that’s not yet factoring in the security audit as well. As much as we’d like to have it done ASAP, a lot of it is dependent on the length of the process and requirements to be met - that’s why my estimate is within the next 2 quarters (sooner the better).

As an open source company, we’ve basically “launched” since the moment we open sourced the codebase - it’s a constant iteration process for us and every week we release security updates as part of our roadmap. Security certifications and audits are something we’re starting to do in parallel at the moment whilst still being early in our journey (open sourced 3 months ago roughly).

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

#89

Post by dangtony98 »

grinich wrote: post #81
pc86 wrote: post #60

Earlier quoted context omitted.

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.

I'm the founder of https://WorkOS.com ("Stripe for SSO") and I can definitely say it takes a lot of eng work to build and maintain. The complexity is fractal as you scale to more and more enterprise users with esoteric systems.

Big fans of WorkOS! Happy to be talking with your team about SSO options for Infisical :)

We built out all our OAuth2 integrations with other platforms (different from SSO but something relatable), so we have an idea of how much work it is to maintain these types of “integrations” and related services… Clearly enough to warrant entire solutions like WorkOS dedicated for this exact purpose.

Post reply on HN