Getting distribution right is apparently hard. I've started a branch for a new module called KeyDrop that will handle that. It will supply all of the guts for a client/server model for secret distribution, with an offline master keyring.

• You designate a server to store the master keys and vaults and write a trivial wrapper to get HTTP queries into and out of the KeyDrop class for it. This is the KeyDrop server.
• The KeyDrop server has all the master keys and all the vaults for all the clients, however the master keys are encrypted, and the KeyDrop server is never given the information needed to decrypt them. Compromising the KeyDrop server gains an attacker nothing at all.
• Each KeyDrop client is assigned an ID and a client key. The client key is stored locally on the client, and its only purpose is to decrypt the master key. The master key is never stored on the client.
• When the client is running, if it doesn't have a copy of the master key in RAM, it asks the KeyDrop server for the master key. The KeyDrop server returns an encrypted master key, which the client must decode. For efficiency, the master key should then be tucked away somewhere (NOT on the filesystem).
• The client can also ask the KeyDrop server for a list of updates to that client's vault.
• A mechanism is provided to push updates to client vaults out to the KeyDrop server. You should provide your own mechanism to force your client to request an update.
• Another mechanism is provided to organize all the client, vault and shared keys in an encrypted master keyring. This obviously should be kept offline.

I think this actually solves the entire question of how to securely configure a server; each KeyDrop client only needs a couple of items - the client ID and client key - to automatically and securely pull, store and update when needed all the other secrets assigned to that client.