Rename master to main in various docs (#1071)

* checkers: README: Replace branch master links with main branch

Signed-off-by: John Andersen <[email protected]>

* doc: CSV2CVE: Replace branch master links with main branch

Signed-off-by: John Andersen <[email protected]>

* doc: MANUAL: Replace branch master links with main branch

Signed-off-by: John Andersen <[email protected]>

* doc: CONTRIBUTORS: Replace branch master links with main branch

Signed-off-by: John Andersen <[email protected]>

* test: README: Replace branch master links with main branch

Signed-off-by: John Andersen <[email protected]>

Author: John Andersen

cve_bin_tool/checkers/README.md

@@ -113,7 +113,7 @@ That helps other contributors know that that particular checker is going to be
 hard to do.  Once you've done that, you can abandon the checker and find something
 easier to work on, or you can try to think outside the box to find another way
 to detect the version.  One example is how we did it for the 
-[sqlite3 get_version_map() fuction](https://github.com/intel/cve-bin-tool/blob/master/cve_bin_tool/checkers/sqlite.py#L104)
+[sqlite3 get_version_map() fuction](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/sqlite.py#L104)
 where the checker uses version hashes from the website that are *also* stored
 as strings in the binary.
 
@@ -234,7 +234,7 @@ That regex might look like this: `3\?Xiph.Org libVorbis ([0-9]+\.[0-9]+\.[0-9]+)
 
 > If you can't get a signature match using just regex you may end up needing to
 > overwrite the
-> [`get_version()`](https://github.com/intel/cve-bin-tool/blob/master/cve_bin_tool/checkers/__init__.py#L120-L132)
+> [`get_version()`](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/__init__.py#L120-L132)
 > method for the checker, but that should be a last resort if you can't find a
 > regex that works for `VERSION_PATTERNS`.
 >
@@ -284,7 +284,7 @@ There are two types of tests you want to add to prove that your checker works as
 2. Tests to show that the checker correctly detects real binaries.
 
 You can read about how to add these in 
-[tests/README.md](https://github.com/intel/cve-bin-tool/blob/master/test/README.md)
+[tests/README.md](https://github.com/intel/cve-bin-tool/blob/main/test/README.md)
 
 ## Running tests
 

doc/CONTRIBUTORS.md

@@ -92,7 +92,7 @@ pip install -r requirements.txt
 
 The CVE Binary Tool has a set of tests that can be run using `pytest` command.  Usually all the short tests should pass, although sometimes internet connectivity issues will cause problems.
 
-[There is a README file in the tests directory](https://github.com/intel/cve-bin-tool/blob/master/test/README.md) which contains more info about how to run just specific tests, or how to run the longer tests which involve downloading full software packages to test the tool. The long tests sometimes fail due to package name changes, which may not be your fault unless you modified one of them.
+[There is a README file in the tests directory](https://github.com/intel/cve-bin-tool/blob/main/test/README.md) which contains more info about how to run just specific tests, or how to run the longer tests which involve downloading full software packages to test the tool. The long tests sometimes fail due to package name changes, which may not be your fault unless you modified one of them.
 
 ## Running isort and black
 
@@ -146,10 +146,10 @@ pre-commit install
 
 Git allows you to have "branches" with variant versions of the code.  You can see what's available using `git branch` and switch to one using `git checkout branch_name`.
 
-To make your life easier, we recommend that the `master` branch always be kept in sync with the repo at `https://github.com/intel/cve-bin-tool`, as in you never check in any code to that branch.  That way, you can use that "clean" master branch as a basis for each new branch you start as follows:
+To make your life easier, we recommend that the `main` branch always be kept in sync with the repo at `https://github.com/intel/cve-bin-tool`, as in you never check in any code to that branch.  That way, you can use that "clean" main branch as a basis for each new branch you start as follows:
 
 ```bash
-git checkout master
+git checkout main
 git pull
 git checkout -b my_new_branch
 ```
@@ -245,10 +245,10 @@ Many beginners get stuck trying to figure out how to start.  You're not alone!
 
 Here's three things we recommend:
 1. Try something marked as a "[good first issue](https://github.com/intel/cve-bin-tool/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)" We try to mark issues that might be easier for beginners.
-2. [Add tests to an existing checker](https://github.com/intel/cve-bin-tool/blob/master/test/README.md). This will give you some practice with the test suite.
-3. [Add a new checker](https://github.com/intel/cve-bin-tool/blob/master/cve_bin_tool/checkers/README.md)  This will give you some deeper understanding of how the tool works and what a signature looks like.  We have a few new checker requests listed in the "good first issue" list, or any linux library that has known CVEs (preferably recent ones) is probably interesting enough.
+2. [Add tests to an existing checker](https://github.com/intel/cve-bin-tool/blob/main/test/README.md). This will give you some practice with the test suite.
+3. [Add a new checker](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/README.md)  This will give you some deeper understanding of how the tool works and what a signature looks like.  We have a few new checker requests listed in the "good first issue" list, or any linux library that has known CVEs (preferably recent ones) is probably interesting enough.
 4. Suggest fixes for documentaiton.  If you try some instruction and it doesn't work, or you notice a typo, those are always easy first commits!  One place we're a bit weak is instructions for Windows users.
 
 If you get stuck or find something that you think should work but doesn't, ask for help in an issue or stop by [the cve-bin-tool gitter](https://gitter.im/cve-bin-tool/community) to ask questions.
 
-Note that our "good first issue" bugs are in high demand during the February-April due to the start of Google Summer of Code.  It's totally fine to comment on a bug and say you're interested in working on it, but if you don't actually have any pull request with a tentative fix up within a week or so, someone else may pick it up and finish it. If you want to spend more time thinking, the new checkers (especially ones no one has asked for) might be a good place for a relaxed first commit.
+Note that our "good first issue" bugs are in high demand during the February-April due to the start of Google Summer of Code.  It's totally fine to comment on a bug and say you're interested in working on it, but if you don't actually have any pull request with a tentative fix up within a week or so, someone else may pick it up and finish it. If you want to spend more time thinking, the new checkers (especially ones no one has asked for) might be a good place for a relaxed first commit.

doc/CSV2CVE.md

@@ -4,7 +4,7 @@ This tool takes a comma-delimited file (.csv) with the format `vendor,product,ve
 
 This is meant as a helper tool for folk who know the list of product being used in their software, so that you don't have to rely on binary detection heuristics.  There exist other tools that do this, but it seemed potentially useful to provide both in the same suite of tools, and it also saves users from having to download two copies of the same data.
 
-At the moment, you must use the exact vendor and product strings used in the National Vulnerability Database.  You can read more on how to find the correct string in [the checker documentation](https://github.com/intel/cve-bin-tool/blob/master/cve_bin_tool/checkers/README.md).  Future work could extend this to use the mappings already in the CVE Binary Tool or to use other mappings such as common linux package names for a given distribution.  (Contributions welcome!)
+At the moment, you must use the exact vendor and product strings used in the National Vulnerability Database.  You can read more on how to find the correct string in [the checker documentation](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/README.md).  Future work could extend this to use the mappings already in the CVE Binary Tool or to use other mappings such as common linux package names for a given distribution.  (Contributions welcome!)
 
 > Note: For backward compatibility, we still support `csv2cve` command for producing CVEs from csv but we recommend using new `--input-file` command instead.
 
@@ -76,4 +76,4 @@ $ python -m cve_bin_tool.csv2cve test.csv
 │ libjpeg-turbo  │ libjpeg-turbo  │ 2.0.1   │ CVE-2018-19664    │ MEDIUM    │
 │ libjpeg-turbo  │ libjpeg-turbo  │ 2.0.1   │ CVE-2018-20330    │ HIGH      │
 └────────────────┴────────────────┴─────────┴───────────────────┴───────────┘
-```
+```

doc/MANUAL.md

@@ -106,9 +106,9 @@ As such, it cannot tell if someone has backported fixes to an otherwise
 vulnerable version, it merely provides a mapping between strings, versions, and
 known CVEs.
 
-A [list of currently available checkers](https://github.com/intel/cve-bin-tool/tree/master/cve_bin_tool/checkers)
+A [list of currently available checkers](https://github.com/intel/cve-bin-tool/tree/main/cve_bin_tool/checkers)
 can be found in the checkers directory or using `cve-bin-tool --help` command, as can the
-[instructions on how to add a new checker](https://github.com/intel/cve-bin-tool/blob/master/cve_bin_tool/checkers/README.md).
+[instructions on how to add a new checker](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/README.md).
 Support for new checkers can be requested via
 [GitHub issues](https://github.com/intel/cve-bin-tool/issues).
 (Please note, you will need to be logged in to add a new issue.)
@@ -181,7 +181,7 @@ supported, as is usage within cygwin on windows.
 This tool does not scan for all possible known public vulnerabilities, it only
 scans for specific commonly vulnerable open source components.   A complete
 list of currently supported library checkers can be found in [the checkers
-directory](https://github.com/intel/cve-bin-tool/tree/master/cve_bin_tool/checkers).
+directory](https://github.com/intel/cve-bin-tool/tree/main/cve_bin_tool/checkers).
 
 As the name implies, this tool is intended for use with binaries. If you have
 access to a known list of product names and versions, we do have an option `--input-file`
@@ -265,7 +265,7 @@ For Example if input_file contains following data:
 | sun           | sunos         | 5.4      | 4         |                                       |                |          |
 | ssh           | ssh2          | 2.0      | Mitigated |                                       |                |          |
 
-You can test it using our [test input file](https://github.com/intel/cve-bin-tool/blob/master/test/json/test_triage.json) with following command:
+You can test it using our [test input file](https://github.com/intel/cve-bin-tool/blob/main/test/json/test_triage.json) with following command:
 
 ```console
 cve-bin-tool -i="test/json/test_triage.json"
@@ -326,7 +326,7 @@ We currently have number of command line options and we understand that it won't
 1. TOML which is popular amongst Python developer and very similar to INI file. If you are not familiar with TOML checkout official [TOML documentation](https://toml.io/en/)
 2. YAML which is popular amongst devops community and since many of our users are devops. We also support YAML as config file format. You can find out more about YAML at [yaml.org](https://yaml.org/)
 
-You can see our sample TOML config file [here](https://github.com/intel/cve-bin-tool/blob/master/test/config/cve_bin_tool_config.toml) and sample YAML config file [here](https://github.com/intel/cve-bin-tool/blob/master/test/config/cve_bin_tool_config.yaml).
+You can see our sample TOML config file [here](https://github.com/intel/cve-bin-tool/blob/main/test/config/cve_bin_tool_config.toml) and sample YAML config file [here](https://github.com/intel/cve-bin-tool/blob/main/test/config/cve_bin_tool_config.yaml).
 
 > You have to specify either a directory to scan and/or an input file containing vendor, product and version fields either in JSON or CSV format.
 

test/README.md

@@ -1,5 +1,5 @@
 # cve-bin-tool tests
-You can see all existing tests in [`test/`](https://github.com/intel/cve-bin-tool/tree/master/test)
+You can see all existing tests in [`test/`](https://github.com/intel/cve-bin-tool/tree/main/test)
 
 ## Running all tests
 
@@ -64,8 +64,8 @@ deactivate
 ```
 
 ## Adding new tests: CVE mapping tests
-* You can see the code for scanner tests in ['test/test_scanner.py'](https://github.com/intel/cve-bin-tool/blob/master/test/test_scanner.py)
-* You can see checker wise test data in ['test/test_data'](https://github.com/intel/cve-bin-tool/blob/master/test/test_data)
+* You can see the code for scanner tests in ['test/test_scanner.py'](https://github.com/intel/cve-bin-tool/blob/main/test/test_scanner.py)
+* You can see checker wise test data in ['test/test_data'](https://github.com/intel/cve-bin-tool/blob/main/test/test_data)
 * If you just want to add a new mapping test for a checker, add a dictionary of *product*, *version* and *version_strings* in the mapping_test_data list . Here, *version_strings* are the list of strings that contain version signature or strings that commonly can be found in the module. For example: this is how the current mapping_test_data for gnutls look like. You should add the details of the new test case data at the end of `mapping_test_data` list:
 ```python
 mapping_test_data = [