First I want to thank everyone for their feedback in the last thread about the configuration management system. While it was long and hard, a lot of really good ideas came out of it. What I'd like to do here is summarize some of the points of contention and propose alternatives for further discussion. It seems there is a lot of agreement around the basic ideas behind the proposal and if we can work out the controversial pieces, then we are in pretty good shape to move forward. If you need the background to this discussion, you can read the original proposal as well as the very long comment thread it spawned (second longest in gdo history!)
So first off, I think it is fair to say that the community hates the proposed json.php hybrid format with the burning passion of a thousand suns. This was meant to be a compromise which addressed the concerns of having sensitive information in a readable directory that could be exposed if .htaccess/web.config protection was not present or configured improperly. The major objections to this are
- It creates another 'Drupalism', a format that is similar to an established standard with our own special sauce added (just like .info files are sort-of-but-not-really .ini files.)
- It significantly detracts from developer experience by breaking syntax highlighting and code verification in IDEs and editors.
Out of that thread came two related ideas that, when put together, should hopefully allow us to use pure JSON as well as address any security concerns that arise.
The first idea was put forth by grendzy, who suggested that instead of storing the config files in a standard place, we store them in a directory that is named using a hash of your site's private key, like sites/default/config_723fd490de3fb7203c3a408abee8c0bf3c2d302392. The files in this directory would still be protected via .htaccess/web.config, but if that protection failed then the files would still be essentially impossible to find. This means we could store pure, native .json files eveywhere instead, to still bring the benefits of JSON (human editable, syntax checkable, interoperability with external configuration management tools, native + speedy encoding/decoding functions), without the confusing and controversial PHP wrapper.
The thread discussing this idea has some more commentary on this solution. It seems like this idea has a lot of support, especially from other security team members. But I've asked for a more formal ruling before we get too married to it; I don't want to end up in a situation where we start building a system and then discover it isn't going to fly.
The second idea was to make the actual writing of the files optional. In the original proposal, anytime you saved your configuration in the UI, the data would be saved both to the Active Store (the database by default) and to the .json.php files. These files are really only used for deployment, and the only time they get accessed is when new data is being saved or when they have been pushed to a new server (or in some rare cases when a developer edits them by hand). If we make the default that they never get written, then the security of having .json files is greatly mitigated. We would provide a mechanism so that non-technical users could have an easy export/import process (for instance chx has suggested providing a direct zip upload/download mechanism). We would also still offer people the opportunity to turn it on by default if they want. Doing this would trigger a hook_requirements() check to verify that .htaccess protection is working, and if not we could either block it or put up a big flashing red warning of death about how taking this action could kill babies or whatever. On top of all this, the location of the files would still be configurable, which would enable developers to locate them outside of the webroot (which is actually the reccomended scenario, just like with private files).
So I would love to see some more discussion of these topics. What won't work here? What are we missing? Thanks everyone.
