hyperledger/fabric-protos

fabric-protos's Issues

Publish API docs

Currently the Fabric protobuf API can only be explored through the individual .proto files. It would be useful to publish a navigable API doc via GitHub pages.

Additionally, with the new language bindings being created for #72, it would also be helpful to publish the javadoc and tsdoc API documentation.

Publish bindings for additional languages

Currently Go bindings are published to fabric-protos-go but there is no real equivalent for Java or other languages. This has led to some less than ideal build processes for code which depends on the Fabric protos, typically involving copying proto files around.

This issue is based on a request from @C0rWin:

Recently, I've been working with Java-based applications using Fabric. I've noted that proto files have not been updated for Java SDK and Java shim for more than two years. So I want to suggest creating a first level repo, similarly to how it was done for go, e.g. fabric-protos-go. That's to have protos compiled in the fabric-protos repo and pushed into fabric-protos-java when it could be published into Maven central.

This way, we will remove hardcoded dependency on proto files, which are currently duplicated in shim and SDK and introduce artefacts that will keep java protos updated.

Move npm module to esm and drop node < 20

Migrate fabric-protos Go apiv1 builds to GitHub Actions

The original apiv1 Go builds still run with azure devops using the old build process

It would be good to move them over to work the same way as the Go apiv2 builds

Update builds to include release-2.4 and release-2.5 branches

The new GHA build currently only works with the main branch and v0.3.x

It also needs to run on the release-2.4 and release-2.5 branches, with the correct version for each

This will probably require a bit of thought about publishing Go bindings to fabric-protos-go and fabric-protos-go-apiv2 correctly

Create a MAINTAINERS.md file

Example: https://github.com/hyperledger-labs/solang/blob/main/MAINTAINERS.md Example of a pointer: https://github.com/hyperledger-labs/homebrew-solang/blob/main/MAINTAINERS.md

Document approach to versioning and breaking changes

It would be useful to agree how the APIs in this repo should be managed in terms of versioning and breaking changes.

Until recently there wasn't really any version involved and it was left as an exercise for the reader how to manage which proto definitions to use, resulting a range of approaches. Even for Go, where there was a pre-generated go bindings repository, a v0 pseudo-version number was used, with no protection against breaking changes.

With the recent introduction of pre-generated Java and Node bindings, a version number is required. So far this has been a pre-release v0 version to get the new CI pipelines working, which also include breaking change detection.

My assumption is that we should be avoiding breaking changes, which would make a simple v1 Go module version numbering system possible for all generated bindings.

There may be situations that genuinely require breaking changes, however these should be rare and involve serious thought about whether it is absolutely necessary. Should a breaking change be necessary, we would need to consider how the versioning system would handle the change. For example, Google's approach is that package names for versioned APIs must end with the version, and adding a version suffix to the generated Go module is one possible way to handle the Go module version numbering system.

Update breaking change detection to check against previous release

The current breaking change detection runs against the main branch, which is probably too strict. Everything should be fine as long as there are no breaking changes between tagged releases.

Note: what constitutes the previous release will depend on the branch.

add csharp_namespace option

[nodebinding] missing FromOject alternative

I want a way to transform a javascript object(or json) to a protobuf binary without set attribute mannually to align schema.
We have found a simple way to do so when using fabric-protos, which depended on protobufjs

typeObject.encode(JSObject).finish()

where the typeObject is the type constructor or type itself such as gateway.EvaluateRequest

Now I wonder if we can have similar clean solution now in @hyperledger/fabric-protos.

GitHub publish to apiv2 repo failing

Looks like the publish step has been failing for a while:

Run ../build/.github/scripts/installDeployKey.sh fabric-protos-go-apiv2 ***
base64: invalid input
# github.com:22 SSH-2.0-babeld-3f0fc[8](https://github.com/hyperledger/fabric-protos/actions/runs/3190978756/jobs/5206756644#step:9:9)3a
# github.com:22 SSH-2.0-babeld-3f0fc83a
# github.com:22 SSH-2.0-babeld-3f0fc83a
# github.com:22 SSH-2.0-babeld-3f0fc83a
# github.com:22 SSH-2.0-babeld-3f0fc83a
remote: Permission to hyperledger/fabric-protos-go-apiv2.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/hyperledger/fabric-protos-go-apiv2.git/': The requested URL returned error: 403
Error: Process completed with exit code [12](https://github.com/hyperledger/fabric-protos/actions/runs/3190978756/jobs/5206756644#step:9:13)8.

[go binding] peer.TransactionAction#Header

// TransactionAction binds a proposal to its action.  The type field in the header dictates the type of action to be applied to the ledger.
type TransactionAction struct {
	// The header of the proposal action, which is the proposal header
	Header []byte `protobuf:"bytes,1,opt,name=header,proto3" json:"header,omitempty"`
	// The payload of the action as defined by the type in the header For
	// chaincode, it's the bytes of ChaincodeActionPayload
	Payload              []byte   `protobuf:"bytes,2,opt,name=payload,proto3" json:"payload,omitempty"`
	...
}

As documented, the header should be of the proposal header type, which I cannot find which is the type it refers to.

Request for Guidance: Regenerating common.pb.go for Hyperledger Fabric v2.2

Hello,

I am currently attempting to regenerate the common.pb.go file for Hyperledger Fabric v2.2 and have a few queries regarding the process.

Firstly, I'd like to know which branch of the repository I should be using for this task. According to the documentation, it appears that even the v0.1.x branch is for v2.4 releases. Can you please clarify which branch should be used for v2.2?

Secondly, as per my understanding, the process should involve compiling the common/common.proto file. However, I am unsure about the exact steps to take in this regard. Could you please provide a detailed guide or the specific commands that I should use to properly compile this file?

I would appreciate your assistance in helping me navigate this process. Thank you in advance for your time and support.

Best regards,

Add support for PurgePrivateData [Fabric epic #3020]

Updating to include the new PurgePrivateData API.

• add a new field to the shim
• add new message for the properties of this API

Fabric Issue

Clarify discrepancies between code and package documentation regarding Epoch system

Comment regarding ChannelHeader structure inside common/common.proto implies that the Epoch system is already implemented
This comment is later used as part of the package's documentation:
https://hyperledger.github.io/fabric-protos/protos.html#common-ChannelHeader and https://pkg.go.dev/github.com/hyperledger/fabric-protos-go/common#ChannelHeader.
However, go SDK sets the Epoch to a hard coded value of 0 and contains TODO markers, e.g. in this file: https://github.com/hyperledger/fabric-sdk-go/blob/main/internal/github.com/hyperledger/fabric/protoutil/proputils.go.
This can be quite misleading and at least a warning in the documentation would be appreciated.

Update go package names to hyperledger/fabric-protos-go-apiv2

I believe https://github.com/hyperledger/fabric-protos-go is deprecated, and https://github.com/hyperledger/fabric-protos-go-apiv2 is the latest fabric-protos-go package.
Hence this needs to be updated in all .proto definitions as:

option go_package = "github.com/hyperledger/fabric-protos-go-apiv2";

This is so that if some other's project's .proto depends upon fabric-protos, then on compiling it created dependency to deprecated version i.e. github.com/hyperledger/fabric-protos-go, which then later on create conflicts with go applications depending on this proto and fabric-protos.
I'm a maintainer/co-owner of Hyperledger/Cacti, where we are facing this issue.

I've a bash script to do this (which is what I'm using for workaround), if you are okay with it, I can create PR for this.

script:

Script

#!/bin/bash
ROOT_DIR=${1:-'..'}
pushd $ROOT_DIR

files=$(find ./fabric-protos -name *.proto)
for filename in $files

do

sed -i'.scriptbak' -e ' s#^option go_package = "github.com/hyperledger/fabric-protos-go/#option go_package = "github.com/hyperledger/fabric-protos-go-apiv2/#' "$filename"

rm -rf $filename.scriptbak

cat $filename | grep "option go_package"

done

popd $ROOT_DIR

How to convert proto encoded buffer using new protobuf library "google.golang.org/protobuf"

Hi team,

We use proto from the protobuf lib in our Golang chain codes to unmarshal the "stub.GetCreator()" result. First, we create an instance of the Serailizedidentity from "github.com/hyperledger/fabric-protos-go/msp" to hold the Unmarshall result from "stub.GetCreator()" and then unmarshall it using proto.

creator, err := stub.GetCreator()
if err != nil {
    return nil, err
}
    //Create a SerializedIdentity to hold Unmarshal GetCreator() result
sId := &msp.SerializedIdentity{}
//Unmarshal the creator from []byte to structure
err := proto.Unmarshal(creator, sId)
if err != nil {
    return nil, err
}

Our product is enterprise edition, and we are not permitted by our company to use deprecated packages. So I tried to use the new protobuf, which is not deprecated and is recommended by the protobuf team, i.e. "google.golang.org/protobuf."
I am getting the following error:

"cannot use sId (variable of type msp.SerializedIdentity) as protoreflect.ProtoMessage value in argument to proto.Unmarshal:msp.SerializedIdentity does not implement protoreflect.ProtoMessage (missing method ProtoReflect)compilerInvalidIfaceAssign
var sId *msp.SerializedIdentity"

I believe the old "protoc" written by "github.com/golang/protobuf" is used to generate the go code for proto files i.e "identities.pb.go" file. We are unable to unmarshall the serailize data from "stub.Creator()" to msp.SerailizeIdentity using the most recent protobuf "google.golang.org/protobuf/proto" due to "identities.pb.go" file generated using protoc of a deprecated version. Is there any way to use the new protobuf "google.golang.org/protobuf" lib to unmarshal the serialised data from "stub.Creator()" using fabric-protos-go/msp, or is there any plan to update fabric-protos-go in the future so that identities.pb.go generated by "google.golang.org/protobuf"?

Add nightly security vulnerability scans

See the fabric-gateway vulnerability-scan.yml workflow for example

Inconsistent Casing For TransientMap in ChaincodeProposalPayload

It would appear the convention is to utilize snake casing for message field names and CamelCasing for the message name or the type. In peer/proposal.proto, that convention is broken with TransientMap.

fabric-protos/peer/proposal.proto

Line 228 in 318e632

map<string, bytes> TransientMap = 2;

I realize this may be impossible to fix at this point with how many SDKs and clients that have hardcoded this field name, but here's to hoping it can get fixed in a v2. :)

Fix build deprecation warning

The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

main, 0.2.x and 0.1.x branches all use the same tags when publishing NPM packages

The source branch for the version of the @hyperledger/fabric-protos package tagged latest varies depending on which branch had a release created last. This causes potential confusion and/or failures for users who do not specify a specific version (or version range) when installing this NPM package. By default the version tagged latest is installed, and this may or may not match the latest supported version of Fabric.

Suggest using:

• next and next-unstable tags for releases and pushed commits to the main branch - corresponding to Fabric v3 (beta).
• latest and unstable tags for the 0.2.x branch - corresponding to Fabric v2.5 LTS.
• v1 and v1-unstable tags for the 0.1.x branch - corresponding to Fabric v1.4.

Publish compiled output using v2 Go protobuf API

As a Fabric application developer
I want fabric-protos-go to include stubs compiled for the v2 Go API for protocol buffers
So that we can take advantage of new features in v2 protobuf API within our consuming application

See https://go.dev/blog/protobuf-apiv2 for details.

This could be achieved by continuing to publish the protobufs compiled using the v1 Go API for protocol buffers at the top level of the fabric-protos-go repository, and publishing the equivalent stubs using the v2 API in a v2 sub-directory within that repository, as per the Go module publishing guidance. This would allow consumers to migrate to the newer protobuf APIs while maintaining complete compatibility for existing consumers.

An alternative (and perhaps better) approach would be to publish to a different publishing reposity, such as hyperledger/fabric-protos-go-apiv2. This would avoid any confusion about the module versioning. This wouldn't really be a v2 of the fabric-protos-go module, just an alternative implementation backed by the v2 Go API for protocol buffers.