Plugins cannot read other plugin configs

[staltz]

An improvement to secret-stack's security and overall avoidance of spaghetti dependencies.

This PR is a breaking change that allows each plugin to read config.global and config[pluginName] but nothing else.

E.g. with the config below:

{
  global: { seed, appKey },
  foo: { age: 18 },
  bar: { timeout: 3000 },
  qux: { path: "~/.config/app" }
}

A plugin named foo will get in its init function only config.global and config.foo:

{
  name: 'foo',
  manifest: {
    greet: 'sync',
  }
  init: function init(api, config) {
    // config is { global, foo }
    // ...
  }
}

global is now a reserved word (a plugin named "global" would emit an error log and be skipped.

[mixmix]

I think this works. I would like to float an alternative implementation which breaks fewer other modules but achieves same result:

• don't add "global" namespace
• each plugin "lays claim" to part of the config
• the subConfig it gets is "the namespaced part + the remaining config no other plugins layed claim to"

It's... messier (beacause a future plugin can call itself "connections" and swallow the global config called connections (so that would require reserved plugin name "connections")
But.. config.host and config.keys etc would always be there ... don't have to go to each module and add global.

It is more incremental, but might cause problems. What do you think?

[mixmix]

I have never used appKey. I would be in favoure of deprecating (wasn't it replaced with caps?)

I also don't think "global" is needed here? It feels more implicit to me that these are global?

[staltz]

I have never used appKey. I would be in favoure of deprecating (wasn't it replaced with caps?)

Out of scope?

also don't think "global" is needed here? It feels more implicit to me that these are global?

It's necessary in case you want to specify at this point some plugin-specific config, then you need a way of saying that the other configs are global, not plugin-specific. It can also be generally less confusing, if both SecretStack({ ... }) and .create(null, { ... }) object shapes follow the same schema.

[staltz]

How is this "laying claim" actually going to work? I'm afraid of having a complex system to solve a problem that's not very important. I think it's reasonable to incur this kind of breaking change cost, and change ways of working with secret stack.

I think the dumbest implementation is often a good bet, i.e. my PR is a pretty dumb approach. It's simple, also easy to know how downstream implementations need to comply.

[staltz]

Also, I must say, not merging this PR is a realistic approach for me. It's not a necessary step for my other tasks.