CONTRIBUTING.md

Contributing

If you have any ideas for things we should include, please use ONE of the following methods to submit them:

• Create a pull request
• Create an issue in the project (with links, and we'll parse and incorporate them)

Significant effort SHOULD be made to give attribution for these lists whenever possible, and if you are a list owner or know who the original author/curator is, please let us know so we can give proper credit.

Folder naming scheme

Folders should be named with the train case scheme, for example File-System.

Conventional Commits

All commits related to contributions to seclists are encouraged to use the Conventional-Commits v1.0.0 syntax

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

For example:

feat(wordlist): Added "raft" wordlists by Google

Below is a flowchart which should assist you in selecting the best conventional-commits syntax for the commit messages of the contributions you wish to make.

flowchart TD
	start(You made a commit) --> f1
	f1{Does it affect a wordlist?}
	f1 --> |YES| q1A{Did you upload a\ncompletely new\nwordlist?}

	q1A --> |YES| q1A_opt1(Use the syntax:\nfeat(wordlist): Added "WORDLIST_NAME_HERE" by AUTHOR_NAME_HERE)
	q1A --> |NO| q1B{Did you add\ncompletely new\ncontent to an existing\nwordlist?}
	
	q1B --> |YES| q1B_opt1(Use the syntax:\nfeat(wordlist): Added _____ to "WORDLIST_NAME_HERE")
	q1B --> |NO| q1C{Did you fix an error/\nmistake/oversight in an\nexisting wordlist?}
	
	q1C --> |YES| q1C_end(Use the syntax:fix(wordlist): Fixed _____ in "WORDLIST_NAME_HERE"\nfix(wordlist): Removed _____ from "WORDLIST_NAME_HERE")
	q1C --> |NO| q1D{Did you perform a big operation\nwich affects all wordlists \nin a minor way?\nFor example: \n- Moving all wordlists from one \ndirectory to a new one\n- Changing the line-endings of\nall wordlists}

	q1D --> |YES| q1D_end(Use the syntax:\nchore(wordlist): _____\n\nFor example:\n\nchore(wordlist): Moved all file-extension wordlists to /Fuzzing/File-Extensions/)
	q1D --> |NO| support1(Ask a project-maintainer which commit type you should use)

	f1 --> |NO| f2{Does if affect a\nREADME file?}

	f2 --> |YES| q2A{Did you create a new\nREADME file?}

	q2A --> |YES| q2A_end(Use the syntax:\nfeat(docs): Created documentation for ______)
	q2A --> |NO| q2B{Did you fix a typo?\nDid you improve the\nphrasing of a README?}

	q2B --> |YES| q2B_end(Use the syntax:\nchore(docs): Fixed typo for _____ docs\nchore(docs): Improved phrasing in ____ docs)
	q2B --> |NO| q2C{Did you add new \ncontent to an existing\nREADME?}

	q2C --> |YES| q2C_end(Use the syntax:\nfeat(docs): Added documentation for ______)
	q2C --> |NO| q2D{Did you fix incorrect\ninformation in a \nREADME?}

	q2D --> |YES| q2D_end(Use the syntax:\nfix(docs): Corrected _____\n\nFor example:\nfix(docs): Corrected author name for the raft.txt wordlist)
	q2D --> |NO| support2(Ask a project-maintainer which commit type you should use)


	f2 --> |NO| q3A{Does it affect the CICD\npipelines? (github actions)}

	q3A --> |YES| q3B{Did you create a\ncompletely new\nautomation?}
	q3A --> |NO| support3(Ask a project-maintainer which commit type you should use)

	q3B --> |YES| q3B_end(Use the syntax:\nfeat(cicd): Created ______)
	q3B --> |NO| q3C{Did you fix an error or \nfix a vulnerability in an \nexisting automation?}

	q3C --> |YES| q3C_end(Use the syntax:\nfix(cicd): Fixed ______ in "AUTOMATION_NAME_HERE"\n\nFor example:\nfix(cicd): Fixed permissions error in "trickest-wordlist auto-updater")
	q3C --> |NO| q3D{Did you add \na new feature \nto an existing \nautomation?}

	q3D --> |YES| q3D_end(Use the syntax:\nfeat(cicd): Added _____ to "AUTOMATION_NAME_HERE"\n\nFor example:\nfeat(cicd): Added a file size checker to "dangerous_wordlist_checker.sh")
	q3D --> |NO| q3E{Did you:\n- Fix a typo\n- Move a file\n- Add a code coment}

	q3E --> |YES| q3E_end(Use the syntax:\nchore(cicd): Fixed typo in "AUTOMATION_NAME_HERE"\nchore(cicd): Moved ______\nchode(cicd): Added code comment to "AUTOMATION_NAME_HERE")
	q3E --> |NO| support4(Ask a project-maintainer which commit type you should use)

Loading

READMEs

If you are uploading a brand-new wordlist into SecLists, an entry must be added to the containing folder's README.md. If the folder does not already have a README.md file, you may create one.

These are the general guidelines for writing READMEs in SecLists:

1. Use the filename of the wordlist as the title. This will help other people more easily locate which entries in the README correspond to the wordlist you've uploaded.
2. If the wordlist is very purpose-specific, consider adding a Use for: text, right below the entry title. For example:

vulnerability-scan_j2ee-websites_WEB-INF.txt

Use for: Discovering sensitive J2EE files, allowing for exploitation of an LFI.

3. Always include a link to the source of the wordlist: Source: example.com/the-great-wordlist
4. If the author shared the wordlist through a blogpost, include a link to it: Reference: example.com/how-i-hacked-xyz-with-a-wordlist. This will help SecLists users more easily understand the practical applications of the wordlists you've uploaded.

You can use the README in the folder Web-Content as a general reference.