• (disco)

    Yay, first time INB4 unlist.

  • (disco)

    I recently had a conversation with a client that was in the process of turning their QA people into developers because they officially don't do QA anymore, they do test automation now, and OMGWTF?

    Wasn't Yahoo! by any chance?

  • (disco)

    Executable configuration files aren't a problem, provided you test them. But then any sort of config really ought to be tested anyway; just because it is not executable doesn't mean that getting it wrong won't cause trouble.

  • (disco)

    Doing Paula's job.

  • (disco)
    [image]

    :+1: Brillant!

    Can we expect another duplicate topic when she does get around to doing her job?

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    Brillant!

    Hey, she made @abarker work. That's something!

  • (disco)

    I prefer my emergency passwords secure as in "you know it's just that version string printed in the logs, right?" if defaults are used,...

  • (disco) in reply to HardwareGeek

    Depends on if/when @remy decides to poke this article again.

  • (disco)

    Poor bert, he's not admin.

  • (disco) in reply to Eldelshell
    Eldelshell:
    Poor bert, he's not admin.

    That's because he can't be trusted to write secure code.

  • (disco)

    Stuff like this is why I makewould really like to be empowered to make any assumptions about user-configurable settings dependent on a two-factor check for really being in a pre-beta test environment.

  • (disco) in reply to dkf
    dkf:
    Executable configuration files aren't a problem

    If it's executable, it's not configuration.

  • (disco) in reply to Sentenryu

    Counter-Strike key bindings file is technically speaking executable script. Is it not configuration then?

  • (disco) in reply to Gaska

    It's a script and should be treated as such.

  • (disco) in reply to Sentenryu

    Okay... and what's the implication here? Why can't we treat scripts like configuration files? What it means to treat something like configuration file?

  • (disco) in reply to Sentenryu

    You with the blakeyrat club, it's not user-facing if it doesn't have a GUI?

    There may be problems with executable/script-based config files, but this isn't one of them. Insane defaults is the problem here.

  • (disco) in reply to PleegWat
    PleegWat:
    Insane defaults is the problem here.

    I agree with that

    Gaska:
    Why can't we treat scripts like configuration files?

    For starters, you can sanitize values from a configuration file, but a script can execute any arbitrary code. If the config is in, for example, javascript, what's there to prevent the config file to set hooks into other parts of the software?

  • (disco) in reply to Sentenryu
    Sentenryu:
    For starters, you can sanitize values from a configuration file, but a script can execute any arbitrary code. If the config is in, for example, javascript, what's there to prevent the config file to set hooks into other parts of the software?

    That's the real problem with script-based configuration, and that's mainly cases like 'both the config and the main app are in js/php/whatever'. Counterstrike config script probably isn't a problem because although it may be a script it's probably got its own interpreter and is appropriately limited in what it can do.

  • (disco) in reply to PleegWat

    Is there any advantage on the format used by Counterstrike?

  • (disco) in reply to Sentenryu

    I haven't used counterstrike myself so I'll pass that back to @Gaska. Given how complicated game engines can be, more advanced configurations in scripts may make sense. The end user of course should get a GUI.

  • (disco) in reply to PleegWat
    PleegWat:
    Given how complicated game engines can be

    Have you seen XCOM's config? both XCOM: Enemy Unknow/Within and XCOM 2 have really crazy INI files for config. I guess if you really want, you can make anything with any config format.

  • (disco) in reply to Gaska
    Gaska:
    Why can't we treat scripts like configuration files?

    Manipulating them programmatically is fairly hard and the result is pretty fragile. Consuming them from different languages is hard as it likely requires a full VM for whatever it's written in. It's annoying.

    Sentenryu:
    If the config is in, for example, javascript, what's there to prevent the config file to set hooks into other parts of the software?

    Sandboxing, but it's usually not really that much of an issue (same privilege level, breaking your own toys etc).

  • (disco) in reply to CatPlusPlus
    CatPlusPlus:
    breaking your own toys

    It would be fine for a properly protected server app, but a local app is another story altoguether.

  • (disco) in reply to Sentenryu

    It's important for server apps that start with elevated privileges and need to read config before dropping them (to read TLS keys, bind ports or whatever). For everything else not so much.

    And even then the config is probably only writeable by superuser anyway.

  • (disco) in reply to Sentenryu
    Sentenryu:
    If the config is in, for example, javascript, what's there to prevent the config file to set hooks into other parts of the software?
    Sandboxing.
    Sentenryu:
    Is there any advantage on the format used by Counterstrike?
    Allows for more flexibility (multiple keys for same command; multiple commands for same key; repetition of command separated from command itself - e.g. you can make a key that toggles running/crouching instead of having to hold a key) without having to write it all down in code twice - once for triggers-to-actions mapping, second for keys-to-triggers.
    CatPlusPlus:
    Manipulating them programmatically is fairly hard and the result is pretty fragile. Consuming them from different languages is hard as it likely requires a full VM for whatever it's written in. It's annoying.
    Fair enough.
  • (disco) in reply to Gaska
    Gaska:
    without having to write it all down in code twice

    Didn't you have to write that logic for the script VM?

  • (disco) in reply to Sentenryu
    Sentenryu:
    Didn't you have to write that logic for the script VM?
    Yes, I did. But I would have anyway. Every modern game engine has one scripting language or another, because it's necessary for variety of things during the game. So if I have script interpreter in place already, why not reuse it?
  • (disco) in reply to Gaska

    That depends on how moddable you want your game to be.

  • (disco) in reply to Sentenryu

    In the age where people working on game engines are separate companies from people working on games...

  • (disco) in reply to Sentenryu
    Sentenryu:
    That depends on how moddable you want your game to be.

    you mightr as well make it modable... because PC gamers are gonna mod it if the game gets popular and if you make it easy for them to mod it (and put proper protections in place so they can't play modded version against vanilla online but can go modded v. modded online) then the modders will help make your game even more popular!

  • (disco)

    Firefox's master preference file used to be a script (run in a sandbox); now it's just parsed text that looks like script. (The serialisation code hasn't changed.)

  • (disco) in reply to HardwareGeek

    Paula doing her job would be the RWTF.

  • (disco) in reply to PJH
    I recently had a conversation with a client that was in the process of turning their QA people into developers because they officially don't do QA anymore, they do test automation now, and OMGWTF?

    Well... QA is for assuring quality, QC (Quality Control) is who should actually be performing tests. This is a confluence that has plagued the software industry for most of my 35+ year career (damn, its soon to be 40!).

    So when it comes to testing there are the questions of:

    1. Who defines the tests?
    2. Who implements the tests?
    3. Who executes the tests?

    [QA "merely" verifies that the various processes are being properly followed]

    To answer the above one needs to ask what type of tests...

    To hear more, come to South Florida Code Camp this Saturday!!!!!

  • (disco) in reply to Sentenryu

    Not at all uncommon for Tclers like dkf and myself to source s script for configuration purposes. We tend to call those configuration files regardless of what you might want to call them.

  • (disco) in reply to CatPlusPlus
    CatPlusPlus:
    Gaska:
    Why can't we treat scripts like configuration files?
    Manipulating them programmatically is fairly hard and the result is pretty fragile.
    Not if you have proper metaprogramming and AST support built-in to your language.
  • (disco) in reply to Mason_Wheeler

    That only helps in implementing the mechanical part of the manipulation. You still need knowledge about what the code does, and when the code can do arbitrary things, you are limited in being able to interpret it without executing it (and modify it in a way that doesn't break it, but implements the changes you want). So no, this is hard and error-prone, even if you're using a Lisp.

    Plus it makes no difference for interop from other languages.

  • (disco) in reply to RFoxmich
    RFoxmich:
    Tclers like dkf and myself

    I've never actually seen any code writen in Tcl, so I shall not disagree with you.

    accalia:
    you mightr as well make it modable

    agree for most cases, only exception being games like league of legends, that are meant to play online and would be a nightmare to manage mods.

  • (disco) in reply to CatPlusPlus
    CatPlusPlus:
    That only helps in implementing the mechanical part of the manipulation.
    Yeah, it "only" helps with the difficult part.
    CatPlusPlus:
    You still need knowledge about what the code does,
    *gasp!* To deal with configuration code, you need knowledge about what it does? Say it ain't so! What a terrible burden!
    CatPlusPlus:
    and when the code can do arbitrary things, you are limited in being able to interpret it without executing it (and modify it in a way that doesn't break it, but implements the changes you want).
    Not really. Just implement your config as a DSL and have two sets of macros: one that executes the config script and one that manipulates it. The first one (if not both) should include sanitization code, a whitelist that will reject arbitrary code. There is nothing particularly difficult about any of this if your AST-fu is at least moderately strong.
    CatPlusPlus:
    So no, this is hard and error-prone, even if you're using a Lisp.
    That's because Lisp is not particularly good at metaprogramming and AST manipulation. Sure, it was the first language to have those features, but the first of something is never particularly advanced, and Lisp has never really evolved beyond its primitive state.

    That's the problem with dynamic typing and everything being an S-expression: the AST itself holds no useful information that can be used to differentiate various types of expressions/statements. Lisp was created back when the science of parsing was in its infancy, so they essentially punted on the hard questions and did the simplest thing that could possibly work. But what that means is that the AST does not have all the built-in contextual data that modern languages give you, essentially for free, and you're forced to do a lot of the compiler's work for it.

    CatPlusPlus:
    Plus it makes no difference for interop from other languages.
    True enough. Depending on your point of view, though, you might call that "a feature, not a bug." :P
  • (disco) in reply to Sentenryu
    Sentenryu:
    I've never actually seen any code writen in Tcl, so I shall not disagree with you.

    It tends to not cause most people problems, so it rarely crops up here. :)

  • (disco) in reply to dkf
    dkf:
    It tends to not cause most people problems, so it rarely crops up here.
    Is it that it doesn't cause problems, or that so few people use it they just haven't been found yet? :trolleybus:
  • (disco) in reply to Mason_Wheeler
    Mason_Wheeler:
    Not really. Just implement your config as a DSL and have two sets of macros: one that executes the config script and one that manipulates it. The first one (if not both) should include sanitization code, a whitelist that will reject arbitrary code. There is nothing particularly difficult about any of this if your AST-fu is at least moderately strong.

    Or, you know, you could just use a normal text format and an out of the box serializer. Then just validate already parsed values... nah, that would be crazy.

  • (disco) in reply to Sentenryu
    Sentenryu:
    Or, you know, you could just use a normal text format and an out of the box serializer
    Like XML? :trolleybus:
  • (disco) in reply to RaceProUK
    RaceProUK:
    Like XML? :trolleybus:

    Nah, a csv should suffice :trolleybus:

  • (disco) in reply to Mason_Wheeler
    Mason_Wheeler:
    Yeah, it "only" helps with the difficult part.

    It's not the difficult part. It only makes parser interface different.

    Mason_Wheeler:
    Just implement your config as a DSL and have two sets of macros: one that executes the config script and one that manipulates it.

    Or, you know, use JSON (or s-exprs without eval or whatever other data interchange format) which is trivial to parse and manipulate, avoids all of these issues, doesn't require implementing any DSLs and has existing well-tested implementations. Especially that you're going out of your way to use a very limited subset of your language and therefore nullify any benefit code-as-config might have (no, using the same or similar syntax is not important at all, it's all about arbitrary logic).

  • (disco)
    Remy Porter:
    Configuration management is one of those problems that is deceptively simple but is actually really hard.
    ITYM "Configuration management is one of those problems that is deceptively hard."
  • (disco) in reply to RFoxmich
    RFoxmich:
    Not at all uncommon for Tclers like dkf and myself to source s script for configuration purposes. We tend to call those configuration files regardless of what you might want to call them.

    Pretty much all the EDA software I've used daily for at least the last 15 years or so uses Tcl as its scripting language, including configuration. Even your saved application state — what windows are open, what's in each window, etc. — is a Tcl script; you restore your session by File -> Run script... -> foo_debug.tcl. You can go, and I have gone, in and edit the save file to, say, add stuff to be debugged to your current session rather than closing everything and restoring some other session.

  • (disco) in reply to RaceProUK
    RaceProUK:
    dkf:
    It tends to not cause most people problems, so it rarely crops up here.
    Is it that it doesn't cause problems, or that so few people use it they just haven't been found yet? :trolleybus:

    The only problem it generally causes for me is that I use it so infrequently that I don't remember its syntax. However, since my most common use is to modify a machine-generated configuration script to remove stuff I don't need, it's not really a problem.

  • (disco) in reply to Sentenryu
    Sentenryu:
    agree for most cases, only exception being games like league of legends, that are meant to play online and would be a nightmare to manage mods.
    Valve solved this problem *ages* ago. Just look at CS:GO - you have official ranked matches using matchmaking, *and* moddable community servers where you can do what the fuck you want - all in a single game! And you don't even have to reload game to switch mods!
  • (disco) in reply to Gaska

    You mean the Source Engine mutators? those are awesome. thats an example of multiplayer mods at least partially well done.

  • (disco)

    execptions

    I didn't know @Remy was @Accalia...

Leave a comment on “Safely Configured”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article