Fabric Gateway client API

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Pull requests allow iterative collaborative review of code changes before they are accepted. Every code change is stored in the commit history and is publicly visible. Release versions are periodically tagged and published, and may contain many individual commits: https://github.com/hyperledger/fabric-gateway/releases

Repository on GitHub, which uses git. git is distributed.

SemVer stye versioning is used for releases. A specific release version applies to associated Go, Node (in the npm registry) and Java (in Maven Central) published artifacts: https://github.com/hyperledger/fabric-gateway/releases

Each release has a corresponding Git tag: https://github.com/hyperledger/fabric-gateway/tags Automated build processes publish release artifacts based on the Git tag.

Non-trivial release notes file in repository: https://github.com/hyperledger/fabric-gateway/blob/main/CHANGELOG.md. Release notes are recorded using GitHub releases: https://github.com/hyperledger/fabric-gateway/releases

No vulnerabilities have been identified for this project. Release notes include vulnerabilities in dependencies that are resolved by dependency updates in a given release, for example: https://github.com/hyperledger/fabric-gateway/releases/tag/v1.2.2

Bugs reports are submitted using GitHub issues, as described in the CONTRIBUTING guide: https://github.com/hyperledger/fabric-gateway/blob/main/CONTRIBUTING.md

The project uses GitHub issues to track bugs and associated pull requests that resolve them.

All issues are actively triaged, providing an appropriate combination of comments, issue tagging, and code changes.

All enhancement requests are actively triaged. Enhancements are either appropriately tagged (as backlog items to be addressed by community contribution), resolved by a code enhancement, or closed as not accepted with accompanying comments.

GitHub issues provide visibility of open and previously closed issues: https://github.com/hyperledger/fabric-gateway/issues

Security policy document is included in the repository's SECURITY.md file: https://github.com/hyperledger/fabric-gateway/security/policy

As described in the security policy, private vulnerability reports are made using the GitHub repository's security advisory page: https://github.com/hyperledger/fabric-gateway/security/advisories

No vulnerabilities reported.

Non-trivial build file in repository: https://github.com/hyperledger/fabric-gateway/blob/main/Makefile. GitHub Actions for build automation: https://github.com/hyperledger/fabric-gateway/actions

Non-trivial build file in repository: https://github.com/hyperledger/fabric-gateway/blob/main/Makefile.

All build tools are open source or freely available. Required tools are documented in the project README: https://github.com/hyperledger/fabric-gateway#readme

Complete unit and integration / scenario test suites are included in the repository source. Documentation on running tests is included in the project README: https://github.com/hyperledger/fabric-gateway#readme

All tests are invoked using a Makefile, and are executed using standard frameworks for their corresponding language. The test frameworks used are documented in the CONTRIBUTING guide: https://github.com/hyperledger/fabric-gateway/blob/main/CONTRIBUTING.md

Unit tests cover all functionality and have a very high level of branch coverage. Coverage data is collected on unit test runs. Scenario tests provide additional coverage of all key functionality in a real deployment environment.

A complete set of automated tests is run on all code submissions before they are accepted: https://github.com/hyperledger/fabric-gateway/actions/workflows/pull_request.yml The complete set of tests is run again on integration of code changes to ensure consistency: https://github.com/hyperledger/fabric-gateway/actions/workflows/push.yml Additionally, a scheduled build runs on the current repository state to ensure compatibility with external components: https://github.com/hyperledger/fabric-gateway/actions/workflows/schedule.yml

The CONTRIBUTING guide documents the requirement for all code submissions to have appropriate accompanying unit and scenario tests: https://github.com/hyperledger/fabric-gateway/blob/main/CONTRIBUTING.md This is enforced by project maintainers through the code review process.

For example: - https://github.com/hyperledger/fabric-gateway/pull/580 - https://github.com/hyperledger/fabric-gateway/pull/522

The CONTRIBUTING guide documents the requirement for all code submissions to have appropriate accompanying unit and scenario tests: https://github.com/hyperledger/fabric-gateway/blob/main/CONTRIBUTING.md

Several linting tools are used to check code correctness.

Go: staticcheck, errcheck, gocognit, gocyclo, gofmt, goheader, goimports, gosec, gosimple, govet, ineffassign, misspell, typecheck, unused. Node: ESLint Java: PMD

Compilers are set with strict options and warnings cause a build failure.

Warnings cause a build failure so code generating warnings fails pull request automated checks and cannot be merged.

Compilers are set with strict options and linters are used aggressively, requiring an explicit documented exception in the code to allow any failing check.

The project makes use of cryptographic signatures, and hashes required by those signatures, with the implementation being pluggable. Default signing implementations provided use ECDSA signatures with NIST-approved curves (P-256, P-384), and hashes (SHA-256, SHA-384, SHA3-256, SHA3-384).

The project does not implement these signature and hashing schemes but instead uses publicly published and audited implementations.

Go: Go standard crypto library. Node: @noble/curves (https://github.com/paulmillr/noble-curves) Java: Bouncy Castle (https://www.bouncycastle.org/java.html) and Java standard security framework.

The signing and hashing implementations are pluggable and therefore are selected (and can be provided) by the calling application code. The default signing implementation provided by this project uses ECDSA signatures with NIST-approved P-256 curve and SHA-256 hash.

The signing and hashing implementations are pluggable and therefore are selected (and can be provided) by the calling application code. The default signing implementation uses ECDSA signatures with NIST-approved P-256 curve and SHA-256 hash.

The default signing implementation uses ECDSA signatures with NIST-approved P-256 curve and SHA-256 hash.

The project makes use of gRPC connections configured and provided by the calling client application and is out of scope of this project. The key agreement protocol is dictated by the calling client application and the gRPC library capability. Typically this will be the latest TLS specification.

The software does not store or have any access to passwords.

Nonces are generated using standard secure cryptographic libraries:

Go: crypto/rand package from Go standard libraries Node: Node crypto package Java: java.security.SecureRandom from the standard Java library.

The software does not generate cryptographic keys.

Go code is released by tagging the Git repository, and is obtained by consumers using standard Go tools, which use Git and SSH.

Node code is released as an npm package in the global npm registry. This uses HTTPS to publish and retrieve packages. Additionally, an auth token is required for publishing.

Java code is released to the Maven Central repository. This uses HTTPS to publish and retrieve packages. Additionally, user credentials are required for publishing, and artifacts are signed with an approved GPG signature.

No vulnerabilities have been reported against the project itself. Dependencies are scanned daily for vulnerabilities and updates applied promptly as required: https://github.com/hyperledger/fabric-gateway/actions/workflows/vulnerability-scan.yml

No vulnerabilities have been reported.

Private credentials used by the build process are stored as build secrets in GitHub Actions. These can only be set by repository administrators and their contents cannot be viewed. The build logs are redacted to ensure secrets are secured.

Static analysis run on every code change and by scheduled builds.

Go: staticcheck, errcheck, gofmt, goimports, gosec, gosimple, govet, ineffassign, typecheck, unused, CodeQL. Node: eslint, CodeQL. Java: checkstyle, CodeQL.

gosec, CodeQL

No vulnerabilities discovered.

Most static analysis is carried out on every change, both before and after commit. CodeQL is run on a daily schedule.

Automated test suite with at least 80% branch coverage applied to every code change and on a schedule. Fuzzing is not (yet) carried out.

Go, TypeScript and Java.

No vulnerabilities discovered.