-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Adding tags (closes #9, #318) #362
Conversation
@@ -20,6 +20,7 @@ jobs: | |||
mv yml/OSBinaries yml/Binaries | |||
mv yml/OSLibraries yml/Libraries | |||
mv yml/OSScripts yml/Scripts | |||
rm -r yml/HonorableMentions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed we currently display Honorable Mentions on the website, even though the plan was to just keep them in the repo. Hence this extra command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any set of tags we have want to add by default?
Train of though was if its flag by default WDAC from here: #85
or maybe actors seen using, etc? Added a suggestion to improve the schema but otherwise this looks good to me.
YML-Schema.yml
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switching tags from a list of strings to key-value pairs could make our tags more useful and easier to work with. For example, instead of just listing tags like 'DLL' or 'EXE', we could add more context, like where a file is located:
Tags:
- Type: DLL
- Location: INetCache
here would be the proposed schema for this approach:
"Tags":
type: seq
sequence:
- type: map
mapping: {}
required: false
This would support:
Tags:
- DLL
- Custom Format
- EXE
as well as:
Tags:
- Location: INetCache
This could give us more flexibility and make it easier for anyone using the tags to get what they need without digging through a bunch of text. What do you think? Any concerns about making this switch?
Cheers!
I can see there being a case for key:value-style tags, although it does clutter things up. It's better to go with either strings or key:value pairs - but not both, as that will turn into chaos later on. As such, I have changed it to the latter. Because you could end up with multiple tags using the same key (e.g. Have also updated the website, see LOLBAS-Project/LOLBAS-Project.github.io#20 (comment) I'd also refrain from having 'default tags', as that would undermine the concept of tags: they should be distinct, allow entries to show unique capabilities, and thus add value. I have just included a first iteration of tags, we can add WDAC tags and others later of course. |
I agree lets not go with both! Thank you so much for updating the website and all the adjustments, phenomenal work @wietze! |
After approving, please also approve LOLBAS-Project/LOLBAS-Project.github.io#20
I'll merge - thanks!