Enable multiple policies type #129

cendhu · 2025-09-08T10:54:32Z

Type of change

New feature

Description

This commit updates the proto messages to define policy using various rules such as threshold, signature, and hierarchical. Further, it integrates the signature rules with the verifier component.

Related issues

api/protoblocktx/block_tx.proto

liran-funaro · 2025-09-11T11:00:11Z

api/protoblocktx/block_tx.proto

+
+message Identity {
+  // The identifier of the associated membership service provider
+  string msp_id = 1;


minor: Is this field necessary? Can't we infer the MSP from the certificate's issuing CA?

This field is part of Fabric. It is included in the identity. Hence, I have replicated the same here.

I found only one reference to this field in utils/signature/verify.go:

idBytes, err := msp.NewSerializedIdentity(s.Identity.MspId, s.Identity.GetCertificate())

The question is, can we infer the MSP ID from s.Identity.GetCertificate()? Then pass it to NewSerializedIdentity().

We may infer the MSP ID from the Subject: CN=peer0.org1.example.com, OU=peer, O=Hyperledger, ST=North Carolina, C=US in the certificate. I will create an issue to check this later and use the Fabric way for now till we complete the whole feature.

Note that the endorser would fill this Identity field.

api/protoblocktx/block_tx.proto

service/sidecar/test_exports.go

api/protoblocktx/block_tx.proto

This commit updates the proto messages to define policy using various rules such as threshold, signature, and hierarchical. Signed-off-by: Senthil Nathan N <[email protected]> Signed-off-by: senthil <[email protected]>

Signed-off-by: senthil <[email protected]>

liran-funaro · 2025-10-28T09:28:57Z

api/protoblocktx/block_tx.proto

+
+  oneof creator {
+    // The full raw bytes of the creator's certificate (e.g., an X.509 certificate).
+    bytes certificate= 2;


super nit:

Suggested change

bytes certificate= 2;

bytes certificate = 2;

liran-funaro · 2025-10-28T09:43:47Z

api/protoblocktx/block_tx.proto

 message PolicyItem {
    string namespace = 1;
-    bytes policy = 2;
+    bytes policy = 2; // This holds the complete NamespacePolicy.


minor: Originally, I used bytes policy to allow support for other policies.
The solution in this PR adds PolicyType to the NamespacePolicy, making it generic.
So I think it is best to use NamespacePolicy as the type of policy in the PolicyItem.

liran-funaro · 2025-10-28T10:05:45Z

integration/test/config_update_test.go

 			ChannelID:                    c.SystemConfig.Policy.ChannelID,
 			OrdererEndpoints:             endpoints,
-			MetaNamespaceVerificationKey: metaPolicy.PublicKey,
+			MetaNamespaceVerificationKey: key.PublicKey,


What additional changes are needed to remove the need for the MetaNamespaceVerificationKey?

In the LifecycleEndorsementPolicy field of config block, we need to add policy type to accept either the threshold rule or signature rule. Currently, it supports only the signature rule. Then, we can remove this extra field.

liran-funaro · 2025-10-28T10:07:47Z

api/protoblocktx/block_tx.proto

 message NamespacePolicy {
-    string scheme = 1;    // The scheme for signature verification.
+    PolicyType type = 1;    // The type of policy used.
+    bytes policy = 2;       // The policy rule.


minor: Can we use here oneof as well? This will remove the need for double marshalling and unmarshalling.

liran-funaro · 2025-10-28T11:00:32Z

service/sidecar/test_exports.go

+		Namespaces:   validTxNamespaces,
+		Endorsements: make([]*protoblocktx.Endorsements, 2), // Too many signatures.


minor: The test should also address the "Not enough signatures" and "No signatures" test cases.
I suggest using a TX with two namespaces and only one signature for the "Not enough signatures".

I think we should check both use cases to ensure future implementations will not panic.

liran-funaro · 2025-10-29T12:19:28Z

utils/signature/verify.go

+// ThresholdVerifier verifies a digest.
+type ThresholdVerifier interface {
 	Verify(Digest, Signature) error
 }


I suggest using policies.Policy and amending the verifiers accordingly.

liran-funaro · 2025-10-29T12:22:17Z

service/coordinator/signature_verifier_manager.go

-					Namespaces: txNode.Tx.Namespaces,
-					Signatures: txNode.Signatures,
+					Namespaces:   txNode.Tx.Namespaces,
+					Endorsements: txNode.Signatures,


nit:

Suggested change

Endorsements: txNode.Signatures,

Endorsements: txNode.Endorsements,

liran-funaro · 2025-10-29T12:30:01Z

service/coordinator/dependencygraph/transaction_node.go

 	TransactionNode struct {
 		Tx         *protovcservice.Tx
-		Signatures [][]byte
+		Signatures []*protoblocktx.Endorsements


minor

Suggested change

Signatures []*protoblocktx.Endorsements

Endorsements []*protoblocktx.Endorsements

liran-funaro · 2025-10-29T12:34:52Z

utils/test/utils.go

+		set := &protoblocktx.Endorsements{
+			EndorsementsWithIdentity: []*protoblocktx.EndorsementWithIdentity{{Endorsement: sig}},
+		}
+		sets = append(sets, set)


nit: my personal preference is to avoid declaring variables that are only used once whenever possible.
But it is just a suggestion.

Suggested change

set := &protoblocktx.Endorsements{

EndorsementsWithIdentity: []*protoblocktx.EndorsementWithIdentity{{Endorsement: sig}},

}

sets = append(sets, set)

sets = append(sets, &protoblocktx.Endorsements{

EndorsementsWithIdentity: []*protoblocktx.EndorsementWithIdentity{{Endorsement: sig}},

})

liran-funaro · 2025-10-29T12:39:17Z

utils/test/utils.go

+// identity (MSP ID and certificate). This is used when a set of signatures
+// must all be present to satisfy a rule (e.g., an AND condition).
+func CreateEndorsementsForSignatureRule(signatures, mspIDs, certBytes [][]byte) *protoblocktx.Endorsements {
+	set := &protoblocktx.Endorsements{}


minor

Suggested change

set := &protoblocktx.Endorsements{}

set := &protoblocktx.Endorsements{

EndorsementsWithIdentity: make([]*protoblocktx.EndorsementWithIdentity, 0, len(signatures),

}

cendhu marked this pull request as draft September 8, 2025 10:59

cendhu force-pushed the integrate-bundle branch 9 times, most recently from 67d33d2 to 28bd138 Compare September 10, 2025 11:35

liran-funaro reviewed Sep 14, 2025

View reviewed changes

liran-funaro reviewed Sep 15, 2025

View reviewed changes

api/protoblocktx/block_tx.proto Outdated Show resolved Hide resolved

cendhu force-pushed the integrate-bundle branch 2 times, most recently from 7a06098 to c357994 Compare September 22, 2025 12:49

cendhu marked this pull request as ready for review September 29, 2025 06:18

cendhu force-pushed the integrate-bundle branch 3 times, most recently from c357994 to 3535672 Compare September 29, 2025 14:21

cendhu force-pushed the integrate-bundle branch from 3535672 to 29c6b17 Compare October 13, 2025 03:53

cendhu force-pushed the integrate-bundle branch from 29c6b17 to 4972f6b Compare October 22, 2025 09:35

cendhu added 2 commits October 27, 2025 18:44

Enable multiple policies type

009a287

This commit updates the proto messages to define policy using various rules such as threshold, signature, and hierarchical. Signed-off-by: Senthil Nathan N <[email protected]> Signed-off-by: senthil <[email protected]>

Address comments

e5d771f

Signed-off-by: senthil <[email protected]>

cendhu force-pushed the integrate-bundle branch from 4972f6b to e5d771f Compare October 28, 2025 06:54

cendhu requested a review from liran-funaro October 28, 2025 07:08

liran-funaro reviewed Oct 29, 2025

View reviewed changes

		Namespaces: validTxNamespaces,
		Endorsements: make([]*protoblocktx.Endorsements, 2), // Too many signatures.

	Endorsements: txNode.Signatures,
	Endorsements: txNode.Endorsements,

	Signatures []*protoblocktx.Endorsements
	Endorsements []*protoblocktx.Endorsements

Enable multiple policies type #129

Are you sure you want to change the base?

Enable multiple policies type #129

Uh oh!

Conversation

cendhu commented Sep 8, 2025

Type of change

Description

Related issues

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cendhu Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

cendhu Oct 29, 2025 •

edited

Loading