mreinsch

Why is that? Isn't that exactly the same problem whether you're using environment variables or a config file?

This is indeed an issue, though with a modern cloud based infrastructure and management systems there is no longer a need to create backups from your production servers. They can be automatically recreated and no important data is stored on them.

as long as you don't store your config then in the same repository as your code, that works fine for me.

sniffing isn't the main issue I'm trying to avoid, it's accidental exposure. I.e. minimising the risk that during normal operations the secrets get exposed somehow.

I have to admit that I don't know a thing about TPM. Like is it also available in virtual environments like AWS is providing? How could this be automated? You don't want to enter a passphrase every time a server (re)boots. Would love to hear if anybody successfully used that.

Thanks for that idea of deleting sensitive environment variables. I like that for hosters such as heroku which use ENV variables for config (including secrets) by default.

Thanks. I'm mainly looking at this from the point of how your secrets could be accidentally exposed.

I applaud to postfix for sanitising the ENV, and it's very good practice to do so. But are all the frameworks doing it correctly? Maybe some code is then also just spawning new processes without sanitising? You could argue that's a bug then (which I completely agree), but not all projects are run like postfix...

I agree that ENV variables are useful for general configuration, that's exactly what they were invented for...

ENV variables are not restricted by user though, your process can spawn another process under a different user and give it the same environment. It's the nature of the environment that it is usually inherited from the parent which causes the issues when we're talking about secrets.

The permissions on our chef repository are different. We can give access to the main code repository without giving access to the chef repository.

Alternatively, if you're running on AWS you could also fetch the secrets config file from an S3 bucket which is only accessible by your production servers.

You're right that a tool which runs under the same user could read your config file and thus could access to your secrets.

But there is one main difference: that tool would need to do so explicitly, with the intent of reading (and possibly exposing) your secrets. For me, that's a huge difference from having the secrets being implicitly available to the process through the processes environment.

yeah!

great, looking forward!

Asiajin (http://asiajin.com/) is covering Japanese startups (among other stuff)

Yes, you'll be able to get in. But it'll be ¥3,000 and you'll get two drink tickets instead of the buffet ticket. Check the event description on http://tbtpe.doorkeeper.jp/ for all the details. Anyway, hope to see you there. I'll be helping out at the door as well...

How are you running delayed_job or other custom daemons?

Great! I'll make sure to come along again!