Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the .ctf/config structure #109

Open
ColdHeat opened this issue Feb 21, 2023 · 4 comments
Open

Improve the .ctf/config structure #109

ColdHeat opened this issue Feb 21, 2023 · 4 comments

Comments

@ColdHeat
Copy link
Member

I do not like the structure of the current ctf config. It's too basic. For example the yaml_path issue is difficult to solve because challenge keys are simple key value stores. Instead of trying to shoehorn things on top of the kv, we should break it up into more complex sections.

I think if it's possible something like this would be superior:

[challenges]
[test/test]
location = git@git
path = challenge.yml

We would need:

  1. A way to detect old .ctf/configs and change behvior based on that
  2. Extract the parsing behavior for both type of configs into seperate functions.
@ColdHeat
Copy link
Member Author

I think this involves a conversion from configparser to toml.

[challenge."asdf/asdf"]
name = "Nail"

[http.cookies]
asdf = "asdf"

Ideas like this seem to work with toml which allows us to keep existing functionality while getting more organization.

@MilyMilo
Copy link
Member

MilyMilo commented Nov 8, 2023

Toml has been vendored inside the standard library starting with 3.11 so I feel like it's the right direction. Also it's a superior format to ini which would make for more explicit configs.

@noah-de
Copy link

noah-de commented Dec 4, 2023

I am interested in the discussion of a new .ctf/config structure.

Would new structure keep the version at the bottom of the file as is in the current spec? It's currently listed under 'optional', but if included, could provide an indicator as to how a file should be parsed.

@ColdHeat
Copy link
Member Author

@noah-de I think version should be considered a required field. Feel free to drop any thoughts here. Sorry for the delay I feel like I never got an email for your message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants