Re: Endorsement Policy Failure


Yacov
 

why are you using "admin" roles in an endorsement policy? Peers cannot be admins.



From:        "Tomás Peixinho" <tom.peixinho@...>
To:        Yacov Manevich <YACOVM@...>, "hyperledger-fabric@..." <hyperledger-fabric@...>
Date:        03/12/2020 12:06 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Endorsement Policy Failure
Sent by:        fabric@...




Good evening,

a while back I asked about the endorsement policies, and after I tried to mess with them a bit, I've reached a dead end. My chaincode and application are now complete, so I finally decided to change the endorsement policy (if I don't define it, the default is "Any peer", and this would be very insecure). As a simple starting point, I was trying to have at least one peer from each org to endorse the transactions (my network has 3 orgs), so I defined the policy file as follows:

# A Shotgun policy xx
identities:  # list roles to be used in the policy
    user1: {"role": {"name": "peer", "mspId": "Org1MSP"}} # role member in org with mspid Org1MSP
    user2: {"role": {"name": "peer", "mspId": "Org2MSP"}}
    user3: {"role": {"name": "peer", "mspId": "Org3MSP"}}
    admin1: {"role": {"name": "admin", "mspId": "Org1MSP"}} # admin role.
    admin2: {"role": {"name": "admin", "mspId": "Org2MSP"}}
    admin3: {"role": {"name": "admin", "mspId": "Org3MSP"}}

policy: # the policy  .. could have been flat but show grouping.
    3-of: # signed by one of these groups  can be <n>-of  where <n> is any digit 2-of, 3-of etc..
      - 1-of:
        - signed-by: "user1" # a reference to one of the identities defined above.
        - signed-by: "admin1"
      - 1-of:
        - signed-by: "user2"
        - signed-by: "admin2"
      - 1-of:
        - signed-by: "user3"
        - signed-by: "admin3"

I used the example file that came with the java sdk (chaincodeendorsementpolicy.yaml) and updated it to do what I wanted. However, no matter what I define in this file, the policy check always fails with this message:

2020-03-11 19:22:29.527 UTC [vscc] Validate -> WARN 05a Endorsement policy failure for transaction txid=3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] validateTx -> ERRO 05b VSCCValidateTx for transaction txId = 3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2020-03-11 19:22:29.527 UTC [committer.txvalidator] Validate -> INFO 05c [mychannel] Validated block [2] in 4ms
2020-03-11 19:22:29.527 UTC [valimpl] preprocessProtoBlock -> WARN 05d Channel [mychannel]: Block [2] Transaction index [0] TxId [3d4051db0b3be08ae6205831f326d1e1d42e79ea97e6b89c57bcb163bd80ffaa] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

I thought I might have been doing something wrong with the syntax of the file, but if I change the "3-of" to "0-of", it works, so I guess that's not it. I also thought it could have been because the peers were unable to find each other, so I manually defined the anchor peers for each organization on the configtx.yaml (the port I defined for all of them was the 7051, which was the default port for the peer0-org1, not sure if this is correct or not), and I also defined the fields CORE_PEER_GOSSIP_BOOTSTRAP and CORE_PEER_GOSSIP_EXTERNALENDPOINT for each peer on the docker-compose.yml (the file which defines the network topology), but I'm also not sure of what I should define them with, so I put the "bootstrap" with the address of the anchor peer of the org, and the "external endpoint" with the same address as the peer on which I'm defining it. This final alteration was because I was getting a warning saying that since the external endpoint wasn't defined, peers were unable to see each other and I thought that might have something to do with it (if they couldn't find peers from different orgs, these weren't able to endorse the transactions and the verification would fail, just a theory).

Not sure if any of this makes sense, but since it's not working, I'm gonna go ahead and assume it doesn't. Or maybe my problem isn't even related to any of this, but in that case, I really don't know what I'm missing or doing wrong. Any help would be greatly appreciated. If I'm going about this all wrong, my purpose here was just to define my own endorsement policy, in order to make the blockchain more secure (as per Yacov's recommendation), so if someone can enlighten me on the subject, I thank you in avance.

Cheers

Tomás




Join fabric@lists.hyperledger.org to automatically receive all group messages.