Replaces references to master with references to main (#2171)

.azure-pipelines-gh-pages.yml

@@ -2,7 +2,7 @@ trigger:
   batch: true
   branches:
     include:
-      - master
+      - main
       - "refs/tags/ccf-*"
 
 jobs:
@@ -20,7 +20,7 @@ jobs:
           env
           git status
           git rev-parse HEAD
-          git checkout -b master $(git rev-parse HEAD)
+          git checkout -b main $(git rev-parse HEAD)
         displayName: Prepare repo
 
       # Used to generate setup.py
@@ -66,7 +66,7 @@ jobs:
         displayName: "Publish GitHub Pages"
         condition: |
           and(not(eq(variables['Build.Reason'], 'PullRequest')),
-              eq(variables['Build.SourceBranch'], 'refs/heads/master'))
+              eq(variables['Build.SourceBranch'], 'refs/heads/main'))
         workingDirectory: build/html
 
       - script: rm deploy_key || true

.azure-pipelines.yml

@@ -2,14 +2,14 @@ trigger:
   batch: true
   branches:
     include:
-      - master
+      - main
       - "refs/tags/ccf-*"
 
 pr:
   autoCancel: true
   branches:
     include:
-      - master
+      - main
   paths:
     include:
       - "*"
@@ -19,7 +19,7 @@ schedules:
     displayName: Daily morning build
     branches:
       include:
-        - master
+        - main
     always: true
 
 resources:

.daily.yml

@@ -1,7 +1,7 @@
 pr:
   branches:
     include:
-      - master
+      - main
   paths:
     include:
       - .daily.yml
@@ -15,7 +15,7 @@ schedules:
     displayName: Daily build
     branches:
       include:
-        - master
+        - main
     always: true
 
 resources:

.github/CONTRIBUTING.md

@@ -11,9 +11,9 @@ to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simpl
 Note that we only accept pull requests from forks so please fork the CCF repository before making any changes. You should contribute your changes on a branch on that fork and create a pull request on the [microsoft/CCF repository](https://github.com/microsoft/CCF/compare) from there.
 
 All pull requests must pass a suite of CI tests before they are merged.
-Test commands are defined in [`test.yml`](https://github.com/microsoft/CCF/blob/master/.azure-pipelines-templates/test.yml), so you can locally repeat any tests which fail.
+Test commands are defined in [`test.yml`](https://github.com/microsoft/CCF/blob/main/.azure-pipelines-templates/test.yml), so you can locally repeat any tests which fail.
 
-Code must also meet format requirements enforced by [`checks.yml`](https://github.com/microsoft/CCF/blob/master/.azure-pipelines-templates/checks.yml), which can be checked locally by running [`scripts/ci-checks.sh`]. Some formatting issues can be fixed automatically by running [`scripts/ci-checks.sh -f`].
+Code must also meet format requirements enforced by [`checks.yml`](https://github.com/microsoft/CCF/blob/main/.azure-pipelines-templates/checks.yml), which can be checked locally by running [`scripts/ci-checks.sh`]. Some formatting issues can be fixed automatically by running [`scripts/ci-checks.sh -f`].
 
 This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
 For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)

.github/workflows/ci-checks.yml

@@ -2,9 +2,9 @@ name: "Format and License Checks"
 
 on:
   push:
-    branches: [master]
+    branches: [main]
   pull_request:
-    branches: [master]
+    branches: [main]
 
 jobs:
   checks:

.github/workflows/codeql-analysis.yml

@@ -7,7 +7,7 @@ name: "CodeQL"
 
 on:
   push:
-    branches: [master]
+    branches: [main]
 
 jobs:
   analyze:

.github/workflows/daily-check.yml

@@ -9,4 +9,4 @@ jobs:
 
     steps:
       - run: |
-          curl -s https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20GitHub%20Daily?branchName=master | grep succeeded
+          curl -s https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20GitHub%20Daily?branchName=main | grep succeeded

.stress.yml

@@ -1,7 +1,7 @@
 pr:
   branches:
     include:
-      - master
+      - main
   paths:
     include:
       - .stress.yml
@@ -15,7 +15,7 @@ schedules:
     displayName: Stress test build
     branches:
       include:
-        - master
+        - main
     always: true
 
 resources:

CHANGELOG.md

@@ -42,13 +42,13 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ### Changed
 
-- JS endpoints now list their auth policies by name, similar to C++ endpoints. The fields `require_client_identity`, `require_client_signature`, and `require_jwt_authentication` are removed, and should be replaced by `authn_policies`. For example, the previous default `"require_client_identity": true` should be replaced with `"authn_policies": ["user_cert"]`, an endpoint which would like to handle a JWT but will also accept unauthenticated requests would be `"authn_policies": ["jwt", "no_auth"]`, and a fully unauthenticated endpoint would be `"authn_policies": []`. See [docs](https://microsoft.github.io/CCF/master/build_apps/js_app_bundle.html#metadata) for further detail.
+- JS endpoints now list their auth policies by name, similar to C++ endpoints. The fields `require_client_identity`, `require_client_signature`, and `require_jwt_authentication` are removed, and should be replaced by `authn_policies`. For example, the previous default `"require_client_identity": true` should be replaced with `"authn_policies": ["user_cert"]`, an endpoint which would like to handle a JWT but will also accept unauthenticated requests would be `"authn_policies": ["jwt", "no_auth"]`, and a fully unauthenticated endpoint would be `"authn_policies": []`. See [docs](https://microsoft.github.io/CCF/main/build_apps/js_app_bundle.html#metadata) for further detail.
 
 ## [0.17.0]
 
 ### Added
 
-- Versioned APIs for common CCF functionality: `get_status_for_txid_v1`, `get_last_committed_txid_v1`, `generate_openapi_document_v1`, `get_receipt_for_seqno_v1`, `get_quote_for_this_node_v1`. We will aim to support these function signatures long-term, and provide similar functionality with incremental version bumps when this is no longer possible. In particular, this enables building an app which does not expose the [default endpoints](https://microsoft.github.io/CCF/master/build_apps//logging_cpp.html#default-endpoints) but instead exposes similar functionality through its own API.
+- Versioned APIs for common CCF functionality: `get_status_for_txid_v1`, `get_last_committed_txid_v1`, `generate_openapi_document_v1`, `get_receipt_for_seqno_v1`, `get_quote_for_this_node_v1`. We will aim to support these function signatures long-term, and provide similar functionality with incremental version bumps when this is no longer possible. In particular, this enables building an app which does not expose the [default endpoints](https://microsoft.github.io/CCF/main/build_apps//logging_cpp.html#default-endpoints) but instead exposes similar functionality through its own API.
 
 ### Changed
 
@@ -100,13 +100,13 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 - CLI options are printed on every node launch (#1923).
 - JS logging sample app is included in CCF package (#1932).
-- C++ apps can be built using cmake's `find_package(ccf REQUIRED)` (see [cmake sample](https://github.com/microsoft/CCF/blob/master/samples/apps/logging/CMakeLists.txt)) (#1947).
+- C++ apps can be built using cmake's `find_package(ccf REQUIRED)` (see [cmake sample](https://github.com/microsoft/CCF/blob/main/samples/apps/logging/CMakeLists.txt)) (#1947).
 
 ### Changed
 
 - JWT signing keys are auto-refreshed immediately when adding a new issuer instead of waiting until the next auto-refresh event is due (#1978).
 - Snapshots are only committed when proof of snapshot evidence is committed (#1972).
-- Snapshot evidence must be validated before joining/recovering from snapshot (see [doc](https://microsoft.github.io/CCF/master/operations/ledger_snapshot.html#join-recover-from-snapshot)) (#1925).
+- Snapshot evidence must be validated before joining/recovering from snapshot (see [doc](https://microsoft.github.io/CCF/main/operations/ledger_snapshot.html#join-recover-from-snapshot)) (#1925).
 
 ### Fixed
 
@@ -147,8 +147,8 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ### Added
 
-- [JWT documentation](https://microsoft.github.io/CCF/master/developers/auth/jwt.html#jwt-authentication) (#1875).
+- [JWT documentation](https://microsoft.github.io/CCF/main/developers/auth/jwt.html#jwt-authentication) (#1875).
-- [Member keys in HSM documentation](https://microsoft.github.io/CCF/master/members/hsm_keys.html) (#1884).
+- [Member keys in HSM documentation](https://microsoft.github.io/CCF/main/members/hsm_keys.html) (#1884).
 
 ### Changed
 
@@ -189,7 +189,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 - Members' recovery shares are now encrypted using [RSA-OAEP-256](https://docs.microsoft.com/en-gb/azure/key-vault/keys/about-keys#wrapkeyunwrapkey-encryptdecrypt) (#1841). This has the following implications:
   - Network's encryption key is no longer output by the first node of a CCF service is no longer required to decrypt recovery shares.
   - The latest version of the `submit_recovery_share.sh` script should be used.
-  - The latest version of the `proposal_generator.py` should be used (please upgrade the [ccf Python package](https://microsoft.github.io/CCF/master/quickstart/install.html#python-package)).
+  - The latest version of the `proposal_generator.py` should be used (please upgrade the [ccf Python package](https://microsoft.github.io/CCF/main/quickstart/install.html#python-package)).
 - `submit_recovery_share.sh` script's `--rpc-address` argument has been removed. The node's address (e.g. `https://127.0.0.1:8000`) should be used directly as the first argument instead (#1841).
 - The constitution's `pass` function now takes an extra argument: `proposer_id`, which contains the `member_id` of the member who submitted the proposal. To adjust for this change, replace `tables, calls, votes = ...` with `tables, calls, votes, proposer_id = ...` at the beginning of the `pass` definition.
 - Bundled votes (ie. the `ballot` entry in `POST /proposals`) have been removed. Votes can either happen explicitly via `POST /proposals/{proposal_id}/votes`, or the constitution may choose to pass a proposal without separate votes by examining its contents and its proposer, as illustrated in the operating member constitution sample. The `--vote-against` flag in `proposal_generator.py`, has also been removed as a consequence.
@@ -206,7 +206,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ### Changed
 
-- The `start_test_network.sh` script has been replaced by [`sandbox.sh`](https://microsoft.github.io/CCF/master/quickstart/test_network.html). Users wishing to override the default network config (a single node on '127.0.0.1:8000') must now explictly specify if they should be started locally (eg. `-n 'local://127.4.4.5:7000'`) or on remote machine via password-less ssh (eg. `-n 'ssh://10.0.0.1:6000'`).
+- The `start_test_network.sh` script has been replaced by [`sandbox.sh`](https://microsoft.github.io/CCF/main/quickstart/test_network.html). Users wishing to override the default network config (a single node on '127.0.0.1:8000') must now explictly specify if they should be started locally (eg. `-n 'local://127.4.4.5:7000'`) or on remote machine via password-less ssh (eg. `-n 'ssh://10.0.0.1:6000'`).
 - `node/quote` endpoint now returns a single JSON object containing the node's quote (#1761).
 - Calling `foreach` on a `TxView` now iterates over the entries which previously existed, ignoring any modifications made by the functor while iterating.
 - JS: `ccf.kv.<map>.get(key)` returns `undefined` instead of throwing an exception if `key` does not exist.
@@ -403,7 +403,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 - Add clang-format to the application CI container, to facilitate application development (#1340)
 - Websocket handlers are now distinct, and can be defined by passing `ws::Verb::WEBSOCKET` as a verb to `make_endpoint()` (#1333)
-- Custom KV serialisation is [documented](https://microsoft.github.io/CCF/master/developers/kv/kv_serialisation.html#custom-key-and-value-types)
+- Custom KV serialisation is [documented](https://microsoft.github.io/CCF/main/developers/kv/kv_serialisation.html#custom-key-and-value-types)
 
 ### Fixed
 
@@ -413,7 +413,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ### Added
 
-- CLI tool for managing recovery shares (#1295). [usage](https://microsoft.github.io/CCF/master/members/accept_recovery.html#submitting-recovery-shares)
+- CLI tool for managing recovery shares (#1295). [usage](https://microsoft.github.io/CCF/main/members/accept_recovery.html#submitting-recovery-shares)
 - New standard endpoint `node/ids` for retrieving node ID from IP address (#1319).
 - Support for read-only transactions. Use `tx.get_read_only_view` to retrieve read-only views, and install with `make_read_only_endpoint` if all operations are read-only.
 - Support for distinct handlers on the same URI. Each installed handler/endpoint is now associated with a single HTTP method, so you can install different operations on `POST /foo` and `GET /foo`.
@@ -441,19 +441,19 @@ CCF now deals internally only with serialised data in its tables, mapping byte-v
 - Improved resiliency of recovery process (#1051)
 - `foreach` early-exit semantics are now consistent (#1222)
 - Third party dependency updates (#1144, #1148, #1149, #1151, #1155, #1255)
-- All logging output now goes to stdout, and can be configured to be either JSON or plain text (#1258) [doc](https://microsoft.github.io/CCF/master/operators/node_output.html#json-formatting)
+- All logging output now goes to stdout, and can be configured to be either JSON or plain text (#1258) [doc](https://microsoft.github.io/CCF/main/operators/node_output.html#json-formatting)
-- Initial support for historical query handlers (#1207) [sample](https://github.com/microsoft/CCF/blob/master/src/apps/logging/logging.cpp#L262)
+- Initial support for historical query handlers (#1207) [sample](https://github.com/microsoft/CCF/blob/main/src/apps/logging/logging.cpp#L262)
-- Implement the equivalent of "log rolling" for the ledger (#1135) [doc](https://microsoft.github.io/CCF/master/operators/ledger.html)
+- Implement the equivalent of "log rolling" for the ledger (#1135) [doc](https://microsoft.github.io/CCF/main/operators/ledger.html)
-- Internal RPCs renamed to follow more traditional REST conventions (#968) [doc](https://microsoft.github.io/CCF/master/operators/operator_rpc_api.html)
+- Internal RPCs renamed to follow more traditional REST conventions (#968) [doc](https://microsoft.github.io/CCF/main/operators/operator_rpc_api.html)
 
 ### Added
 
 - Support for floating point types in default KV serialiser (#1174)
-- The `start_test_network.sh` script now supports recovering an old network with the `--recover` flag (#1095) [doc](https://microsoft.github.io/CCF/master/users/deploy_app.html#recovering-a-service)
+- The `start_test_network.sh` script now supports recovering an old network with the `--recover` flag (#1095) [doc](https://microsoft.github.io/CCF/main/users/deploy_app.html#recovering-a-service)
 - Application CI and runtime containers are now available (#1178)
   1. `ccfciteam/ccf-app-ci:0.11` is recommended to build CCF applications
   2. `ccfciteam/ccf-app-run:0.11` is recommended to run CCF nodes, for example in k8s
-- Initial websockets support (#629) [sample](https://github.com/microsoft/CCF/blob/master/tests/ws_scaffold.py#L21)
+- Initial websockets support (#629) [sample](https://github.com/microsoft/CCF/blob/main/tests/ws_scaffold.py#L21)
 
 ### Removed
 
@@ -464,8 +464,8 @@ CCF now deals internally only with serialised data in its tables, mapping byte-v
 ### Added
 
 - Brand new versioned documentation: https://microsoft.github.io/CCF.
-- New `/tx` endpoint to check that a transaction is committed (#1111). See [docs](https://microsoft.github.io/CCF/master/users/issue_commands.html#checking-for-commit).
+- New `/tx` endpoint to check that a transaction is committed (#1111). See [docs](https://microsoft.github.io/CCF/main/users/issue_commands.html#checking-for-commit).
-- Disaster recovery is now performed with members key shares (#1101). See [docs](https://microsoft.github.io/CCF/master/members/accept_recovery.html).
+- Disaster recovery is now performed with members key shares (#1101). See [docs](https://microsoft.github.io/CCF/main/members/accept_recovery.html).
 - Open Enclave install is included in CCF install (#1125).
 - New `sgxinfo.sh` script (#1081).
 - New `--transaction-rate` flag to performance client (#1071).

CMakeLists.txt

@@ -825,11 +825,10 @@ if(BUILD_TESTS)
   endforeach()
 
   add_perf_test(
-    NAME logging_scenario_perf_test
+    NAME ls
     PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/infra/perfclient.py
     CONSENSUS cft
     CLIENT_BIN ./scenario_perf_client
-    LABEL log_scenario
     ADDITIONAL_ARGS
       --package
       liblogging
@@ -844,11 +843,10 @@ if(BUILD_TESTS)
   )
 
   add_perf_test(
-    NAME logging_scenario_ws_perf_test
+    NAME ls_ws
     PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/infra/perfclient.py
     CONSENSUS cft
     CLIENT_BIN ./scenario_perf_client
-    LABEL log_scenario_ws
     ADDITIONAL_ARGS
       --package
       liblogging
@@ -864,11 +862,10 @@ if(BUILD_TESTS)
   )
 
   add_perf_test(
-    NAME logging_scenario_jwt_perf_test
+    NAME ls_jwt
     PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/infra/perfclient.py
     CONSENSUS cft
     CLIENT_BIN ./scenario_perf_client
-    LABEL log_scenario_jwt
     ADDITIONAL_ARGS
       --package
       liblogging
@@ -884,11 +881,10 @@ if(BUILD_TESTS)
   )
 
   add_perf_test(
-    NAME logging_scenario_js_perf_test
+    NAME ls_js
     PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/infra/perfclient.py
     CONSENSUS cft
     CLIENT_BIN ./scenario_perf_client
-    LABEL log_scenario_js
     ADDITIONAL_ARGS
       --js-app-bundle
       ${CMAKE_SOURCE_DIR}/samples/apps/logging/js
@@ -903,11 +899,10 @@ if(BUILD_TESTS)
   )
 
   add_perf_test(
-    NAME logging_scenario_js_jwt_perf_test
+    NAME ls_js_jwt
     PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/infra/perfclient.py
     CONSENSUS cft
     CLIENT_BIN ./scenario_perf_client
-    LABEL log_scenario_js_jwt
     ADDITIONAL_ARGS
       --js-app-bundle
       ${CMAKE_SOURCE_DIR}/samples/apps/logging/js

README.md

@@ -1,15 +1,15 @@
 # The Confidential Consortium Framework
 
-<img alt="ccf" align="right" src="https://microsoft.github.io/CCF/master/_images/ccf.svg" width="300">
+<img alt="ccf" align="right" src="https://microsoft.github.io/CCF/main/_images/ccf.svg" width="300">
 
 [![Docs](https://img.shields.io/badge/Docs-succeeded-green)](https://microsoft.github.io/CCF)
 
-|                        |                                                                                                                                                                                                    |
+|                        |                                                                                                                                                                                                |
-| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Continuous Integration | [![Build Status](https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20Github%20CI?branchName=master)](https://dev.azure.com/MSRC-CCF/CCF/_build/latest?definitionId=3&branchName=master)    |
+| Continuous Integration | [![Build Status](https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20Github%20CI?branchName=main)](https://dev.azure.com/MSRC-CCF/CCF/_build/latest?definitionId=3&branchName=main)    |
-| Daily Build            | [![Build Status](https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20GitHub%20Daily?branchName=master)](https://dev.azure.com/MSRC-CCF/CCF/_build/latest?definitionId=7&branchName=master) |
+| Daily Build            | [![Build Status](https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20GitHub%20Daily?branchName=main)](https://dev.azure.com/MSRC-CCF/CCF/_build/latest?definitionId=7&branchName=main) |
-| Documentation          | [![docs](https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20GitHub%20Pages?branchName=master)](https://dev.azure.com/MSRC-CCF/CCF/_build/latest?definitionId=4&branchName=master)         |
+| Documentation          | [![docs](https://dev.azure.com/MSRC-CCF/CCF/_apis/build/status/CCF%20GitHub%20Pages?branchName=main)](https://dev.azure.com/MSRC-CCF/CCF/_build/latest?definitionId=4&branchName=main)         |
-| Containers             | ![Build and Publish Release Containers](https://github.com/microsoft/CCF/workflows/Build%20and%20Publish%20Release%20Containers/badge.svg)                                                         |
+| Containers             | ![Build and Publish Release Containers](https://github.com/microsoft/CCF/workflows/Build%20and%20Publish%20Release%20Containers/badge.svg)                                                     |
 
 The Confidential Consortium Framework (CCF) is an open-source framework for building a new category of secure, highly available,
 and performant applications that focus on multi-party compute and data.
@@ -19,10 +19,10 @@ Leveraging the power of trusted execution environments (TEEs), decentralised sys
 
 ## Get Started with CCF
 
-- [Install](https://microsoft.github.io/CCF/master/build_apps/install_bin.html) CCF on Linux
+- [Install](https://microsoft.github.io/CCF/main/build_apps/install_bin.html) CCF on Linux
-- Read a [short overview of CCF](https://microsoft.github.io/CCF/master/overview/concepts.html) and get familiar with CCF's core concepts
+- Read a [short overview of CCF](https://microsoft.github.io/CCF/main/overview/concepts.html) and get familiar with CCF's core concepts
-- [Build new CCF applications](https://microsoft.github.io/CCF/master/build_apps/index.html) in TypeScript/JavaScript or C++
+- [Build new CCF applications](https://microsoft.github.io/CCF/main/build_apps/index.html) in TypeScript/JavaScript or C++
-- [Contribute](https://microsoft.github.io/CCF/master/contribute) to this repository, following the [contribution guidelines](.github/CONTRIBUTING.md)
+- [Contribute](https://microsoft.github.io/CCF/main/contribute) to this repository, following the [contribution guidelines](.github/CONTRIBUTING.md)
 - Submit [bugs](https://github.com/microsoft/CCF/issues/new?assignees=&labels=bug&template=bug_report.md&title=) and [feature requests](https://github.com/microsoft/CCF/issues/new?assignees=&labels=enhancement&template=feature_request.md&title=)
 - Start a [discussion](https://github.com/microsoft/CCF/discussions/new) to ask a question or propose an idea
 

cmake/common.cmake

@@ -532,22 +532,25 @@ function(add_perf_test)
 
   set(TESTS_SUFFIX "")
   if("sgx" IN_LIST COMPILE_TARGETS)
-    set(TESTS_SUFFIX "${TESTS_SUFFIX}_SGX")
+    set(TESTS_SUFFIX "${TESTS_SUFFIX}_sgx")
-  endif()
-  if("cft" STREQUAL ${PARSED_ARGS_CONSENSUS})
-    set(TESTS_SUFFIX "${TESTS_SUFFIX}_CFT")
-  elseif("bft" STREQUAL ${PARSED_ARGS_CONSENSUS})
-    set(TESTS_SUFFIX "${TESTS_SUFFIX}_BFT")
   endif()
 
+  if("cft" STREQUAL ${PARSED_ARGS_CONSENSUS})
+    set(TESTS_SUFFIX "${TESTS_SUFFIX}_cft")
+  elseif("bft" STREQUAL ${PARSED_ARGS_CONSENSUS})
+    set(TESTS_SUFFIX "${TESTS_SUFFIX}_bft")
+  endif()
+
+  set(TEST_NAME "${PARSED_ARGS_NAME}${TESTS_SUFFIX}")
+
   if(PARSED_ARGS_LABEL)
-    set(LABEL_ARG "${PARSED_ARGS_LABEL}${TESTS_SUFFIX}^")
+    set(LABEL_ARG "${TEST_NAME}^")
   else()
-    set(LABEL_ARG "${PARSED_ARGS_NAME}${TESTS_SUFFIX}^")
+    set(LABEL_ARG "${TEST_NAME}^")
   endif()
 
   add_test(
-    NAME ${PARSED_ARGS_NAME}
+    NAME "${PARSED_ARGS_NAME}${TESTS_SUFFIX}"
     COMMAND
       ${PYTHON} ${PARSED_ARGS_PYTHON_SCRIPT} -b . -c ${PARSED_ARGS_CLIENT_BIN}
       ${CCF_NETWORK_TEST_ARGS} --consensus ${PARSED_ARGS_CONSENSUS} -g
@@ -558,24 +561,24 @@ function(add_perf_test)
 
   # Make python test client framework importable
   set_property(
-    TEST ${PARSED_ARGS_NAME}
+    TEST ${TEST_NAME}
     APPEND
     PROPERTY ENVIRONMENT "PYTHONPATH=${CCF_DIR}/tests:$ENV{PYTHONPATH}"
   )
   if(DEFINED DEFAULT_ENCLAVE_TYPE)
     set_property(
-      TEST ${PARSED_ARGS_NAME}
+      TEST ${TEST_NAME}
       APPEND
       PROPERTY ENVIRONMENT "DEFAULT_ENCLAVE_TYPE=${DEFAULT_ENCLAVE_TYPE}"
     )
   endif()
   set_property(
-    TEST ${PARSED_ARGS_NAME}
+    TEST ${TEST_NAME}
     APPEND
     PROPERTY LABELS perf
   )
   set_property(
-    TEST ${PARSED_ARGS_NAME}
+    TEST ${TEST_NAME}
     APPEND
     PROPERTY LABELS ${PARSED_ARGS_CONSENSUS}
   )

doc/_templates/sidebar-nav-bs.html

@@ -4,7 +4,7 @@
     }
 
     window.addEventListener("DOMContentLoaded",function(){
-        let selectedVersion = "master"
+        let selectedVersion = "main"
         const thisURL = window.location.toString()
         let indexOfVersion = thisURL.indexOf("ccf-")
         if (indexOfVersion != -1) {

doc/audit/python_library.rst

@@ -46,7 +46,7 @@ Finally, the ledger can be iterated over. For each transaction in the ledger, th
 Example
 -------
 
-An example of how to read and verify entries on the ledger can be found in `governance_history.py <https://github.com/microsoft/CCF/blob/master/tests/governance_history.py>`_, which verifies the member voting history for a short-lived service.
+An example of how to read and verify entries on the ledger can be found in `governance_history.py <https://github.com/microsoft/CCF/blob/main/tests/governance_history.py>`_, which verifies the member voting history for a short-lived service.
 
 Since every vote request is signed by the voting member, verified by the primary node and then stored on the ledger, the test performs the following (this sequence of operations is performed sequentially per transaction):
 

doc/build_apps/auth/jwt.rst

@@ -84,7 +84,7 @@ Validating tokens
 -----------------
 
 Validating a token means checking its format, signature, and IdP- and app-specific claims.
-See `samples/apps/forum/src/authentication.ts <https://github.com/microsoft/CCF/blob/master/samples/apps/forum/src/authentication.ts>`_ for an example on how to do this in TypeScript.
+See `samples/apps/forum/src/authentication.ts <https://github.com/microsoft/CCF/blob/main/samples/apps/forum/src/authentication.ts>`_ for an example on how to do this in TypeScript.
 
 Token signing keys are stored in the ``public:ccf.gov.jwt_public_signing_keys`` kv map where the key is the key ID and the value the DER-encoded X.509 certificate. The key ID matches the ``kid`` field in the token header and can be used to retrieve the matching certificate for validation.
 

doc/build_apps/auth/jwt_ms_example.rst

@@ -1,7 +1,7 @@
 JWT Authentication example using Microsoft Identity Platform
 ------------------------------------------------------------
 
-The `Forum sample app <https://github.com/microsoft/CCF/blob/master/samples/apps/forum>`_ of CCF uses the `Microsoft Identity Platform <https://aka.ms/IdentityPlatform>`_ for user authentication.
+The `Forum sample app <https://github.com/microsoft/CCF/blob/main/samples/apps/forum>`_ of CCF uses the `Microsoft Identity Platform <https://aka.ms/IdentityPlatform>`_ for user authentication.
 In this sample, users submit opinions for polls without other users seeing their opinions.
 After a certain number of opinions have been submitted, aggregate statistics can be retrieved.
 
@@ -17,7 +17,7 @@ In the Forum sample the redirect URL is ``https://.../app/site``, and particular
     The latter is also called a single-page application in Microsoft terms.
     For simplicity and because both applications are considered public it is sufficient to register only a single application which will represent both the server and the client.
 
-Open `samples/apps/forum/src/authentication.ts <https://github.com/microsoft/CCF/blob/master/samples/apps/forum/src/authentication.ts>`_ and replace the app ID with the one registered earlier.
+Open `samples/apps/forum/src/authentication.ts <https://github.com/microsoft/CCF/blob/main/samples/apps/forum/src/authentication.ts>`_ and replace the app ID with the one registered earlier.
 This file is responsible for validating incoming JWTs and extracting a user id for associating opinions to users.
 
 The Forum sample can now be run in a local sandbox with:
@@ -30,14 +30,14 @@ The Forum sample can now be run in a local sandbox with:
 
 .. note::
 
-    The `start script <https://github.com/microsoft/CCF/blob/master/samples/apps/forum/test/start.ts>`_ automatically downloads the current JWT public signing keys from Microsoft and stores them in the network using the ``--jwt-issuer`` sandbox argument.
+    The `start script <https://github.com/microsoft/CCF/blob/main/samples/apps/forum/test/start.ts>`_ automatically downloads the current JWT public signing keys from Microsoft and stores them in the network using the ``--jwt-issuer`` sandbox argument.
 
 Navigate to `<https://127.0.0.1:8000/app/site>`_ and click the Login button.
 You will be redirected to the Microsoft Identity Platform for authentication and back to the Forum sample.
 After logging in, polls can be created and opinions submitted.
 
 Note that aggregated opinion data is only returned after reaching a certain threshold.
-To simulate multiple different users submitting opinions, the `start script <https://github.com/microsoft/CCF/blob/master/samples/apps/forum/test/start.ts>`_ adds an additional fake JWT issuer based on a locally generated private key and certificate.
+To simulate multiple different users submitting opinions, the `start script <https://github.com/microsoft/CCF/blob/main/samples/apps/forum/test/start.ts>`_ adds an additional fake JWT issuer based on a locally generated private key and certificate.
 Run the following scripts to submit opinions of fake users using the fake issuer:
 
 .. code-block:: bash

doc/build_apps/build_app.rst

@@ -19,7 +19,7 @@ The :term:`Open Enclave` configuration file (``oe_sign.conf``) should be placed
 
 .. literalinclude:: ../../samples/apps/logging/oe_sign.conf
 
-.. note:: The `Open Enclave documentation <https://github.com/openenclave/openenclave/blob/master/docs/GettingStartedDocs/buildandsign.md#signing-an-SGX-enclave>`_ provides details about the enclave settings in the ``oe_sign.conf`` configuration file.
+.. note:: The `Open Enclave documentation <https://github.com/openenclave/openenclave/blob/main/docs/GettingStartedDocs/buildandsign.md#signing-an-SGX-enclave>`_ provides details about the enclave settings in the ``oe_sign.conf`` configuration file.
 
 Standalone Signing
 ------------------
@@ -56,4 +56,4 @@ It is then possible to inspect the signed enclave library:
 
 For a given application, the ``signature`` field depends on the key used to sign the enclave. See :ref:`governance/common_member_operations:Updating Code Version` for instructions on how members can register new application versions (``mrenclave`` field).
 
-.. note:: The `Open Enclave documentation <https://github.com/openenclave/openenclave/blob/master/docs/GettingStartedDocs/buildandsign.md#signing-an-SGX-enclave>`_. provides further details about how to sign enclave applications using ``oesign``.
+.. note:: The `Open Enclave documentation <https://github.com/openenclave/openenclave/blob/main/docs/GettingStartedDocs/buildandsign.md#signing-an-SGX-enclave>`_. provides further details about how to sign enclave applications using ``oesign``.

doc/build_apps/build_setup.rst

@@ -44,5 +44,5 @@ If you use `Visual Studio Code`_ you can install the `Remote Container`_ extensi
 
 .. _`Visual Studio Code`: https://code.visualstudio.com/
 .. _`Remote Container`: https://code.visualstudio.com/docs/remote/containers
-.. _`devcontainer.json`: https://github.com/microsoft/CCF/blob/master/.devcontainer/devcontainer.json
+.. _`devcontainer.json`: https://github.com/microsoft/CCF/blob/main/.devcontainer/devcontainer.json
 

doc/build_apps/demo.rst

@@ -34,7 +34,7 @@ The following command will run a simple one node test network on a single machin
     [16:14:10.011]   Node [0] = https://127.0.0.1:8000
     [16:14:10.011] You can now issue business transactions to the ./liblogging.virtual.so application.
     [16:14:10.011] Keys and certificates have been copied to the common folder: /data/src/CCF/build/workspace/sandbox_common
-    [16:14:10.011] See https://microsoft.github.io/CCF/master/use_apps/issue_commands.html for more information.
+    [16:14:10.011] See https://microsoft.github.io/CCF/main/use_apps/issue_commands.html for more information.
     [16:14:10.011] Press Ctrl+C to shutdown the network.
 
 The command output shows the addresses of the CCF nodes where commands may be submitted (eg, in this case, via ``curl https://127.0.0.1:8000/...``).

doc/build_apps/example.rst

@@ -51,7 +51,7 @@ The Logging application implements a trivial protocol, made up of four transacti
             "id": 100
         }
 
-The C++ implementation of the Logging application is located in the `src/apps <https://github.com/microsoft/CCF/tree/master/src/apps>`_ folder. It is discussed in detail on the following pages:
+The C++ implementation of the Logging application is located in the `src/apps <https://github.com/microsoft/CCF/tree/main/src/apps>`_ folder. It is discussed in detail on the following pages:
 
 .. toctree::
    :maxdepth: 2

doc/build_apps/js_app_bundle.rst

@@ -38,7 +38,7 @@ It consists of :ref:`metadata <build_apps/js_app_bundle:Metadata>` (``app.json``
 JavaScript modules can `import <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import>`_ other modules using relative path names.
 
 You can find an example app bundle in the
-`tests/js-app-bundle <https://github.com/microsoft/CCF/tree/master/tests/js-app-bundle>`_
+`tests/js-app-bundle <https://github.com/microsoft/CCF/tree/main/tests/js-app-bundle>`_
 folder of the CCF git repository.
 
 Metadata
@@ -92,7 +92,7 @@ Each endpoint object contains the following information:
   types of the endpoint's requests or responses.
 
 You can find an example metadata file at
-`tests/js-app-bundle/app.json <https://github.com/microsoft/CCF/tree/master/tests/js-app-bundle/app.json>`_
+`tests/js-app-bundle/app.json <https://github.com/microsoft/CCF/tree/main/tests/js-app-bundle/app.json>`_
 in the CCF git repository.
 
 .. note::
@@ -156,7 +156,7 @@ A ``Response`` object can contain the following fields (all optional):
   The content type in parentheses is the default and can be overridden in ``headers``.
 
 See the following handler from the example app bundle in the
-`tests/js-app-bundle <https://github.com/microsoft/CCF/tree/master/tests/js-app-bundle>`_
+`tests/js-app-bundle <https://github.com/microsoft/CCF/tree/main/tests/js-app-bundle>`_
 folder of the CCF git repository.
 It validates the request body and returns the result of a mathematical operation:
 

doc/build_apps/js_app_ts.rst

@@ -4,7 +4,7 @@ TypeScript Application
 This guide shows how to build a TypeScript application using Node.js and npm.
 
 The source code for the example app can be found in the
-`tests/npm-app <https://github.com/microsoft/CCF/tree/master/tests/npm-app>`_
+`tests/npm-app <https://github.com/microsoft/CCF/tree/main/tests/npm-app>`_
 folder of the CCF git repository.
 
 Prerequisites
@@ -111,8 +111,8 @@ CCF currently does not provide an npm package with TypeScript definitions
 for :ref:`CCF's JavaScript API <build_apps/js_app_bundle:JavaScript API>`.
 
 Instead, the definitions are part of the sample app in
-`src/types/ccf.ts <https://github.com/microsoft/CCF/tree/master/tests/npm-app/src/types/ccf.ts>`_.
+`src/types/ccf.ts <https://github.com/microsoft/CCF/tree/main/tests/npm-app/src/types/ccf.ts>`_.
-See `src/endpoints <https://github.com/microsoft/CCF/tree/master/tests/npm-app/src/endpoints>`_
+See `src/endpoints <https://github.com/microsoft/CCF/tree/main/tests/npm-app/src/endpoints>`_
 on how the types can be imported and used.
 
 Metadata
@@ -157,7 +157,7 @@ A note on CommonJS modules
 --------------------------
 
 The sample project uses the
-`@rollup/plugin-commonjs <https://github.com/rollup/plugins/tree/master/packages/commonjs>`_
+`@rollup/plugin-commonjs <https://github.com/rollup/plugins/tree/main/packages/commonjs>`_
 package to automatically convert npm packages with CommonJS modules to native JavaScript modules
 so that they can be used in CCF.
 

doc/build_apps/js_app_tsoa.rst

@@ -10,7 +10,7 @@ Using `tsoa <https://github.com/lukeautry/tsoa>`_ as framework provides the foll
 - App metadata (``app.json``) is auto-generated as much as possible.
 
 The source code for the example app can be found in the
-`samples/apps/forum <https://github.com/microsoft/CCF/tree/master/samples/apps/forum>`_
+`samples/apps/forum <https://github.com/microsoft/CCF/tree/main/samples/apps/forum>`_
 folder of the CCF git repository.
 
 .. note::
@@ -94,7 +94,7 @@ tsoa discovers controllers through a list of search locations specified in ``tso
         ]
     }
 
-As an example, the ``/polls`` route of the sample app is implemented as in `src/controllers/poll.ts <https://github.com/microsoft/CCF/tree/master/samples/apps/forum/src/controllers/poll.ts>`_.
+As an example, the ``/polls`` route of the sample app is implemented as in `src/controllers/poll.ts <https://github.com/microsoft/CCF/tree/main/samples/apps/forum/src/controllers/poll.ts>`_.
 
 For more information on how to write controllers,
 see the `tsoa documentation <https://tsoa-community.github.io/docs/getting-started.html#defining-a-simple-controller>`_.
@@ -117,7 +117,7 @@ Headers and the status code can be set using `Controller methods <https://tsoa-c
 
 Sometimes though it is necessary to access CCF's ``Request`` object, for example when the request body is not JSON.
 In this case, instead of using ``@Body() body: MyType`` as function argument, ``@Request() request: ccf.Request`` can be used.
-See `src/controllers/csv.ts <https://github.com/microsoft/CCF/tree/master/samples/apps/forum/src/controllers/csv.ts>`_
+See `src/controllers/csv.ts <https://github.com/microsoft/CCF/tree/main/samples/apps/forum/src/controllers/csv.ts>`_
 for a concrete example.
 
 .. warning::

doc/build_apps/run_app.rst

@@ -6,7 +6,7 @@ Running CCF Applications
     - The CCF runtime environment has successfully been setup (see :doc:`/operations/run_setup`).
     - CCF is installed (see :doc:`/build_apps/install_bin`)
 
-The quickest way to start a CCF sandbox is to use the `sandbox.sh <https://github.com/microsoft/CCF/blob/master/tests/sandbox/sandbox.sh>`_ test script, specifying the :doc:`enclave image </build_apps/index>` to run.
+The quickest way to start a CCF sandbox is to use the `sandbox.sh <https://github.com/microsoft/CCF/blob/main/tests/sandbox/sandbox.sh>`_ test script, specifying the :doc:`enclave image </build_apps/index>` to run.
 
 The script creates a new one node CCF test network running locally. All the governance requests required to open the network to users are automatically issued.
 
@@ -23,7 +23,7 @@ For example, deploying the ``liblogging`` example application:
     [16:14:10.011]   Node [0] = https://127.0.0.1:8000
     [16:14:10.011] You can now issue business transactions to the ./liblogging.virtual.so application.
     [16:14:10.011] Keys and certificates have been copied to the common folder: /data/src/CCF/build/workspace/sandbox_common
-    [16:14:10.011] See https://microsoft.github.io/CCF/master/use_apps/issue_commands.html for more information.
+    [16:14:10.011] See https://microsoft.github.io/CCF/main/use_apps/issue_commands.html for more information.
     [16:14:10.011] Press Ctrl+C to shutdown the network.
 
 .. note::
@@ -61,7 +61,7 @@ Additionally, if snapshots were generated by the defunct service (using the ``--
     [16:24:32.885]   Node [1] = https://127.0.0.1:8000
     [16:24:32.885] You can now issue business transactions to the liblogging.enclave.so.signed application.
     [16:24:32.885] Keys and certificates have been copied to the common folder: ./workspace/sandbox_common/
-    [16:24:32.885] See https://microsoft.github.io/CCF/master/use_apps/issue_commands.html for more information.
+    [16:24:32.885] See https://microsoft.github.io/CCF/main/use_apps/issue_commands.html for more information.
     [16:24:32.885] Press Ctrl+C to shutdown the network.
 
 The effects of transactions committed by the defunct network should then be recovered. Users can also :ref:`issue new business requests <use_apps/issue_commands:Issuing Commands>`.
@@ -84,9 +84,9 @@ Integration Tests
 -----------------
 
 The ``sandbox.sh`` script can be a helpful element of infrastructure to execute Integration Tests against a CCF test network running a particular application.
-`test_install.sh <https://github.com/microsoft/CCF/blob/master/tests/test_install.sh>`_ is a good example of that, using the sandbox to run `tutorial.py <https://github.com/microsoft/CCF/blob/master/python/tutorial.py>`_ on a release package.
+`test_install.sh <https://github.com/microsoft/CCF/blob/main/tests/test_install.sh>`_ is a good example of that, using the sandbox to run `tutorial.py <https://github.com/microsoft/CCF/blob/main/python/tutorial.py>`_ on a release package.
 
-``test_install.sh`` illustrates how to wait for the sandbox to be `ready <https://github.com/microsoft/CCF/blob/master/tests/test_install.sh#L33>`_ before issuing application transactions, how to shut it down cleanly,
+``test_install.sh`` illustrates how to wait for the sandbox to be `ready <https://github.com/microsoft/CCF/blob/main/tests/test_install.sh#L33>`_ before issuing application transactions, how to shut it down cleanly,
 and how to trigger a recovery. Recovering a test network can be a useful way to inspect post-test application test.
 
 Performance Tests

doc/build_apps/upgrading_app.rst

@@ -3,7 +3,7 @@ Upgrade Your Application
 
 As CCF is still in pre-release, it is possible that new versions of the framework will break existing applications. As such, these may require updates to compile and run successfully when upgrading CCF.
 
-The sample `logging application <https://github.com/microsoft/CCF/tree/master/src/apps/logging>`_ is currently the reference application that developers should look at when building and upgrading their application.
+The sample `logging application <https://github.com/microsoft/CCF/tree/main/src/apps/logging>`_ is currently the reference application that developers should look at when building and upgrading their application.
 
 .. note::
 
@@ -11,4 +11,4 @@ The sample `logging application <https://github.com/microsoft/CCF/tree/master/sr
 
 .. warning::
 
-    It is also possible that the governance Lua script also requires updating. You can compare your governance script with the `latest governance script samples available in GitHub <https://github.com/microsoft/CCF/tree/master/src/runtime_config>`_.
+    It is also possible that the governance Lua script also requires updating. You can compare your governance script with the `latest governance script samples available in GitHub <https://github.com/microsoft/CCF/tree/main/src/runtime_config>`_.

doc/conf.py

@@ -194,7 +194,7 @@ breathe_default_project = "CCF"
 # Set up multiversion extension
 
 smv_tag_whitelist = r"^ccf-.*$"
-smv_branch_whitelist = r"^master$"
+smv_branch_whitelist = r"^main$"
 smv_remote_whitelist = None
 smv_outputdir_format = "{ref.name}"
 
@@ -211,7 +211,7 @@ html_theme_options = {
 html_context = {
     "github_user": "Microsoft",
     "github_repo": "CCF",
-    "github_version": "master",
+    "github_version": "main",
     "doc_path": "doc/",
 }
 

doc/contribute/build_ccf.rst

@@ -62,7 +62,7 @@ Tests can be started through the ``tests.sh`` wrapper for ``ctest``.
     $ cd build
     $ ./tests.sh
 
-Although CCF's unit tests can be run through ``ctest`` directly, the end-to-end tests that start a network require some Python infrastructure. `tests.sh <https://github.com/microsoft/CCF/blob/master/tests/tests.sh>`_ will set up a virtual environment with these dependencies and activate it before running ``ctest`` (use ``-VV`` for verbose test output). Further runs will re-use that virtual environment.
+Although CCF's unit tests can be run through ``ctest`` directly, the end-to-end tests that start a network require some Python infrastructure. `tests.sh <https://github.com/microsoft/CCF/blob/main/tests/tests.sh>`_ will set up a virtual environment with these dependencies and activate it before running ``ctest`` (use ``-VV`` for verbose test output). Further runs will re-use that virtual environment.
 
 .. note::
     On a full build of CCF, it is also possible to run tests with virtual enclaves by setting the ``TEST_ENCLAVE`` environment variable:

doc/contribute/index.rst

@@ -3,7 +3,7 @@ Contribute
 
 The CCF team welcome contributions to any part of the framework, including this documentation.
 
-- Contributions guidelines are outlined on `GitHub <https://github.com/microsoft/CCF/blob/master/.github/CONTRIBUTING.md>`_
+- Contributions guidelines are outlined on `GitHub <https://github.com/microsoft/CCF/blob/main/.github/CONTRIBUTING.md>`_
 - Submit `bugs <https://github.com/microsoft/CCF/issues/new?assignees=&labels=bug&template=bug_report.md&title=>`_ and `feature requests <https://github.com/microsoft/CCF/issues/new?assignees=&labels=enhancement&template=feature_request.md&title=>`_
 
 .. panels::

doc/governance/hsm_keys.rst

@@ -95,7 +95,7 @@ The member's identity key is now ready to be used for signing HTTP requests. The
 
 .. note:: The signatures returned by AKV are returned as a `JWS signature <https://tools.ietf.org/html/rfc7518#section-3.4>`_ and encoded in `base64url <https://tools.ietf.org/html/rfc4648#section-5>`_ format and are not directly compatible with the signatures supported by CCF.
 
-The `jws_to_der.py <https://github.com/microsoft/CCF/blob/master/doc/governance/jws_to_der.py>`_ Python script can be used to convert a JWS signature generated by AKV to a DER signature compatible with CCF:
+The `jws_to_der.py <https://github.com/microsoft/CCF/blob/main/doc/governance/jws_to_der.py>`_ Python script can be used to convert a JWS signature generated by AKV to a DER signature compatible with CCF:
 
 .. code-block:: bash
 

doc/index.html

@@ -1 +1 @@
-<html> <meta http-equiv="refresh" content="0; url=./master/" /> </html>
+<html> <meta http-equiv="refresh" content="0; url=./main/" /> </html>

doc/overview/constitution.rst

@@ -61,8 +61,8 @@ The constitution can limit or remove the operating members' ability to:
 
 This `operating member constitution`_ shows how some members can be made operators.
 
-.. _simple constitution: https://github.com/microsoft/CCF/blob/master/src/runtime_config/gov.lua
+.. _simple constitution: https://github.com/microsoft/CCF/blob/main/src/runtime_config/gov.lua
 
-.. _operating member constitution: https://github.com/microsoft/CCF/blob/master/src/runtime_config/operator_gov.lua
+.. _operating member constitution: https://github.com/microsoft/CCF/blob/main/src/runtime_config/operator_gov.lua
 
-.. _simple constitution with veto: https://github.com/microsoft/CCF/blob/master/src/runtime_config/gov_veto.lua
+.. _simple constitution with veto: https://github.com/microsoft/CCF/blob/main/src/runtime_config/gov_veto.lua

doc/overview/performance.rst

@@ -6,9 +6,9 @@ Overview
 
 CCF pairs strong confidentiality guarantees with `very high performance <TR_>`_. CCF can sustain high transaction throughput, while also reaching consensus over global commits with low latency.
 
-.. _TR: https://github.com/microsoft/CCF/blob/master/CCF-TECHNICAL-REPORT.pdf
+.. _TR: https://github.com/microsoft/CCF/blob/main/CCF-TECHNICAL-REPORT.pdf
 
-There are several performance metrics in the CI test suite to ensure this, ranging from micro-benchmarks of critical systems to end-to-end tests measuring peak throughput. These are run against every PR and commit to the master branch. You can also run these locally to test the configuration of your machines, and use them as a basis for creating performance tests of your own CCF application.
+There are several performance metrics in the CI test suite to ensure this, ranging from micro-benchmarks of critical systems to end-to-end tests measuring peak throughput. These are run against every PR and commit to the main branch. You can also run these locally to test the configuration of your machines, and use them as a basis for creating performance tests of your own CCF application.
 
 Micro-benchmarks
 ----------------
@@ -118,4 +118,4 @@ These plots can also be used over longer tests to gauge outlier severity and fre
 .. image:: ../img/200k_signed.png
 
 .. _bitcoin_256k1: https://github.com/bitcoin-core/secp256k1
-.. _SmallBank: https://github.com/microsoft/CCF/tree/master/samples/apps/smallbank
+.. _SmallBank: https://github.com/microsoft/CCF/tree/main/samples/apps/smallbank

metrics.yml

@@ -1,8 +1,8 @@
 db: "ccf"
 collection: "perf"
 view: "trend"
-columns: 3
+columns: 4
-span: 50
+span: 20
 ewma_span: 4
 pr_user: "ccf-bot"
 monitoring_issue: 1063

python/README.md

@@ -4,4 +4,4 @@ Suite of Python tools for the Confidential Consortium Framework (CCF).
 
 For more information, please find the the CCF documentation at https://microsoft.github.io/CCF.
 
-Package sources are available at https://github.com/microsoft/CCF/tree/master/python.
+Package sources are available at https://github.com/microsoft/CCF/tree/main/python.

python/setup.py.in

@@ -21,7 +21,7 @@ setup(
     description="Set of tools and utilities for the Confidential Consortium Framework (CCF)",
     long_description=long_description,
     long_description_content_type="text/markdown",
-    url="https://github.com/microsoft/CCF/tree/master/python",
+    url="https://github.com/microsoft/CCF/tree/main/python",
     license="Apache License 2.0",
     author="CCF Team",
     classifiers=[

src/apps/smallbank/smallbank.cmake

@@ -55,11 +55,10 @@ if(BUILD_TESTS)
 
   foreach(CONSENSUS ${CONSENSUSES})
     add_perf_test(
-      NAME small_bank_client_test_${CONSENSUS}
+      NAME sb
       PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/small_bank_client.py
       CLIENT_BIN ./small_bank_client
       VERIFICATION_FILE ${SMALL_BANK_VERIFICATION_FILE}
-      LABEL SB
       CONSENSUS ${CONSENSUS}
       ADDITIONAL_ARGS
         --transactions ${SMALL_BANK_ITERATIONS} --max-writes-ahead 250
@@ -68,11 +67,10 @@ if(BUILD_TESTS)
   endforeach()
 
   add_perf_test(
-    NAME small_bank_client_ws_test_cft
+    NAME sb_ws
     PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/small_bank_client.py
     CLIENT_BIN ./small_bank_client
     VERIFICATION_FILE ${SMALL_BANK_VERIFICATION_FILE}
-    LABEL SB_WS
     CONSENSUS cft
     ADDITIONAL_ARGS
       --transactions
@@ -85,11 +83,10 @@ if(BUILD_TESTS)
   )
 
   add_perf_test(
-    NAME small_bank_sigs_client_test_cft
+    NAME sb_sig
     PYTHON_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/tests/small_bank_client.py
     CLIENT_BIN ./small_bank_client
     VERIFICATION_FILE ${SMALL_BANK_SIGNED_VERIFICATION_FILE}
-    LABEL "SB_sig"
     CONSENSUS cft
     ADDITIONAL_ARGS
       --transactions

tests/start_network.py

@@ -92,7 +92,7 @@ def run(args):
             f"Keys and certificates have been copied to the common folder: {network.common_dir}"
         )
         LOG.info(
-            "See https://microsoft.github.io/CCF/master/users/issue_commands.html for more information"
+            "See https://microsoft.github.io/CCF/main/users/issue_commands.html for more information"
         )
         LOG.warning("Press Ctrl+C to shutdown the network")