> >--f46d044787ffa1cd7704c5b76f97 >Content-Type: text/plain; charset=UTF-8 > >On Thu, Jul 26, 2012 at 9:09 AM, Michael Raskin <[email protected]> wrote: > >> >Right now, I need to distribute and sync my "secure files" to multiple >> >machines. If I could just store the mysql password in the store, >> >gpg encrypted, that would make things a lot easier. >> >As files can be encrypted for multiple receivers, I can manage >> >permissions through that mechanism and just store everything in 1 place >> >(channel). >> > >> >Then, during activation of a new configuration, when some password is >> >needed (like when creating a mysql database), "gpg -d" would give a >> >passphrase prompt to the person who has chosen this config. >> >To avoid interactivity, a passphrase-less key can be used (granted, then >> >we're back to the current security-level where gaining root/physical >> >access gives you all plain passwords), or gpg-agent. >> >> So what we want is to make some storage for secrets that is accessible >> only to the associated builder (so that the secrets are not stored in >> derivations)? >> > >Not sure if this is what I propose. >Depends on what you mean by "builder". If you mean the script that builds a >derivation, then no. >I want to store encrypted (safe to be readable by everyone) files in the >store and it's up to the "builder" (person who gives the command to >activate a config) to make sure he has the decryption key.
To create these encrypted files we would need to have some way to call encrypting program. You could hard-code into Nix a way to call GPG, or hardcode a way to pass something to builder process without leaving its content in derivation. Maybe the secrets would be cleaned up after succesful builds. >This can be a system-wide key, or more fine-grained (organisational units), >or even separate per-secret-per-machine keys. >Indeed some on-the-fly scheme that really acts per build (derivation) is >probably possible, but I don't think any secrets are needed during build, >but rather during activation. Public keys can be specified explicitly, so no problem. Private keys would be root-readable-only or require access to root-started gpg-agent. All this could be described in expressions. >I think a in-plain-sight solution using encryption won't require much >changes to the way the nix (store) currently works. I tried to do what you say, but you need to remove derivations in that case, or encrypt manually. >Extending this idea a little bit: >We can probably have some key management daemon listening on a socket (like >gpg-agent/ssh-agent) or network port (for central management). Then just >point nixos to this socket through a config setting or env var >(NIX_SECRETS_SOCKET) when activating and have it ask for keys there. (the >agent will then prompt/log that the key for "mysql-machine3" is being >requested) Are you sure that adding _Nix_ support for key management daemon is needed? _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
