Hacker Newsnew | past | comments | ask | show | jobs | submit | quinndiggity's commentslogin

To be brutally honest (as if not already), Doppler makes me wonder why not simply focus on building on-top of open solutions like Vault. Considering there is no on-prem version of Doppler, you could essentially run Vault behind the scenes and provide the experience you are aiming to deliver with Doppler, giving you a marketing strategy for free ("Ready to run secret management with a focus on usability; the fastest zero to production option for 'Enterprise' secret management"), that doesn't require contrasting yourself ("We ARE Vault; it's a great tool, we made it easier"), and could even value-add or contribute back upstream (vs trying to cannibalize someone who could be your peer), and even reduces your engineering effort and the need to revalidate all the security primitives (and have 3rd parties do that for you just by their using it).

Disclaimer; I have nothing to do with HashiCorp, they've just done right by me, have been great to the community, and are always improving and learning from their mistakes. A nerve is struck when marketing tells people that they are using the wrong tool (without backing that up with data), and making comparisons to a protocol which has fallen to the wayside aside from limited use cases but otherwise is predominantly insecure.


Thank you for acknowledging the need for trust, self-hosting + auditability.

However, please stop trying to contrast yourself with these analogies. Owncloud and Nextcloud both have hosted OR on-prem versions

https://owncloud.com/pricing/

https://nextcloud.com/providers/


He compared it to Dropbox...


I think the context was lost here - https://news.ycombinator.com/item?id=24724730

They did compare it to all of these


"An analogy: there are open source versions of Dropbox for users that don't trust Dropbox with their files (NextCloud, ownCloud, etc.), however this comes with the friction of having to host your own solution. We are more like Dropbox, where we want to create a solution that is incredibly easy to install, manage, and work with."

NextCloud: self-host OR pay for a managed option (this means someone runs it for you.) ownCloud: self-host OR pay for a managed option (this means someone runs it for you.)

He compared it to Dropbox, Nextcloud, and ownCloud.


> I am not invalidating someone's right to privacy.

You are saying that not having the choice to choose what to share is acceptable though. Privacy isn't about having something to hide, it's about having the same rights you have with your day-to-day thoughts; you aren't forced to shout every single thought that pops into your mind, you are able to pick and choose what you would like to express and share. Privacy and encryption aim towards that goal.


Wait wait wait, and this is paid and hosted too? Bleh, nooooo thanks. I'm not sending private and secret key material to a bunch of ex-Uber employees (gross on that point alone), but nevermind to ones who looked at the existing market, didn't understand the tool-scape, and essentially decided to roll their own crypto...


Whoa, please don't be a jerk in response to other people's work on HN. It's fine if you don't like it, and it's certainly fine if you have substantive criticism. But it's not fine to put down others, or their work; internet cultures can easily turn in that direction and we're hoping to avoid that here.

The Show HN guidelines (which also apply to Launch HNs) have a few things to say about this: https://news.ycombinator.com/showhn.html, and of course the site guidelines do also: https://news.ycombinator.com/newsguidelines.html.


Understood, and yes my comment was harsh, perhaps a bit much so

However `Enterprise tools like HashiCorp Vault and AWS Parameter Store felt like we were stuck using FTP instead of Dropbox!` is in itself bashing other peoples' work, and misleading prospective users.

It's not alright to mislead people, and the trends over the years of new engineers without a ton of experience looking at a battle-hardened, vetted system with their one specific use case and no understanding of the endless numbers of refinements that resulted in the predominant solution that solves more problems and edge cases than just their partially understood use case, is... why we have shit like this coming out of Apple (for example)

https://lapcatsoftware.com/articles/macl.html

Despite being a millennial, I can't help but agree with this sentiment:

> When I try to list the contents of the Documents folder in Terminal, I get a permissions dialog, because Millennials are killing Unix.

Understand _why_ things are done the way they are before you write them off as inferior and re-invent the wheel, otherwise you'll simply discover all the things you didn't understand previously, and create effectively the same solution, only poorly implemented and without all the vetting and refinement that went into what was already there before you came and "did it better".


Not to start a flamewar, but as a 35 year veteran, the permissions dialog is the same as what SELinux would give you. Apple are implementing an RBAC and require authentication and authorization on a per-app basis.

This is on top of their SEP and read only System volumes with secure boot. Leave aside the argument about system openness to modification, that is beyond Unix's security and permissions model.

Sure, Unix offers some of that with chmod and mount options, but it's hardly a comprehensive solution.


It looks like this https://www.nomadproject.io/docs/integrations/vault-integrat...

It's incredibly simple, and a breeze to use.

``` job "vault" { group "demo" { task "task" { vault { policies = ["database"] } template { env = true data = <<EOF {{ with secret "database/creds/production" }} DB_USERNAME={{.Data.username}} DB_PASSWORD={{.Data.password}} {{ end }} EOF } } } } ```

edit: thanks HN formatting


with this setup, Vault will create a new database user based on the configuration you set (read-only for some services, for example), and will attach a time-to-live to those credentials; as long as the application is using them, it will renew the TTL. When an application is killed, or scaling happens, etc, and the application instance isn't using those specific credentials, Vault will clean up and remove the unused account cleanly

Can do all sorts of great things with this; for example TLS (ssl) certificate renewals, etc, as the certificate expiry IS the TTL; when a certificate needs to be renewed it can happen automatically and your application can receive any signal you choose (SIGHUP, for example)


Fascinating! Thanks for sharing, I had no idea this was possible.


I guess dynamic secrets are too "ftp" for Doppler, eh?

You lost the entire audience who have actually used Vault before when you claimed it was too complex for your team to understand.. Why would I trust a company staffed with a crew that can't even understand the tools they are trying to compete with


I think part of the reason people are chiming in on the distinction is that a controller is comparable to a mouse for a computer; a controller requires something else for any functionality, at which point you're comparing a general computing device that can do anything to a much more restricted special use device


your comment said "decks" though - the ddj1000 is _closer_ to decks, but it's still a controller.

decks, you're thinking (some examples):

cdj350 cdj400 cdj800 cdj850 cdj900 cdj1000 cdj2000 xdj1000 etc


this guy mixes


It's literally impossible, in case you haven't tried recently.

If you don't want to send them a government issued photo ID, you can make a new account that lasts 10 minutes and then is locked on you and holds any accounts linked to it hostage as you can't sign in.


> literally impossible

come on


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: