fix: dci lint errors hyperledger-cacti#514

Also adds a .dcilintignore file to specify which files are
not possible to change without breaking third party dependencies.

TODO: If and when these dependencies get swapped out or they
release new versions with inclusive language, we'll need to
update them accordingly and the ignore file as well.

Fixes hyperledger-cacti#514

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>

.dcilintignore

@@ -0,0 +1,4 @@
+# TSLint configuration parameter
+packages/cactus-cockpit/tslint.json
+# Besu CLI argument
+tools/docker/besu-all-in-one/supervisord.conf

CONTRIBUTING.md

@@ -57,13 +57,13 @@ Quoting the most relevant parts below (and thanks to the Rust maintainers for th
 
 > Pull requests are the primary mechanism we use to change Rust. GitHub itself has some great documentation on using the Pull Request feature. We use the "fork and pull" model described here, where contributors push changes to their personal fork and create pull requests to bring those changes into the source repository.
 >
-> Please make pull requests against the master branch.
+> Please make pull requests against the main branch.
 >
-> Rust follows a no merge policy, meaning, when you encounter merge conflicts you are expected to always rebase instead of merge. E.g. always use rebase when bringing the latest changes from the master branch to your feature branch. Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages.
+> Rust follows a no merge policy, meaning, when you encounter merge conflicts you are expected to always rebase instead of merge. E.g. always use rebase when bringing the latest changes from the main branch to your feature branch. Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages.
 >
 > GitHub allows closing issues using keywords. This feature should be used to keep the issue tracker tidy.
 
-Source: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests
+Source: https://github.com/rust-lang/rust/blob/53702a67e2ae8a404169a0329f6a38d73bf7494d/CONTRIBUTING.md#pull-requests
 
 Further reading:
 - https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-collaborative-development-models
@@ -97,13 +97,13 @@ Further reading:
 7. Commit your changes
     1. Make sure your commit message follows the formatting requirements (details above) and here: [Conventional Commits syntax](https://www.conventionalcommits.org/en/v1.0.0-beta.4/#specification); this aids in release notes generation which we intend to automate
     2. Be aware that we are using git commit hooks for the automation of certain mundane tasks such as applying the required code style and formatting so your code will be wrapped at 80 characters each line automatically. If you wish to see how your changes will be altered by the formatter you can run the `npm run prettier` command from a terminal or install an IDE extension for the `Prettier` tool that can do the same (VSCode has one that is known to work).
-8. Ensure your branch is rebased onto the `upstream` master branch where `upstream` is fancy git talk for the main Cactus repo on Github (the one you created your fork from).
+8. Ensure your branch is rebased onto the `upstream` main branch where `upstream` is fancy git talk for the main Cactus repo on Github (the one you created your fork from).
    1. If you are having trouble, there are many great resources out there (so we will not write another here).
       1. If you are having trouble locating a suitable guide specifically on the mechanics of rebasing, we can recommend [this one](https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history). Thanks to Rafael for the link!
    2. If merge conflicts arise, you must fix these at rebase time since omitting this step does not magically make the conflicts go away, just pushes it over the fence to the maintainer who will attempt to merge your pull request at a later point in time.
    3. If the above happens, at that point said maintainer will most likely ask you (if not already) to perform the rebase anyway since as the author of a change you are best positioned to resolve any conflicts on the code level. Occassionally maintainers may do the merge/conflict resolution themselves, but do not count on this nor try to make a habit out of relying on the potential kindness.
    4. After successful rebasing, take another look at your commit(s). Ideally there should be just one in each pull request, but also on the other hand each commit should be as small, simple and self contained as possible, so there can be cases where it makes sense to submit a PR with multiple commits if for example you also had to change something in the test tooling while implementing a feature (in which case there could be a commit for the feature itself and another for the necessary changes to the test tooling package). What we respectfully ask though is that you try to avoid these situations and submit most of your PRs with a single, self contained commit that does not touch multiple things. This significantly reduces the cognitive load required to review the changes which in turn makes everyone happier: the maintainers will have an easier job reviewing, which means they'll be doing it faster which will (probably) cause you joy in turn.
-9.  Push your changes to your master (or whatever you named your feature branch, that is entirely up to you at the end of the day)
+9.  Push your changes to your main (or whatever you named your feature branch, that is entirely up to you at the end of the day)
 10. Initiate a pull request from your fork to the base repository
    5. Remember: Opening a pull request is like saying "Hey maintainers, I have this change finalized and ready for you to spend time on reviewing it." The word `finalized` here is understood to imply that you are not planning on doing any more changes on the branch apart from when being asked to by the reviewers.
    6. It is perfectly acceptable to open a pull request and mark it as `draft` (a GitHub feature) which then signals to the maintainers that if they have time, they are welcome to look at the change, but it may or may not be in its final form yet so you are not responsible for potential loss of time on their end if the review has to be performed multiple times on account of changes. Once you promote your draft PR to a real one, the comments from the point above apply however.
@@ -118,7 +118,7 @@ Further reading:
 Ensure all the following conditions are met (on top of you agreeing with the change itself)
 
 1. All automated checks that are not explicitly called out here are also passing/green.
-2. Branch is rebased onto master and there are no dangling/duplicate commits.
+2. Branch is rebased onto main and there are no dangling/duplicate commits.
 3. Commits appear simple and self contained. Simple is always relative to the mangitude of the change itself of course. A 1k line change can still be simple if all it does is rename some commonly used variable in each place its being used.
 4. If the contributors are having trouble with git basic functionality such as rebasing / force pushing, DCO, do your best to help them out, when in doubt feel free to reach out to Peter (who is the one insisting an all these git rules so he deserves to be the primary contact for all git related issues).
    1. Remember that we want to foster a welcoming community so if someone is new to git try to be extra patient with them on this front.
@@ -142,24 +142,24 @@ To protect the Hyperledger Cactus source code, GitHub pull requests are accepted
    # Verify the new remote named 'upstream'
    git remote -v
 
-   # Checkout your master branch and rebase to upstream.
-   # Run those commands whenever you want to synchronize with master branch
+   # Checkout your main branch and rebase to upstream.
+   # Run those commands whenever you want to synchronize with main branch
    git fetch upstream
-   git checkout master
-   git rebase upstream/master
+   git checkout main
+   git rebase upstream/main
    ```
 3. Create your branch.
    ```
-   # Checkout the master branch - you want your new branch to come from master
-   git checkout master
+   # Checkout the main branch - you want your new branch to come from main
+   git checkout main
 
    # Create a new branch named `<newfeature>` (give simple informative name)
    git branch <newfeature>
    ```
 4. Checkout your branch and add/modify files.
    ```
    git checkout <newfeature>
-   git rebase master
+   git rebase main
    # Happy coding !
    ```
 5. Commit changes to your branch.

GOVERNANCE.md

@@ -12,7 +12,7 @@ Maintainers may be removed by explicit resignation, for prolonged inactivity (3
 
 **Releases**
 
-A majority of the maintainers may decide to create a release of Cactus.  Any broader rules of Hyperledger pertaining to releases must be followed.  Once the project is mature, there will be a stable LTS (long term support) release branch, as well as the master branch for upcoming new features.
+A majority of the maintainers may decide to create a release of Cactus.  Any broader rules of Hyperledger pertaining to releases must be followed.  Once the project is mature, there will be a stable LTS (long term support) release branch, as well as the main branch for upcoming new features.
 
 **Making Feature/Enhancement Proposals**
 
@@ -25,7 +25,7 @@ Significant changes can be marked as such via the predefined label with the same
 To easily access the list of significant changes, navigate to the label:
 https://github.com/hyperledger/cactus/labels/Significant_Change
 
-We also recommend reading our CONTRIBUTING.md file (https://github.com/hyperledger/cactus/blob/master/CONTRIBUTING.md) for more information about contributing.
+We also recommend reading our CONTRIBUTING.md file (https://github.com/hyperledger/cactus/blob/main/CONTRIBUTING.md) for more information about contributing.
 
 **Approving Pull Requests**
 

codeql-analysis.yml

@@ -2,10 +2,10 @@ name: "CodeQL"
 
 on:
   push:
-    branches: [master]
+    branches: [main]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [master]
+    branches: [main]
   schedule:
     - cron: '0 11 * * 1'
 
@@ -42,7 +42,7 @@ jobs:
       with:
         languages: ${{ matrix.language }}
         # If you wish to specify custom queries, you can do so here or in a config file.
-        # By default, queries listed here will override any specified in a config file. 
+        # By default, queries listed here will override any specified in a config file.
         # Prefix the list here with "+" to use these queries and those in the config file.
         # queries: ./path/to/local/query, your-org/your-repo/queries@main
 

packages/cactus-api-client/src/main/typescript/api-client.ts

@@ -24,7 +24,7 @@ import { Configuration, BaseAPI } from "@hyperledger/cactus-core-api";
  * itself ends up being the act of routing).
  *
  * @see https://github.com/OpenAPITools/openapi-generator/blob/v5.0.0-beta2/modules/openapi-generator/src/main/resources/typescript-axios/apiInner.mustache#L337
- * @see https://github.com/OpenAPITools/openapi-generator/blob/master/docs/generators/typescript-axios.md
+ * @see https://github.com/OpenAPITools/openapi-generator/blob/v5.0.0/docs/generators/typescript-axios.md
  */
 export class ApiClient extends BaseAPI {
   /**

packages/cactus-cockpit/e2e/protractor.conf.js

@@ -1,5 +1,5 @@
 // Protractor configuration file, see link for more information
-// https://github.com/angular/protractor/blob/master/lib/config.ts
+// https://github.com/angular/protractor/blob/release-6.0/lib/config.ts
 
 const { SpecReporter } = require("jasmine-spec-reporter");
 

packages/ledger-plugin/fabric/validator/unit-test/fabric-docker/README.md

@@ -11,9 +11,9 @@
 
 ## a) clone the directories
 	curl -sSL https://bit.ly/2ysbOFE | bash -s -- 1.4.0 1.4.0
-Then, `fabric-samples` directory is made in the current directory, including `basic-network`, `bin`, `chaincode/fabcar`, and `fabcar`. 
+Then, `fabric-samples` directory is made in the current directory, including `basic-network`, `bin`, `chaincode/fabcar`, and `fabcar`.
 
-- c.f.: https://hyperledger-fabric.readthedocs.io/en/master/install.html#install-samples-binaries-and-docker-images
+- c.f.: https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html
 - If you are behind an proxy environment, use the command that `curl -x http://yourProxyURL:yourProxyPortNumber` instead of `curl`
 
 ## b) Initialization

tools/docker/fabric14-fabcar-testnet/README.md

@@ -11,9 +11,9 @@
 
 ## a) clone the directories
 	curl -sSL https://bit.ly/2ysbOFE | bash -s -- 1.4.0 1.4.0
-Then, `fabric-samples` directory is made in the current directory, including `basic-network`, `bin`, `chaincode/fabcar`, and `fabcar`. 
+Then, `fabric-samples` directory is made in the current directory, including `basic-network`, `bin`, `chaincode/fabcar`, and `fabcar`.
 
-- c.f.: https://hyperledger-fabric.readthedocs.io/en/master/install.html#install-samples-binaries-and-docker-images
+- c.f.: https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html
 - If you are behind an proxy environment, use the command that `curl -x http://yourProxyURL:yourProxyPortNumber` instead of `curl`
 
 ## b) Initialization

tools/docker/quorum-all-in-one/start-tessera.sh

@@ -17,7 +17,6 @@ echo Config type ${TESSERA_CONFIG_TYPE}
 #generating the two config flavors
 cat <<EOF > ${DDIR}/tessera-config-09.json
 {
-  "useWhiteList": false,
   "jdbc": {
     "username": "sa",
     "password": "",

whitepaper/whitepaper.md

@@ -763,7 +763,7 @@ Key components are defined as follows:
 Validator ensure the determined result with attaching digital signature with "Validator key" which can be verified by "Verifier".
 - **Validator Server**: The server accepts a connection from Verifier, and it provides Validator API, which can be used for issuing signed transactions and monitoring Ledger behind it. The LedgerConnector will be implemented for interacting with the Ledger nodes.
 - **Verifier**: The entity accepts only sucussfully verified operation results by verifying the digital signature of the validator. Verifier will be instantiated by calling the VerifierFactory#create method with associated with the Validator to connect. Each Verifier may be temporarily enabled or disabled. Note that "Validator" is apart from "Verifier" over a bi-directional channel.
-- **Verifier Registry**: The information about active Verifier. The VerifierFactory uses this information to instantiate Verifier for the Business Logic Plugin. 
+- **Verifier Registry**: The information about active Verifier. The VerifierFactory uses this information to instantiate Verifier for the Business Logic Plugin.
 - ~~**Cactus Routing Interface**: The entity is a routing service between "Business Logic Plugin" and  "Ledger Plugin(s)". The entity is also a routing service between Business Logic Plugin and API calls from "Application user(s)".~~
 - ~~**Ledger-n**: DLT platforms(e.g. Ethereum, Quorum, Hyperledger Fabric, ...)~~
 
@@ -1512,7 +1512,7 @@ Various identities are used at Cactus Service API.
 
 **Wallet ID**
 * ID for the user identity which is associated with authentication credential at integrated `Ledger`.
-* It is recommended to store temporary credential here allowing minimal access to operate `Ledger` instead of giving full access with master secret.
+* It is recommended to store temporary credential here allowing minimal access to operate `Ledger` instead of giving full access with primary secret.
 * Service API enables user to add/update/delete authentication credential for the Wallet.
 
 **Ledger ID**
@@ -1627,7 +1627,7 @@ To get a better understanding of the various, near-infinite deplyoment scenarios
 
 **Identity Secret**: A private key or a password that - by design - is only ever known by the identity owner (unless stolen).
 
-**Credentials**: Could mean `user a`uthentication credentials/identity proofs in an IT application or any other credentials in the traditional sense of the word such as a proof that a person obtained a masters or PhD.
+**Credentials**: Could mean `user a` authentication credentials/identity proofs in an IT application or any other credentials in the traditional sense of the word such as a proof that a person obtained a bachelor's degree or a PhD.
 
 **Ledger/Network/Chain**: Synonymous words meaning referring largely to the same thing in this paper.