Should we create separate repo for cook's ingredients & recipes?

[noraj]

Can you create a cook-recipe repository so people can share their cook.yml config?

[glitchedgitz]

I was also thinking to create diff repo for that, but I am not sure how people will use that.

If we take the example of nuclei templates, then people share diff templates by template purpose, and their names also attached as authors. So one can download all templates and use them when he/she needs acc to target.

In the cook's case file will be only cook.yaml.
But no doubt that if everyone shares something then the cook will be much better.

So here is my current plan.
Creating a repo where people can share the following things

• charset, wordlists, extension sets, and patterns
• their own recipes (how they are using cook)
• Using COOK with other tools
• Useful Resources to use with cook

And their name will appear above it, just like it appears in PATT
This way one can update his/her cook.yaml with whatever they want.

What do you think about this?

[noraj]

I was also thinking to create diff repo for that, but I am not sure how people will use that.

When you write diff you mean different repositories? Not a diff repository including diff from custom cook.yaml and the original one?

In the cook's case file will be only cook.yaml.

What about export COOK=mycustomcook.yaml? And what about an option to specify it like for docker-compose docker-compose -f docker-compose.dev.yaml?

And what about a directory where we can store multiple cook config files and then specify them by name. EG. /config with wordlists.yaml, custom-patterns.yaml etc. and instead of export COOK=/usr/share/cook/config/wordlists.yaml have cook -config wordlist.

By the way having to specify a env var or a command option each time is boring. Cook should be looking for cook.yaml at different locations, eg.:

• $XDG_CONFIG_HOME/cook/cook.yaml default ~/.config/cook/cook.yaml
• $XDG_CONFIG_DIRS/cook/cook.yaml default /etc/xdg/cook/cook.yaml
• /etc/cook/cook.yaml
• /usr/share/cook/cook.yaml

Maybe tryiong to comply with XDG Base Directory Specification (SO) like most unix apps.

And their name will appear above it, just like it appears in PATT

What do you mean? contributors name doesn't appear in PATT.

[glitchedgitz]

When you write diff you mean different repositories?

Yeah, I mean different repositories.

What about export COOK=mycustomcook.yaml

I don't think users will use multiple files for cook, the whole purpose is to accumulate every wordlist in the same place.

Cook should be looking for cook.yaml at different locations

The diff between other tools and COOK is that the user will modify cook.yaml may be on weekly basis, maybe for new wordlists, extensions, or something. And he doesn't want to lose cook.yaml as he updated it according to himself. But in other tools the config file once edit & forgot and user even don't mind losing it.

I will think about this point again after creating interactive mode for configuring cook.yaml.

What do you mean? contributors name doesn't appear in PATT.

I mean name appears over the tip, to represent the person who provided that tip. But still not sure if create separate repo is a good idea or not.

[noraj]

I don't think users will use multiple files for cook, the whole purpose is to accumulate every wordlist in the same place.

But people may prefer different charset or different name for shortcuts etc. so having the ability to use several config files separately is extremely interesting.

The diff between other tools and COOK is that the user will modify cook.yaml may be on weekly basis, maybe for new wordlists, extensions, or something. And he doesn't want to lose cook.yaml as he updated it according to himself. But in other tools the config file once edit & forgot and user even don't mind losing it.

Why would the user loose its config file? For example on archlinux pacman save the old config file as cook.yml.pacnew (see pacman/Pacnew and Pacsave) and there are merge tools to merge old and new config files. There are similar mechanism for other distros so no config file is overridden on package update.
Anyway even is such a mechanism only the default one would be overridden eg. /usr/share/cook/cook.yaml but the one customized by the user .eg ~/.config/cook/cook.yaml would be safe and untouched. cook can works like most unix utilities. Also there is an order for config loading eg. ~/.config/cook/cook.yaml first if not found /etc/xdg/cook/cook.yaml and if not found the default in /usr/share/cook/cook.yaml for example. For the example it is the way it works with Neovim.

I mean name appears over the tip, to represent the person who provided that tip.

Can you show me please? Because in don't see such a thing on PATT. I'm the 1st contributor and I never saw such a thing.

But still not sure if create separate repo is a good idea or not.

Yes something like https://github.com/projectdiscovery/nuclei-templates and being able to fetch them all in a config folder to be able to use them easily. But if one just want to grab a chunk of one config and add it in its config file he is free to do so too.

[glitchedgitz]

Lets see what others think about this, I already pin this discussion.

Update:
Regarding PATT

[glitchedgitz]

Why would the user loose its config file? For example on archlinux pacman save the old config file as cook.yml.pacnew (see pacman/Pacnew and Pacsave) and there are merge tools to merge old and new config files. There are similar mechanism for other distros so no config file is overridden on package update.
Anyway even is such a mechanism only the default one would be overridden eg. /usr/share/cook/cook.yaml but the one customized by the user .eg ~/.config/cook/cook.yaml would be safe and untouched. cook can works like most unix utilities. Also there is an order for config loading eg. ~/.config/cook/cook.yaml first if not found /etc/xdg/cook/cook.yaml and if not found the default in /usr/share/cook/cook.yaml for example. For the example it is the way it works with Neovim.

Hey @noraj, I rethink about this and will implement this approach to follow community standards.
And this will work like this

1. On first run cook will create a file cook.yaml in APPNAME of OS.
2. If user sets env variable COOK then COOK will use that location with the filename that he wants.
3. New option -config-path will be there to specify config file's path.

This way I think user will able to do more customization and also will able to use custom cook.yaml
Thanks for your contribution :)

[noraj]

Cool, good news.

[glitchedgitz]

Just released version 1.6 with updated config behaviour.
And few more small updates.