Encrypted config file and section inheritance

edited September 2011 in Help request
Hi iarwain,
I found an issue regarding config section inheritance in encrypted config files and I'd like to know whether it is the intended way things should work.

I'm loading some config files in code like this
orxConfig_Load( "config1.ini" );
orxConfig_Load( "config2.ini" );

and the config files look like the following:

Texture = image.png

[[email protected]]
TextureCorner = (10,10,0)
TextureSize = (32,32,0)

If the config2.ini file is not encrypted, it works ok. But if it is encrypted, the inheritance is ignored.

In encrypted config files the includes are also ignored.

I think config files don't like the "@" character.

Is that correct?



  • edited September 2011
    That would definitely be a bug and it sounds like you've got a lead with the '@' character. I'll check it tonight. Encrypted config files have never been tested much and I made a few changes and added new features to config since then, so I'm not very surprised.

    I'll let you know what I find, thanks for reporting it.
  • edited September 2011
    I couldn't find any problem with the encryption, however I think I know what happened to you.

    My guess is that you used orxCrypt to encrypt your config file, isn't it?
    If so, which version are you using? I'd recommend compiling your own version (you'll likely to need to compile a static non-embedded version of orx first and place it in the appropriate /lib folder of the tool). If I remember I fixed a few things in config saving not so long ago.

    Now, for file inclusion, unfortunately orx doesn't keep track of those when loading config files. As orxCrypt calls orx to simply load all the target config files and save a single new one, it'll lose track of file inclusions as well. It was meant as a tool to produce a final unique config file that would contain all the configuration you need, instead of a bunch of small files. Encryption is kind of an added bonus. =)

    As for the parenting, if you encrypt only the file that has the [email protected] section but doesn't contain a Parent section, it won't be able to find the parent and thus won't be able to output the parenting. To fix this you can simply include config1.ini from config2.ini and that should fix the problem. However if you have config entries that are unique to config1.ini and that have changed since the last time you encrypted config2.ini, they'll get overridden when loading config2.ini. Easy fix: either you re-encrypt a new version of config2.ini or you load config2.ini before config1.ini. But in both cases, loading config1.ini becomes worthless as all the info will also be in config2.ini. ^^

    I suspect that's what is happening for you. So now there are two options for you now, either those limitations are ok and don't prevent you from doing what you want or you'll have to encrypt the file manually yourself. That is till I write a new 'raw' mode in the orxCrypt tool.

    Luckily this is very easy to do, you simply have to output the OECF as the 4 characters of your file and then you xor the content of your config file with your encryption key, character by character. This is an ugly external dependency though so I'll probably add a function that will do all this for you this week end directly in orx's config module.
  • edited September 2011
    Yes, I'm using orxCrypt. I will try some of your suggestions.

    Thank you.
  • edited September 2011
    No problem. I should probably emphasize that orxCrypt is currently more of a merger tool. It'll change this week end as I'll make the merging optional and not by default.
  • edited September 2011
    Ok, the code's in.

    You now have access to orxConfig_CopyFile() which will do a raw copy of a file, including comments and inclusions with an optional encryption key.
    If the source file is encrypted, the current key will be used to decrypt it and the key passed in parameter will only be used to encrypt the destination file.
    If no key is passed as parameter, the destination file will not be encrypted, even if the source file is.

    You can't copy a file over itself.

    I also updated orxCrypt to use that scheme by default and you can still do the merging which was the old default behavior by specifying -m on the command line. If not merging, only one file can be provided as input. Only the windows binaries have been updated on the server.

    Let me know if you have any issues with it, I tested everything quickly, it seemed ok but I might have missed special cases.
Sign In or Register to comment.