Merge pull request #2593 from suvajit-sarkar/develop

chore: merged changes from main to develop

.github/workflows/scorecard.yml

@@ -0,0 +1,73 @@
+# This workflow uses actions that are not certified by GitHub. They are provided
+# by a third-party and are governed by separate terms of service, privacy
+# policy, and support documentation.
+
+name: Scorecard supply-chain security
+on:
+  # For Branch-Protection check. Only the default branch is supported. See
+  # https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection
+  branch_protection_rule:
+  # To guarantee Maintained check is occasionally updated. See
+  # https://github.com/ossf/scorecard/blob/main/docs/checks.md#maintained
+  schedule:
+    - cron: '37 8 * * 3'
+  push:
+    branches: [ "main" ]
+
+# Declare default permissions as read only.
+permissions: read-all
+
+jobs:
+  analysis:
+    name: Scorecard analysis
+    runs-on: ubuntu-latest
+    permissions:
+      # Needed to upload the results to code-scanning dashboard.
+      security-events: write
+      # Needed to publish results and get a badge (see publish_results below).
+      id-token: write
+      # Uncomment the permissions below if installing in a private repository.
+      # contents: read
+      # actions: read
+
+    steps:
+      - name: "Checkout code"
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+        with:
+          persist-credentials: false
+
+      - name: "Run analysis"
+        uses: ossf/scorecard-action@0864cf19026789058feabb7e87baa5f140aac736 # v2.3.1
+        with:
+          results_file: results.sarif
+          results_format: sarif
+          # (Optional) "write" PAT token. Uncomment the `repo_token` line below if:
+          # - you want to enable the Branch-Protection check on a *public* repository, or
+          # - you are installing Scorecard on a *private* repository
+          # To create the PAT, follow the steps in https://github.com/ossf/scorecard-action?tab=readme-ov-file#authentication-with-fine-grained-pat-optional.
+          # repo_token: ${{ secrets.SCORECARD_TOKEN }}
+
+          # Public repositories:
+          #   - Publish results to OpenSSF REST API for easy access by consumers
+          #   - Allows the repository to include the Scorecard badge.
+          #   - See https://github.com/ossf/scorecard-action#publishing-results.
+          # For private repositories:
+          #   - `publish_results` will always be set to `false`, regardless
+          #     of the value entered here.
+          publish_results: true
+
+      # Upload the results as artifacts (optional). Commenting out will disable uploads of run results in SARIF
+      # format to the repository Actions tab.
+      - name: "Upload artifact"
+        uses: actions/upload-artifact@97a0fba1372883ab732affbe8f94b823f91727db # v3.pre.node20
+        with:
+          name: SARIF file
+          path: results.sarif
+          retention-days: 5
+
+      # Upload the results to GitHub's code scanning dashboard (optional).
+      # Commenting out will disable upload of results to your repo's Code Scanning dashboard
+      - name: "Upload to code-scanning"
+        uses: github/codeql-action/upload-sarif@1b1aada464948af03b950897e5eb522f92603cc2 # v3.24.9
+        with:
+          sarif_file: results.sarif

CHANGELOG.md

@@ -0,0 +1,3 @@
+# Change Log
+
+All notable changes to this project will be documented in the release [logs](https://github.com/hyperledger/bevel/releases).

GOVERNANCE.md

@@ -0,0 +1,68 @@
+# Governance
+
+Hyperledger Bevel is managed under an open governance model as described in the Hyperledger charter. Bevel is led by a set of maintainers, who can be found in the MAINTAINERS.md file.
+
+**Maintainers**
+
+Bevel is led by the project’s maintainers. The maintainers are responsible for reviewing and merging all patches submitted for review, and they guide the overall technical direction of the project within the guidelines established by the Hyperledger Technical Oversighting Committee (TOC).
+
+**Becoming a Maintainer**
+
+The project’s maintainers will, from time-to-time, consider adding or removing a maintainer. An existing maintainer can submit a change set to the MAINTAINERS.md file. A nominated contributor may become a maintainer by a three-quarters approval of the proposal by the existing maintainers. Once approved, the change set is then merged and the individual is added to (or alternatively, removed from) the maintainers group.
+
+Maintainers may be removed by explicit resignation, for prolonged inactivity (3 or more months), or for some infraction of the code of conduct or by consistently demonstrating poor judgement. A maintainer removed for inactivity should be restored following a sustained resumption of contributions and reviews (a month or more) demonstrating a renewed commitment to the project.  We require that maintainers that will be temporarily inactive do so “gracefully” and update other maintainers on their status and time availability rather than appearing to “fall off the face of the earth.”
+
+**Releases**
+
+A majority of the maintainers may decide to create a release of Bevel. 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**
+
+Code changes that are either bug fixes, direct and small improvements, or things that are on the roadmap (see below) can be issued as PRs in a relatively quick time period, although we recommend creating a Github ticket to track even bugs and small improvements.  For more substantial changes, however, a feature/enhancement proposal is required.  These proceed through the approval process like typical PRs, and require the same “1 + 1” approval policy for acceptance.
+
+In particular, all contributors to the project should have enough time to voice an opinion on feature/enhancement proposals before they are accepted.  So the maintainers will determine some “comment period” between proposal submission and acceptance so that contributors have enough time to voice their opinions.
+
+We also recommend reading our CONTRIBUTING.md file (https://github.com/hyperledger/bevel/blob/main/CONTRIBUTING.md) for more information about contributing.
+
+**Approving Pull Requests**
+
+Maintainers designated for review are required to review PRs in a timely manner (all circumstances considered, of course).  Any pull request must be reviewed by at least two maintainers, and if a PR is submitted by a maintainer, these two reviewers must be different from the original submitter.
+
+The technical requirements for submitting/approving/merging pull requests are further detailed in the CONTRIBUTING.md file where it is laid out in detail how to ensure git commit graph tidiness.
+
+**Reviewing Pull Requests**
+
+We are strongly committed to processing pull requests from everyone in a fair manner meaning that pull requests are to be
+reviewed in order of submission.
+Reviewing PRs in order of submission does not guarantee nor necessitate accepting/merging said PRs in order of submission
+since some PRs may require lengthy feedback loops while others may pass the muster without any change requests or
+feedback at all, depending on the nature of the change being proposed.
+Security related pull requests may be fast tracked even against the "in order of submission" principle if it appears
+that a vulnerability makes a pull request a time sensitive issue where the sooner we propagate a fix the better it is.
+
+**Maintainers Meeting**
+
+The maintainers hold regular maintainers meetings, which are open to everyone. The purpose of the maintainers meeting is to plan for and review the progress of releases, and to discuss the technical and operational direction of the project.
+
+Please see the wiki for maintainer meeting details.
+
+One point to mention about meetings is that new feature/enhancement proposals as described above should be presented to a maintainers meeting for consideration, feedback, and acceptance.
+
+**Roadmap**
+
+The Bevel maintainers are required to maintain a roadmap. There is a public-friendly [roadmap](https://hyperledger-bevel.readthedocs.io/en/latest/references/roadmap/) that anyone can digest. The required features to be implemented will be maintained as issues at the official github repository of Bevel with tag string ‘for current release’ or ‘for future release’. The task which is not volunteered to work, will be dispatched to specific contributors following consensus among the majority of maintainers.
+
+
+**Communications**
+
+We use the Bevel email list for long-form communications and Discord for short, informal announcements and other communications.  We encourage all communication, whenever possible, to be public and in the clear (i.e. rather than sending an email directly to a person or two, send it out to the whole list if it pertains to the project).
+
+**Future Changes**
+
+The governance of Bevel may change as the project evolves.  In particular, if the project becomes large, we will incorporate tiered maintainership, with top-level maintainers, subprojects, subproject maintainers, release managers, and so forth.  We emphasize that this document is intended to be “living” and will be updated periodically.
+
+We require that changes to this document require a three-quarters approval of the existing maintainers.  Note that this may also be changed in the future if deemed necessary.
+
+**Attribution**
+
+This document is based on the Hyperledger Cacti governance document, with some substantial changes.

README.md

@@ -4,6 +4,7 @@
 [chat-image]: https://img.shields.io/discord/905194001349627914?logo=Hyperledger&style=plastic.svg
 
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](LICENSE) [![Documentation Status](https://readthedocs.org/projects/hyperledger-bevel/badge/?version=latest)](https://hyperledger-bevel.readthedocs.io/en/latest/?badge=latest) [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3548/badge)](https://bestpractices.coreinfrastructure.org/projects/3548)
+ [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/hyperledger/bevel/badge)](https://scorecard.dev/viewer/?uri=github.com/hyperledger/bevel)
 [![DCI Lint Status](https://github.com/hyperledger/bevel/actions/workflows/dci_lint.yml/badge.svg)](https://github.com/hyperledger/bevel/actions/workflows/dci_lint.yml)
 
 - [Short Description](#short-description)

ROADMAP.md

@@ -0,0 +1,3 @@
+# Hyperledger Bevel Roadmap
+
+Roadmap to this project will be documented [here](https://hyperledger-bevel.readthedocs.io/en/latest/references/roadmap/)

SECURITY.md

@@ -0,0 +1,9 @@
+# Hyperledger Security Policy
+
+## Reporting a Security Bug
+
+If you think you have discovered a security issue in any of the Hyperledger projects, we'd love to hear from you. We will take all security bugs seriously and if confirmed upon investigation we will patch it within a reasonable amount of time and release a public security bulletin discussing the impact and credit the discoverer.
+
+In order to report a security bug please email a description of the flaw and any related information (e.g. reproduction steps, version) to [security at hyperledger dot org](mailto:security@hyperledger.org).
+
+The process by which the Hyperledger Security Team handles security bugs is documented further in our [Defect Response page](https://wiki.hyperledger.org/display/SEC/Defect+Response) on our [wiki](https://wiki.hyperledger.org).

platforms/hyperledger-fabric/configuration/roles/create/refresh_certs/create_channel_block/tasks/nested_main.yaml

@@ -22,7 +22,7 @@
     channel_name: "{{ sys_channel_name }}"
     namespace: "{{ component_ns }}"
 
-# Create the update-channel-scriptk.sh file for organizations
+# Create the update-channel-script.sh file for organizations
 - name: "Create update-channel-script.sh script file for orderers"
   template:
     src: "update_consenter_script.tpl"

platforms/hyperledger-fabric/configuration/roles/create/refresh_certs/create_channel_block/templates/update_consenter_script.tpl

@@ -6,6 +6,8 @@ CURRENT_DIR=${PWD}
 
 echo "installing jq "
 apt-get install -y jq
+echo "installing wget "
+apt-get wget
 echo "installing sed "
 apk add sed
 echo "installing configtxlator"

platforms/hyperledger-fabric/configuration/roles/helm_component/templates/approve_chaincode_job.tpl

@@ -53,7 +53,7 @@ spec:
       lang: {{ component_chaincode.lang | default('golang') }}
       commitarguments: {{ component_chaincode.arguments | default('') | quote }}
       endorsementpolicies:  {{ component_chaincode.endorsements | default('') | quote }}
-      initrequired: {{ component_chaincode.init_required }}
+      initrequired: {{ component_chaincode.init_required | default('false') | quote }}
 {% if component_chaincode.repository is defined %}
       repository:
         hostname: "{{ component_chaincode.repository.url.split('/')[0] | lower }}"

platforms/hyperledger-indy/configuration/roles/check/k8_component/tasks/main.yaml

@@ -30,7 +30,7 @@
     secret="{{ service_account }}-token"
     kube_token="$(KUBECONFIG={{ kubernetes.config_file }} kubectl get secret ${secret} -n {{ component_ns }} -o go-template={% raw %}'{{ .data.token }}'{% endraw %} | base64 -d)"
     vault_token=$(curl --request POST --data '{"jwt": "'"$kube_token"'", "role": "{{ role }}"}' {{ vault.url }}/v1/auth/kubernetes-{{ organization }}-bevel-ac-auth/login | jq -j '.auth.client_token')
-    echo ${vault_token}
+    echo $vault_token
   register: token_output
   when: component_type == "GetServiceAccount"
 

platforms/hyperledger-indy/configuration/samples/network-indy-newnode-to-baf-network.yaml

@@ -15,11 +15,11 @@ network:
   # Network level configuration specifies the attributes required for each organization
   # to join an existing network.
   type: indy
-  version: 1.11.0                         # Supported versions 1.11.0 and 1.12.1
+  version: 1.12.6                         # Supported versions 1.11.0, 1.12.1 & 1.12.6
 
   #Environment section for Kubernetes setup
   env:
-    type: indy             # tag for the environment. Important to run multiple flux on single cluster
+    type: indy                      # tag for the environment. Important to run multiple flux on single cluster
     proxy: ambassador               # value has to be 'ambassador' as 'haproxy' has not been implemented for Indy
     proxy_namespace: "ambassador"
     #  These ports are enabled per cluster, so if you have multiple clusters you do not need so many ports
@@ -67,6 +67,8 @@ network:
       region: "region"                        # AWS region
 
     publicIps: ["3.221.78.194"]             # List of all public IP addresses of each availability zone from all organizations in the same k8s cluster
+    azure:
+        node_resource_group: "MC_myResourceGroup_myCluster_westeurope"
 
     # Kubernetes cluster deployment variables. The config file path has to be provided in case
     # the cluster has already been created.
@@ -165,6 +167,8 @@ network:
       region: "region"                        # AWS region
 
     publicIps: ["3.221.78.194"]               # List of all public IP addresses of each availability zone from all organizations in the same k8s cluster                        # List of all public IP addresses of each availability zone
+    azure:
+        node_resource_group: "MC_myResourceGroup_myCluster_westeurope"
 
     # Kubernetes cluster deployment variables. The config file path has to be provided in case
     # the cluster has already been created.

platforms/hyperledger-indy/configuration/samples/network-indy-newnode-to-non-baf-network.yaml

@@ -14,11 +14,11 @@ network:
   # Network level configuration specifies the attributes required for each organization
   # to join an existing network.
   type: indy
-  version: 1.11.0                         # Supported versions 1.11.0 and 1.12.1
+  version: 1.12.6                         # Supported versions 1.11.0, 1.12.1 & 1.12.6
 
   #Environment section for Kubernetes setup
   env:
-    type: indy             # tag for the environment. Important to run multiple flux on single cluster
+    type: indy                      # tag for the environment. Important to run multiple flux on single cluster
     proxy: ambassador               # value has to be 'ambassador' as 'haproxy' has not been implemented for Indy
     proxy_namespace: "ambassador"
     #  These ports are enabled per cluster, so if you have multiple clusters you do not need so many ports
@@ -66,6 +66,8 @@ network:
       region: "region"                        # AWS region
 
     publicIps: ["3.221.78.194"]               # List of all public IP addresses of each availability zone from all organizations in the same k8s cluster                        # List of all public IP addresses of each availability zone
+    azure:
+        node_resource_group: "MC_myResourceGroup_myCluster_westeurope"
 
     # Kubernetes cluster deployment variables. The config file path has to be provided in case
     # the cluster has already been created.

platforms/hyperledger-indy/configuration/samples/network-minikube-aries.yaml

@@ -14,14 +14,14 @@ network:
   # Network level configuration specifies the attributes required for each organization
   # to join an existing network.
   type: indy
-  version: 1.11.0                         # Supported versions 1.11.0 and 1.12.1
+  version: 1.12.6                         # Supported versions 1.11.0, 1.12.1 & 1.12.6
 
   #Environment section for Kubernetes setup
   env:
     type: "bevel"                     # tag for the environment. Important to run multiple flux on single cluster
-    proxy: none               # proxy is none for minikube/single cluster
-    retry_count: 20                 # Retry count for the checks
-    external_dns: disabled          # Should be enabled if using external-dns for automatic route configuration
+    proxy: none                       # proxy is none for minikube/single cluster
+    retry_count: 20                   # Retry count for the checks
+    external_dns: disabled            # Should be enabled if using external-dns for automatic route configuration
 
   # Docker registry details where images are stored. This will be used to create k8s secrets
   # Please ensure all required images are built and stored in this registry.
@@ -48,6 +48,8 @@ network:
       type: peer
       cloud_provider: minikube             
       publicIps: []                        # Public Ips of stewards/nodes [public ip of minikube]
+      azure:
+        node_resource_group: "MC_myResourceGroup_myCluster_westeurope"
 
       # Kubernetes cluster deployment variables. The config file path has to be provided in case
       # the cluster has already been created.
@@ -91,6 +93,8 @@ network:
       type: peer
       cloud_provider: minikube             
       publicIps: ["192.168.99.173"]        # Public Ips of stewards/nodes [public ip of minikube]
+      azure:
+        node_resource_group: "MC_myResourceGroup_myCluster_westeurope"
 
       # Kubernetes cluster deployment variables. The config file path has to be provided in case
       # the cluster has already been created.