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

Infisical – open-source HashiCorp Vault alternative

github.com

Post reply on HN
Print view View original

101–109 of 109 posts

Re: Infisical – open-source HashiCorp Vault alternative

#101

Post by irq-1 »

danenania wrote: post #4

EnvKey ( https://www.envkey.com/ ) is another OSS alternative to Vault with a bit more focus on security (disclaimer: I'm the founder). We have a comparison with Vault here: https://www.envkey.com/compare/hashicorp-vault/ We'll probably write up a comparison with Infisical soon as well but I'd say the main thing is that our end-to-end encryption has no opt-outs (as Infisical does for many of its integrations), and we…

I looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.

Re: Infisical – open-source HashiCorp Vault alternative

#102

Post by yencabulator »

Znafon wrote: post #18
mirzap wrote: post #15

Earlier quoted context omitted.

What's wrong with monetization? You understand that OSS's significant problem is a lack of funding, where authors don't want or don't know how to monetize their product? Sentry looks like a good model for OSS, and it's proof that you can make a living from OSS. I also don't have anything against "enterprise features" for which you need a license, while most features are available in OSS version.

> What's wrong with monetization? You understand that OSS's significant problem is a lack of funding, where authors don't want or don't know how to monetize their product? > Sentry looks like a good model for OSS, and it's proof that you can make a living from OSS. Sentry is using the BSL, the very same license that HashiCorp has switched to but that change has not been received well.

If Sentry used BSL from the beginning, and refrains from calling itself an "open source company", that's just another company doing its thing.

It's the bait and switch and bullshit language ("evolving open source") that gets people riled up.

Re: Infisical – open-source HashiCorp Vault alternative

#103

Post by yencabulator »

josephcsible wrote: post #41
nine_k wrote: post #39

Earlier quoted context omitted.

Dual licensing (copyleft + commercial) has been a thing for a long time. Open Core is also a thing, and I think it's better than BSL because at least the core part is truly open.

I have nothing against dual licensing, but that's not what "enterprise features" are. As for Open Core, there is one case in which I think that's fine: when none of the proprietary parts would be useful at all in an otherwise 100% FOSS environment. For example, if Linux support were FOSS but all the Windows- and macOS-specific code were proprietary, or if a plugin to talk to Bugzilla were FOSS but a plugin to talk to…

Open Core usually fails the FOSS community when the company either 1) makes some essential features like OAUTH/SSO or 2FA Enterprise only, or 2) is openly hostile toward open source components that compete with its own Enterprise features.

How well would your example companies deal with a PR adding open source macOS platform support, or an open source JIRA bridge?

Re: Infisical – open-source HashiCorp Vault alternative

#104

Post by danenania »

irq-1 wrote: post #101
danenania wrote: post #4

EnvKey ( https://www.envkey.com/ ) is another OSS alternative to Vault with a bit more focus on security (disclaimer: I'm the founder). We have a comparison with Vault here: https://www.envkey.com/compare/hashicorp-vault/ We'll probably write up a comparison with Infisical soon as well but I'd say the main thing is that our end-to-end encryption has no opt-outs (as Infisical does for many of its integrations), and we…

I looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.

Hmm thank you for the feedback, but I'm not sure if I follow you. Which golang code are you referring to? We have two different Go libraries.

One is envkey-source (https://docs-v2.envkey.com/docs/envkey-source), which contains core client-side decryption and verification logic. It can be used standalone from the shell like this:

  # some-command runs with EnvKey vars in its environment
  $ envkey-source -- ./some-command
Or like this:

  # EnvKey vars are set in current shell
  $ eval $(envkey-source)
  $ echo $SOME_ENVKEY_VAR
And second, envkey-source is also wrapped by our language-specific SDKs, including one for Go: https://github.com/envkey/envkey/tree/main/public/sdks/langu...

It allows you to integrate with a Go project like this:

  // main.go
  import (
    "os"
    _ "github.com/envkey/envkeygo/v2"
  )

  // assuming you have GITHUB_TOKEN set in EnvKey
  token := os.Getenv("GITHUB_TOKEN") // this will stay in sync
We're planning to do a docs-improvement pass soon so I'm very interested in how we could clear up any confusing aspects of how the different pieces fit together.

Re: Infisical – open-source HashiCorp Vault alternative

#105

Post by revskill »

vmatsiiako wrote: post #93
revskill wrote: post #88

I tried infsical before, it's bad. It lacks of the most important feature: Auto save your form.

Could you please explain what you mean by auto saving the form?

I got angry once i lost all my input when i navigate away as i didn't remember i saved the form or not.

Re: Infisical – open-source HashiCorp Vault alternative

#106

Post by irq-1 »

danenania wrote: post #104
irq-1 wrote: post #101

Earlier quoted context omitted.

I looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.

Hmm thank you for the feedback, but I'm not sure if I follow you. Which golang code are you referring to? We have two different Go libraries. One is envkey-source ( https://docs-v2.envkey.com/docs/envkey-source ), which contains core client-side decryption and verification logic. It can be used standalone from the shell like this: # some-command runs with EnvKey vars in its environment $ envkey-source -- ./some-comma…

The second project; it only does caching of the keys. It's a big advantage to use your software without any SDK or client code. You should make it clear that it's optional.

Re: Infisical – open-source HashiCorp Vault alternative

#107

Post by Znafon »

yencabulator wrote: post #102
Znafon wrote: post #18

Earlier quoted context omitted.

> What's wrong with monetization? You understand that OSS's significant problem is a lack of funding, where authors don't want or don't know how to monetize their product? > Sentry looks like a good model for OSS, and it's proof that you can make a living from OSS. Sentry is using the BSL, the very same license that HashiCorp has switched to but that change has not been received well.

If Sentry used BSL from the beginning, and refrains from calling itself an "open source company", that's just another company doing its thing. It's the bait and switch and bullshit language ("evolving open source") that gets people riled up.

Sentry has not been using BSL since the beginning.

Re: Infisical – open-source HashiCorp Vault alternative

#108

Post by danenania »

irq-1 wrote: post #106
danenania wrote: post #104

Earlier quoted context omitted.

Hmm thank you for the feedback, but I'm not sure if I follow you. Which golang code are you referring to? We have two different Go libraries. One is envkey-source ( https://docs-v2.envkey.com/docs/envkey-source ), which contains core client-side decryption and verification logic. It can be used standalone from the shell like this: # some-command runs with EnvKey vars in its environment $ envkey-source -- ./some-comma…

The second project; it only does caching of the keys. It's a big advantage to use your software without any SDK or client code. You should make it clear that it's optional.

Ok, understood. The purpose is not so much caching as setting the vars in the environment so they can be accessed in a standardized way that is compatible with dotenv, 12 factor apps, etc. But yes, you could also say they’re being cached.

We do try to mention in the docs for each SDK that envkey-source can be used from the shell instead, but I’m sure we can make it clearer. Thanks again!

Post reply on HN