Re: Using Lua for config files

[Todd Coram <todd@...>]

This is a long thread and apologies if this approach has been mentioned
before, but...

I'm a big fan of program-generated config files. That is, since
everybody/product has their favorite config file format (ugh, will we
ever stop re-inventing the config file?), I tend to avoid going down
that rabbit hole (or at least avoid it in my main application) by using
Lua syntax as the final generated form of config file. This is something
I've done before in Perl too.

By going with the native language as config I avoid writing or adopting
yet-another-config-file-reader into the main application.
By generating the config file (from a simpler config format or via
GUI/Webpage), I can ensure that it can be parsed and somewhat ensure
that it is safe.

I haven't allowed arbitrary code blocks or functions in a config file,
but with a generator you could probably run some sanity checks
(sandboxed?) on the code before you generate a "valid" config file. 

This does just push the config file issues (as verbosely documented in
this thread) "down the road" rather than solve them, but you can at
least move the problem outside of your main application/product. 

But, what if someone mucks with the generated config file?  Well, that
voids the warranty ;-)

/todd

On Fri, Dec 27, 2013, at 08:12 AM, Andrew Starks wrote:
> On Mon, Dec 23, 2013 at 6:49 PM, Robert Virding
> <robert.virding@erlang-solutions.com> wrote:
> > Being allowed to enter straight Lua, even if it looks good and is run in a sandbox, would give the non-Lua user way too many ways of getting into trouble.
> 
> This may not be the thread, or even the mailing list, for a prolonged
> discussion on this topic, although I think it may be.
> 
> The way that I can understand this perspective is to imagine a piece
> of software that has been extended by the developer, but did not have
> those extensions fully integrated into the software. [1] As a result,
> important configuration options are relegated to a configuration file
> and now it is not reasonable to expect that the average user will be
> able to avoid technical support on their way to success.
> 
> This is a product management problem: The wrong context is forced on
> the wrong persona. What would normally be fine in configuration must
> now be sanitized, because the configuration files are now also a stand
> in for a proper user interface.
> 
> Perhaps others have better examples of where this may apply?
> 
> Documentation, testing, aka "quality", are important everywhere.
> Assuming that nothing is being cheated, then I can't see any
> additional reasons to limit what someone could do in configuration,
> accepting applications where security plays an outsized role.
> 
> Also, covering for deficiencies in quality is a legitimate strategy. I
> just don't think it's a very good one for anything beyond what it
> takes to push a Z release.
> 
> -Andrew
> 
> [1] This has been true of our software, at times.
>