Ease of debug when building on bespoke base container

[ianmiell]

Problem:
eg container with shutit.tk.mysql.mysql on it
we build another container that depends on above
password config is different, so tests fail when trying to connect

Solutions:
Skip test (don't like this)
Don't have things that depend on password in tests (not ideal)
Store "reserved for test" configs as one-way hash (insecure?)
Store alphabetized-order rep'n of per module as one-way hash
Store alphabetized-order rep'n of complete config as one-way hash
Store all configs in container manifest (means having passwords in there, insecure)

[aidanhs]

Does it make sense to impose a strong separation between 'core' config sections (repository, host, container) and module sections? I'm thinking that module builds should never behave intentionally differently based on core config sections.

By enforcing this separation, it becomes safer (but still not completely) to serialise module configs into the container because they simply cannot contain passwords of the user. Instead they end up containing the passwords of e.g. mysql...which a user at the other end has to know anyway.

Now, assuming module configs are serialised to the container, we can secure any potentially sensitive configs by not putting them in a module. E.g. if we have com.corp.shared_folder.shared_folder and com.corp.vcs.git_login which need common ldap credentials but shouldn't have stored, we'd put them in a section called com.corp.passwords (or even just com.corp).
If either of the modules above has a requirement to use the credentials of the current user (e.g. authenticating to use the version control system), that code would be moved out of build (which only gets run once) and into start.

Which boils down to "Store all configs in container manifest", with restrictions to remove sensitive items - as noted, the only passwords left would be passwords a user needs to know anyway.

[ianmiell]

Is this still an issue with the (now-documented) config changes?

I'm aggressively closing hoping for a re-open if so.