Date   

Re: Is there a way to block chaincode access for SDK? #fabric-chaincode

Yacov
 

Each chaincode corresponds to a different namespace, and has a different endorsement policy.
Software engineering idioms such as "separation of business logic from tech logic" should never be a reason to separate one chaincode into several chaincodes.

That being said, you can actually prevent users from invoking certain chaincodes by writing and deploying your own authentication filter in the peer.
Take a look at https://github.com/hyperledger/fabric/blob/release-1.4/sampleconfig/core.yaml#L360-L374and at a built in filter we have for blocking expired client certificates in https://github.com/hyperledger/fabric/blob/release-1.4/core/handlers/auth/filter/expiration.go.

Basically you need to extract the target chaincode name from the signed proposal and return an error if it doesn't fit your whitelist.



From:        "Prasanth Sundaravelu" <prasanths96@...>
To:        fabric@...
Date:        12/02/2019 11:11 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Is there a way to block chaincode access for SDK? #fabric-chaincode
Sent by:        fabric@...




Hi Guys,

I've been trying to separate one big chaincode into multiple chaincodes and also for separating business logic from tech logic.

Here, the tech logic service (eg: EncryptAndSaveState) needs to be accessed by multiple other chaincodes.

I have separated code into different chaincodes and instantiated in same single channel.

The problem is, if I want to use one chaincode's service from another, I have to expose the functions in chaincode from Invoke / Query functions, so that I can use stub.InvokeChaincode() to call these services. But, if I expose these functions (eg: EncryptAndSaveState), it will be accessible by SDK aswell. I don't want the tech services chaincode to be accessed via SDK.

Is there a way to identify if request is coming from chaincode (stub.InvokeChaincode()) or from SDK?
or,
Is there a way to set configuration at peer, to not let request coming from SDK access certain chaincodes by name?

I've tried to do workaround for this by generating and storing a map of TxID and Random-Number at calling chaincode and attached this random number with the Invocation. When the called chaincode receives the Invoke, it again queries back to the calling chaincode (using stub.InvokeChaincode() again) to verify if this random number is infact generated by that chaincode. But, the last Invoke (verification) did not work, it threw: GRPC client failed to get a proper response from the peer \"grpcs://localhost:8051\"."

I would also like to know why this does not work.

Would really appreciate any clue.





Re: Proposal : Hyperledger Fabric block archiving

Manish
 

Hi Atsushi,

My response in blue in-lined text…

Thanks,
Manish

On Mon, Dec 2, 2019 at 4:10 PM Manish Sethi <manish.sethi@...> wrote:


On Fri, Nov 29, 2019 at 12:44 AM nekia <atsushin@...> wrote:
Thanks, Manish, Yacov, and Gari.
 
 
I really appreciate for your feedback and insights.
 
(Feedback from Manish)
First, the fundamental assumption that you make is that all the block files are same across peers is incorrect. The block files are not guaranteed to contain same number of blocks across peers. This is because a block file is bounded by the file size and not by the  number of blocks. Further, the size of a given block may vary slightly on each peer. Though the header and the data section of a blocks are of same size across peers but this difference in overall size could be caused by the metadata section which contains concenter signatures. ...
Thank you so much for a quite important point. We're now reviewing and analyzing the implementation of fabric around metadata. Let me ask a question to clarify my understanding.
Say for example, block #100 is available on channel 'mychannel' within organization 'org1', does it mean that the metadata of block #100 on peer0.org1 can be different to the metadata of same block(#100) on a different peer(ex. peer1.org1)? If yes, you are right that our assumption is incorrect. That is, our feature will not be able to refer to a block data (from any peer node) which resides on the archive repository. Because locPointer (offset and length of each block within a blockfile) is not available for archived blockfiles on the repository.

Yes, that is the case I was highlighting…
Second, there are certain kind of queries for which a peer assumes the presence of block files in the current way. This primarily includes history queries, blocks related queries, and txid related queries. These queries may start failing or lead to crashes or unexpected results if you simply delete the files. ...
Third, somewhat similar to the second point above, peer has a feature wherein it rebuilds the statedb and historydb if they are dropped and peer is simply restarted. For this feature as well it relies on the percense of blockfiles.
We have catered for these situations. Each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface. Even after archiving blockfiles, blockchain characteristics are still maintained on the Blockchain network. So rebuilding statedb and accessing historydb are still available under this archiving feature.
Note: Hyperledger Fabric core has been modified to handle query failures when it attempts to access deleted blockfiles.

 I see now. This important detail was not covered in the proposal and hence I was under impression that you are not modifying the core fabric code. Given, the first point above, this would cause more changes in the peer core.
Fourth, I am not sure if gossip is the right communication mechanism that you want to employ for this communication. An archiver client perhaps can simply poll (or register for updates with) the archiver repository.
In early stage in our development, we used a polling mechanism to trigger archiving. But in terms of the efficiency (process and network traffic), we changed the implementation to be event driven.
 
 As I mentioned previously, it can still be event driven (event from archiver repo). My main point was point-to-point communication vs gossip.
Finally, I would like to understand in more details what are the benefits of having a separate repository? Why not simply let the files be there on the anchor peer and purge from other peers? If the answer is compression, then ideally we should explore a choise of writing the data in blockfiles in compressed format.
Good point. We designed this archiving feature to be as simple as possible (that is, minimal code changes to Hyperledger Fabric core). With the repository concept, we're able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
     All I wanted to say here is that, it would be good if someone wants one of the peers file to act as a repo as well…. in other words, it still has all what a repo offers and code will be outside core peer code anyways. But this is less important point as compared to others, I guess.
 
  
(Feedbacks from Yacov)
one thing I noticed while skimming the code, is that while you send the ArchivedBlockFileMsg via gossip, you are not ensuring it is eventually propagated to peers successfully.
 
This means that if a peer didn't get the message, it won't archive your file.
 
I suggest that you think of a more robust mechanism, like periodically comparing digests of ranges.
You're right. This kind of logic is lacking from our current implementation. Actually it was in our radar, but we have difficulty to implement this aspect. Thank you for pointing to a reference code for pull-based gossip.
 
(Feedbacks from Gari)
It seems the only thing you really wanted to use the peer for was to propagate information to other peers within the same organization. ...
Yes, that is one of the reasons we integrated archiving features into peer binary. But the most important reason is for handling query failures when it attempts to access deleted blockfiles. And each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
 
 
Thanks,
Atsushi
 


Is there a way to block chaincode access for SDK? #fabric-chaincode

Prasanth Sundaravelu
 

Hi Guys,

I've been trying to separate one big chaincode into multiple chaincodes and also for separating business logic from tech logic.

Here, the tech logic service (eg: EncryptAndSaveState) needs to be accessed by multiple other chaincodes. 

I have separated code into different chaincodes and instantiated in same single channel. 

The problem is, if I want to use one chaincode's service from another, I have to expose the functions in chaincode from Invoke / Query functions, so that I can use stub.InvokeChaincode() to call these services. But, if I expose these functions (eg: EncryptAndSaveState), it will be accessible by SDK aswell. I don't want the tech services chaincode to be accessed via SDK. 

Is there a way to identify if request is coming from chaincode (stub.InvokeChaincode()) or from SDK? 
or,
Is there a way to set configuration at peer, to not let request coming from SDK access certain chaincodes by name?

I've tried to do workaround for this by generating and storing a map of TxID and Random-Number at calling chaincode and attached this random number with the Invocation. When the called chaincode receives the Invoke, it again queries back to the calling chaincode (using stub.InvokeChaincode() again) to verify if this random number is infact generated by that chaincode. But, the last Invoke (verification) did not work, it threw: GRPC client failed to get a proper response from the peer \"grpcs://localhost:8051\"."

I would also like to know why this does not work.

Would really appreciate any clue.


Re: Proposal : Hyperledger Fabric block archiving

Manish
 



On Fri, Nov 29, 2019 at 12:44 AM nekia <atsushin@...> wrote:
Thanks, Manish, Yacov, and Gari.
 
 
I really appreciate for your feedback and insights.
 
(Feedback from Manish)
First, the fundamental assumption that you make is that all the block files are same across peers is incorrect. The block files are not guaranteed to contain same number of blocks across peers. This is because a block file is bounded by the file size and not by the  number of blocks. Further, the size of a given block may vary slightly on each peer. Though the header and the data section of a blocks are of same size across peers but this difference in overall size could be caused by the metadata section which contains concenter signatures. ...
Thank you so much for a quite important point. We're now reviewing and analyzing the implementation of fabric around metadata. Let me ask a question to clarify my understanding.
Say for example, block #100 is available on channel 'mychannel' within organization 'org1', does it mean that the metadata of block #100 on peer0.org1 can be different to the metadata of same block(#100) on a different peer(ex. peer1.org1)? If yes, you are right that our assumption is incorrect. That is, our feature will not be able to refer to a block data (from any peer node) which resides on the archive repository. Because locPointer (offset and length of each block within a blockfile) is not available for archived blockfiles on the repository.

Yes, that is the case I was highlighting…
Second, there are certain kind of queries for which a peer assumes the presence of block files in the current way. This primarily includes history queries, blocks related queries, and txid related queries. These queries may start failing or lead to crashes or unexpected results if you simply delete the files. ...
Third, somewhat similar to the second point above, peer has a feature wherein it rebuilds the statedb and historydb if they are dropped and peer is simply restarted. For this feature as well it relies on the percense of blockfiles.
We have catered for these situations. Each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface. Even after archiving blockfiles, blockchain characteristics are still maintained on the Blockchain network. So rebuilding statedb and accessing historydb are still available under this archiving feature.
Note: Hyperledger Fabric core has been modified to handle query failures when it attempts to access deleted blockfiles.

 I see now. This important detail was not covered in the proposal and hence I was under impression that you are not modifying the core fabric code. Given, the first point above, this would cause more changes in the peer core.
Fourth, I am not sure if gossip is the right communication mechanism that you want to employ for this communication. An archiver client perhaps can simply poll (or register for updates with) the archiver repository.
In early stage in our development, we used a polling mechanism to trigger archiving. But in terms of the efficiency (process and network traffic), we changed the implementation to be event driven.
 
 As I mentioned previously, it can still be event driven (event from archiver repo). My main point was point-to-point communication vs gossip.
Finally, I would like to understand in more details what are the benefits of having a separate repository? Why not simply let the files be there on the anchor peer and purge from other peers? If the answer is compression, then ideally we should explore a choise of writing the data in blockfiles in compressed format.
Good point. We designed this archiving feature to be as simple as possible (that is, minimal code changes to Hyperledger Fabric core). With the repository concept, we're able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
     All I wanted to say here is that, it would be good if someone wants one of the peers file to act as a repo as well…. in other words, it still has all what a repo offers and code will be outside core peer code anyways. But this is less important point as compared to others, I guess.
 
  
(Feedbacks from Yacov)
one thing I noticed while skimming the code, is that while you send the ArchivedBlockFileMsg via gossip, you are not ensuring it is eventually propagated to peers successfully.
 
This means that if a peer didn't get the message, it won't archive your file.
 
I suggest that you think of a more robust mechanism, like periodically comparing digests of ranges.
You're right. This kind of logic is lacking from our current implementation. Actually it was in our radar, but we have difficulty to implement this aspect. Thank you for pointing to a reference code for pull-based gossip.
 
(Feedbacks from Gari)
It seems the only thing you really wanted to use the peer for was to propagate information to other peers within the same organization. ...
Yes, that is one of the reasons we integrated archiving features into peer binary. But the most important reason is for handling query failures when it attempts to access deleted blockfiles. And each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
 
 
Thanks,
Atsushi
 


Re: problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

Siddharth Jain
 

below is our truncated logs

2019-12-02 09:42:46.771 PST [policies] Evaluate -> DEBU 4d3 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Application/ChannelCreationPolicy ==
2019-12-02 09:44:32.662 PST [policies] Evaluate -> DEBU 4ef Signature set satisfies policy /Channel/Application/Org1/Admins

2019-12-02 09:45:03.088 PST [policies] Evaluate -> DEBU 511 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Writers ==
2019-12-02 09:45:34.699 PST [policies] Evaluate -> DEBU 513 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Writers ==
2019-12-02 09:46:26.038 PST [policies] Evaluate -> DEBU 515 == Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdOrg/Writers ==
2019-12-02 09:46:26.039 PST [msp] satisfiesPrincipalInternalV143 -> DEBU 51b Checking if identity has been named explicitly as an admin for OrdOrgMSP
2019-12-02 09:46:26.039 PST [msp] satisfiesPrincipalInternalV143 -> DEBU 51c Checking if identity carries the admin ou for OrdOrgMSP
2019-12-02 09:46:26.040 PST [msp] hasOURole -> DEBU 51f MSP OrdOrgMSP checking if the identity is a client
2019-12-02 09:46:26.040 PST [cauthdsl] func2 -> DEBU 521 0xc0005f9180 identity 0 does not satisfy principal: The identity is not an admin under this MSP [OrdOrgMSP]: The identity does not contain OU [ADMIN], MSP: [OrdOrgMSP]
2019-12-02 09:46:26.040 PST [cauthdsl] func2 -> DEBU 522 0xc0005f9180 principal evaluation fails
2019-12-02 09:46:26.040 PST [msp] satisfiesPrincipalInternalPreV13 -> DEBU 525 Checking if identity satisfies role [CLIENT] for OrdOrgMSP
2019-12-02 09:46:26.042 PST [cauthdsl] func2 -> DEBU 52a 0xc0005f9180 identity 0 does not satisfy principal: The identity is not a [CLIENT] under this MSP [OrdOrgMSP]: The identity does not contain OU [CLIENT], MSP: [OrdOrgMSP]
2019-12-02 09:46:26.042 PST [policies] Evaluate -> DEBU 52d Signature set did not satisfy policy /Channel/Orderer/OrdOrg/Writers
2019-12-02 09:48:07.333 PST [policies] func1 -> DEBU 52f Evaluation Failed: Only 0 policies were satisfied, but needed 1 of [ OrdOrg/Writers ]
2019-12-02 09:48:07.333 PST [policies] Evaluate -> DEBU 533 Signature set did not satisfy policy /Channel/Orderer/Writers

it is true that in configtx.yaml we have defined

Policies: &OrdPolicies
            Readers:
                Type: Signature                
                Rule: "OR('OrdOrgMSP.admin', 'OrdOrgMSP.orderer', 'OrdOrgMSP.client')"
               
            Writers:
                Type: Signature
                Rule: "OR('OrdOrgMSP.admin', 'OrdOrgMSP.client')"
               
            Admins:
                Type: Signature
                Rule: "OR('OrdOrgMSP.admin')"

and we are calling channel create as admin of Org1 but we used the same pattern as in https://github.com/hyperledger/fabric-samples/blob/release-1.4/first-network/configtx.yaml

Policies:
            Readers:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"
            Writers:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"
            Admins:
                Type: Signature
                Rule: "OR('OrdererMSP.admin')"

so what gives?


From: Nikhil E Gupta <negupta@...>
Sent: Monday, December 2, 2019 6:00 AM
To: Siddharth Jain <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies
 
Hi Siddharth,

This error is caused by a certificate problem. You can investigate further by checking your orderer logs.

This stack overflow post: https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails/57662645#57662645 has a good overview of what to look for when you check your orderer logs.

Nik



-----fabric@... wrote: -----
To: "fabric@..." <fabric@...>
From: "Siddharth Jain"
Sent by: fabric@...
Date: 11/30/2019 06:32PM
Subject: [EXTERNAL] [Hyperledger Fabric] problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

we get the error below when trying to create a channel using the peer CLI
2019-11-30 20:53:15.482 UTC [orderer.common.broadcast] ProcessMessage -> WARN 00c [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51816 because of error: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
  • we have a 3 org network (plus orderer)
  • we are using NodeOUs
  • our configtx.yaml can be found at https://gist.github.com/siddjain/4cefde4321185c81a663f877fd6b105e
  • we are running the CLI under credentials of an admin user of one of the peer organizations
  • we checked the public cert and it has OU=admin on it. it was generated using cryptogen 1.4.4
how can we fix this? what is the cause?

fwiw, in case it helps, if we try to create the channel using credentials of admin of the orderer org we get a different error

2019-11-30 20:30:53.025 UTC [orderer.common.broadcast] ProcessMessage -> WARN 008 [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51808 because of error: error validating channel creation transaction for new channel 'tracktrace', could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group]  /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied



Re: problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

Nikhil Gupta
 

Hi Siddharth,

This error is caused by a certificate problem. You can investigate further by checking your orderer logs.

This stack overflow post: https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails/57662645#57662645 has a good overview of what to look for when you check your orderer logs.

Nik



-----fabric@... wrote: -----
To: "fabric@..." <fabric@...>
From: "Siddharth Jain"
Sent by: fabric@...
Date: 11/30/2019 06:32PM
Subject: [EXTERNAL] [Hyperledger Fabric] problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

we get the error below when trying to create a channel using the peer CLI
2019-11-30 20:53:15.482 UTC [orderer.common.broadcast] ProcessMessage -> WARN 00c [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51816 because of error: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
  • we have a 3 org network (plus orderer)
  • we are using NodeOUs
  • our configtx.yaml can be found at https://gist.github.com/siddjain/4cefde4321185c81a663f877fd6b105e
  • we are running the CLI under credentials of an admin user of one of the peer organizations
  • we checked the public cert and it has OU=admin on it. it was generated using cryptogen 1.4.4
how can we fix this? what is the cause?

fwiw, in case it helps, if we try to create the channel using credentials of admin of the orderer org we get a different error

2019-11-30 20:30:53.025 UTC [orderer.common.broadcast] ProcessMessage -> WARN 008 [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51808 because of error: error validating channel creation transaction for new channel 'tracktrace', could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group]  /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied



Re: fabric node sdk vs java sdk

Ross Tang <tangross@...>
 

I don’t have definite answer, like side by side comparison. But I am working very fine with node sdk, especially when my middle tier application, and front end app are (everything in Typescript). I create a single Typescript monrepo, for every stack/components, including chaincode. It is end-to-end typing, and I am using Jest for unit and integration for web, api gateway, middleware, and chaincode. Also easy with DevOps. 


On 2 Dec 2019, at 4:48 PM, Medha Kamalakar <medha_Kamalakar@...> wrote:

Hello,
 
Are there any recommendations around which fabric sdk should be used(node sdk vs java sdk) for various hyperledger fabric blockchain use cases.
Are there any guidelines for choice of SDK and has any comparative analysis been done for this?(Criteria could be performance, feature list, support available etc..)
 
 
Thanks and Regards,
Medha.
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.


Re: fabric node sdk vs java sdk

Matthew White
 

Hello - both SDKs have the updated programming model. Both have the same features, and able to support the same Fabric use-cases.
 
It's possibly more important to consider the development environment, skills, and other libraries you want to use - let that be a guide to the choice of development language and pick the SDK to match
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Medha Kamalakar" <medha_Kamalakar@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] fabric node sdk vs java sdk
Date: Mon, Dec 2, 2019 8:48 AM
 

Hello,

 

Are there any recommendations around which fabric sdk should be used(node sdk vs java sdk) for various hyperledger fabric blockchain use cases.

Are there any guidelines for choice of SDK and has any comparative analysis been done for this?(Criteria could be performance, feature list, support available etc..)

 

 

Thanks and Regards,

Medha.

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


fabric node sdk vs java sdk

Medha Kamalakar <medha_Kamalakar@...>
 

Hello,

 

Are there any recommendations around which fabric sdk should be used(node sdk vs java sdk) for various hyperledger fabric blockchain use cases.

Are there any guidelines for choice of SDK and has any comparative analysis been done for this?(Criteria could be performance, feature list, support available etc..)

 

 

Thanks and Regards,

Medha.

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.


Query on fabric NodeJS versioning #fabric-sdk-node

shrugupt@...
 

Hi All,

Is there any recommendation for fabric Node JS SDK version to be used for a specific fabric version running on the network peer/orderer/ca nodes. 

For example, if my fabric network is running on vesion 1.4.1 then which version of fabric Node JS SDK is recommended to use? How can get this information on nodeJS SDK compatible version for each fabric version?

Thanks in advance!

Regards,
Shruti Gupta


problem creating channel: 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies

Siddharth Jain
 

we get the error below when trying to create a channel using the peer CLI
2019-11-30 20:53:15.482 UTC [orderer.common.broadcast] ProcessMessage -> WARN 00c [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51816 because of error: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
  • we have a 3 org network (plus orderer)
  • we are using NodeOUs
  • our configtx.yaml can be found at https://gist.github.com/siddjain/4cefde4321185c81a663f877fd6b105e
  • we are running the CLI under credentials of an admin user of one of the peer organizations
  • we checked the public cert and it has OU=admin on it. it was generated using cryptogen 1.4.4
how can we fix this? what is the cause?

fwiw, in case it helps, if we try to create the channel using credentials of admin of the orderer org we get a different error

2019-11-30 20:30:53.025 UTC [orderer.common.broadcast] ProcessMessage -> WARN 008 [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:51808 because of error: error validating channel creation transaction for new channel 'tracktrace', could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group]  /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied


Re: Hyperledger Fabric GitHub Migration

binh nguyen <binh1010010110@...>
 

After 4 years, we're back home where we started. Thanks!


On Mon, Nov 25, 2019 at 9:00 PM David Enyeart <enyeart@...> wrote:

The transition to GitHub for source control management, and Azure Pipelines for CI, is now complete for all Fabric development repositories. The final repository to shift will be fabric-test in early December.

You can open pull requests at https://github.com/hyperledger/fabric/pulls.

We use the standard GitHub fork and branch PR workflow. If you need a refresher on the workflow, please see the instructions at https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html.

Thanks to Brett Logan for making the transition a smooth one!


Dave Enyeart

"Brett T Logan" ---11/21/2019 01:11:31 AM---Hello Contributors,

From: "Brett T Logan" <brett.t.logan@...>
To: fabric@...
Date: 11/21/2019 01:11 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperledger Fabric GitHub Migration
Sent by: fabric@...





Hello Contributors,

The time has finally come. The Hyperledger Fabric maintainers are planning for a migration of the core Fabric repository to GitHub this Friday morning Eastern Standard Time.

We are asking that effective immediately, all contributors stop pushing changes to Gerrit. Instead contributors can open their changes as pull requests using the Hyperledger Fabric repository in Github https://github.com/hyperledger/fabric. We have already configured CI to run against new pull requests using Azure Pipelines. This will allow the maintainers time merge as many Gerrit CR's as they can before the cutover.

Any changes that don't make it in before the Friday cutover will be abandoned and contributors will need to reopen them in GitHub. If you feel it's unlikely your change will make it in by Friday morning, we ask that you move it to GitHub now, and close your CR so maintainers can focus on changes that will get merged in the next day.

We will be publishing updated documentation about best practices, but in the meantime a few reminders about GitHub contributions:
    • Commits should be focused and small
    • Commit messages should include the Jira number on their first line and the body should include meaningful information on the change
    • Your signature must be included in your commit message, you can do this using the "-s" flag when running the "git commit" command
    • When opening a pull request it must come from your fork of the Fabric repository
    • When opening the pull request, your pull request message should include a meaningful title and provide the reasoning around the change, this will help maintainers understand what you are attempting to achieve (we will be publishing an automatic template yet this week, once that happens you should fill out the template accordingly)
With this migration, Hyperledger will have migrated all of its development repositories off of Gerrit and Jenkins. Contributions are welcome to any of the Hyperledger projects through GitHub moving forward. It is our hope that by adopting this industry standard we can lower the barrier of entry for new contributors and attract even more of the community to participate in contributing.

As always, thank you for your contributions!

Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
E-mail: brett.t.logan@...







Migration from Gerrit: Help with JQ and Git needed

Ry Jones
 

All,
I have exported all of the git data from Gerrit (except for the fabric-test repo, which is still undergoing development). I have also exported the comments and the like as JSON. I've set up a new org here:


And this is a temporary home of the JSON:

What I need is help gluing the two together, if that's even needed. Take a look here:

Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal : Hyperledger Fabric block archiving

nekia <atsushin@...>
 

Thanks, Manish, Yacov, and Gari.
 
 
I really appreciate for your feedback and insights.
 
(Feedback from Manish)
First, the fundamental assumption that you make is that all the block files are same across peers is incorrect. The block files are not guaranteed to contain same number of blocks across peers. This is because a block file is bounded by the file size and not by the  number of blocks. Further, the size of a given block may vary slightly on each peer. Though the header and the data section of a blocks are of same size across peers but this difference in overall size could be caused by the metadata section which contains concenter signatures. ...
Thank you so much for a quite important point. We're now reviewing and analyzing the implementation of fabric around metadata. Let me ask a question to clarify my understanding.
Say for example, block #100 is available on channel 'mychannel' within organization 'org1', does it mean that the metadata of block #100 on peer0.org1 can be different to the metadata of same block(#100) on a different peer(ex. peer1.org1)? If yes, you are right that our assumption is incorrect. That is, our feature will not be able to refer to a block data (from any peer node) which resides on the archive repository. Because locPointer (offset and length of each block within a blockfile) is not available for archived blockfiles on the repository.

 
Second, there are certain kind of queries for which a peer assumes the presence of block files in the current way. This primarily includes history queries, blocks related queries, and txid related queries. These queries may start failing or lead to crashes or unexpected results if you simply delete the files. ...
Third, somewhat similar to the second point above, peer has a feature wherein it rebuilds the statedb and historydb if they are dropped and peer is simply restarted. For this feature as well it relies on the percense of blockfiles.
We have catered for these situations. Each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface. Even after archiving blockfiles, blockchain characteristics are still maintained on the Blockchain network. So rebuilding statedb and accessing historydb are still available under this archiving feature.
Note: Hyperledger Fabric core has been modified to handle query failures when it attempts to access deleted blockfiles.

 
Fourth, I am not sure if gossip is the right communication mechanism that you want to employ for this communication. An archiver client perhaps can simply poll (or register for updates with) the archiver repository.
In early stage in our development, we used a polling mechanism to trigger archiving. But in terms of the efficiency (process and network traffic), we changed the implementation to be event driven.
 
 
Finally, I would like to understand in more details what are the benefits of having a separate repository? Why not simply let the files be there on the anchor peer and purge from other peers? If the answer is compression, then ideally we should explore a choise of writing the data in blockfiles in compressed format.
Good point. We designed this archiving feature to be as simple as possible (that is, minimal code changes to Hyperledger Fabric core). With the repository concept, we're able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
 
(Feedbacks from Yacov)
one thing I noticed while skimming the code, is that while you send the ArchivedBlockFileMsg via gossip, you are not ensuring it is eventually propagated to peers successfully.
 
This means that if a peer didn't get the message, it won't archive your file.
 
I suggest that you think of a more robust mechanism, like periodically comparing digests of ranges.
You're right. This kind of logic is lacking from our current implementation. Actually it was in our radar, but we have difficulty to implement this aspect. Thank you for pointing to a reference code for pull-based gossip.
 
(Feedbacks from Gari)
It seems the only thing you really wanted to use the peer for was to propagate information to other peers within the same organization. ...
Yes, that is one of the reasons we integrated archiving features into peer binary. But the most important reason is for handling query failures when it attempts to access deleted blockfiles. And each peer node is still able to access all the blockfiles (even if they're archived and discarded) seamlessly via as-is interface.
 
 
Thanks,
Atsushi
 


Documentation Workgroup: No call Friday, 29 November, next call December 6

Anthony O'Dowd <a_o-dowd@...>
 

Hello All,

Due to our colleagues in the US celebrating Thanksgiving there will not be a call this week! Our next call will be Dec 6.

You can read the summary minutes for last week's call: https://wiki.hyperledger.org/display/fabric/2019+11+22+DWG+Agenda
and catch up via the recordings page: https://wiki.hyperledger.org/display/fabric/Recordings

Particular highlights last week were Pam's walk through of the the new GitHub based contribution process and Joe's outline of the upgrade docs. The former is a must-see if you would like to contribute to Hyperledger Fabric documentation. The latter helps you understand how we've simplified the structure of the tasks required to of upgrade Fabric versions. It will particularly helpful as users start to move to Fabric 2.0 Thanks to Pam and Joe for these

Please feel free to contribute to next week's agenda: https://wiki.hyperledger.org/display/fabric/2019+12+06+DWG+Agenda

Look out for our next meetings on Dec 6!

Best regards,

Anthony, Pam, Joe, Nik

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Error while migrating from kafka to RAFT

Adhav Pavan
 

Joson,

I just did as per your suggestion, signed config changes (envelop) with orderer MSP admin. 

As I already mentioned in below mail,

"When we create certificates using cryptogen tool, for peer organizations, the user admin certificate has OU as "Admin", but in the case of Orderer Organization, Certificate has OU as "client". When we sign config update block with orderer admin certs, its getting failed as I already mentioned in linked mail(The identity does not contain OU [ADMIN])."

After investigation, I changed crypto-config.yaml as  below

I have changed crypto-config.yaml in the orderer section as below and its working as expected.
 
CA:
      OrganizationalUnit: admin

 

My concern is why croytogen tool is creating a certificate with client OU, only for orderer!

Thank you so much.

Regards,
Pavan Adhav
8390114357


Re: mixing CouchDB and LevelDB

Siddharth Jain
 

thanks. this is helpful.


From: David Enyeart <enyeart@...>
Sent: Wednesday, November 27, 2019 10:51 AM
To: Siddharth Jain <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] mixing CouchDB and LevelDB
 

You can see an explanation and proposal to enforce the database target here:
https://jira.hyperledger.org/browse/FAB-17163


Dave Enyeart

"Siddharth Jain" ---11/27/2019 01:01:52 PM---I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link

From: "Siddharth Jain" <siddjain@...>
To: "fabric@..." <fabric@...>
Date: 11/27/2019 01:01 PM
Subject: [EXTERNAL] [Hyperledger Fabric] mixing CouchDB and LevelDB
Sent by: fabric@...





I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link to where I read this but am wondering why is that so? Since each peer's db is independent, I would have thought each peer can decide for itself what DB it wants to use. Could someone shed some light on this?




Re: mixing CouchDB and LevelDB

David Enyeart
 

You can see an explanation and proposal to enforce the database target here:
https://jira.hyperledger.org/browse/FAB-17163


Dave Enyeart

"Siddharth Jain" ---11/27/2019 01:01:52 PM---I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link

From: "Siddharth Jain" <siddjain@...>
To: "fabric@..." <fabric@...>
Date: 11/27/2019 01:01 PM
Subject: [EXTERNAL] [Hyperledger Fabric] mixing CouchDB and LevelDB
Sent by: fabric@...





I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link to where I read this but am wondering why is that so? Since each peer's db is independent, I would have thought each peer can decide for itself what DB it wants to use. Could someone shed some light on this?




mixing CouchDB and LevelDB

Siddharth Jain
 

I read somewhere in the docs that all nodes have to either use LevelDB or CouchDB. I can't find link to where I read this but am wondering why is that so? Since each peer's db is independent, I would have thought each peer can decide for itself what DB it wants to use. Could someone shed some light on this?


Re: Maintainer nominations

David Enyeart
 

For those of you not attending the Fabric contributor meeting today where this topic was discussed...

- There was general agreement that documentation should not be split from Fabric repository unless there is a very compelling reason to do so.
- The expectation is that all the issues previously identified in this thread could be resolved without splitting out Fabric documentation.
- As a next step, the documentation team took an action to propose a workflow such that documentation content (including translated content) in the main Fabric repository could be delivered without the need for new documentation/translation specific project maintainers.


Dave Enyeart

"Christopher Ferris" ---11/26/2019 12:26:38 PM---I think that it is important not to conflate things. There's a request to add two maintainers who's

From: "Christopher Ferris" <chris.ferris@...>
To: Me <chris.ferris@...>
Cc: Pam Andrejko <pama@...>, fabric@...
Date: 11/26/2019 12:26 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Maintainer nominations
Sent by: fabric@...





I think that it is important not to conflate things. There's a request to add two maintainers who's role will be
to help manage the Fabric documentation. I think that should be handled independent of any discussion of repository disposition.
Let's please address the two PRs for Chris and Joe independent of this broader discussion.

The generated documentation *should be* generated from the source code, and should most certainly NOT be
segregated to another repository. The authored documentation, written by humans has for the most part been
developed by a mostly disjoint set of people than those who author the code. Now, it would certainly
be nice to ensure that the code and the documentation were kept in lock-step, and even managed such that the code and doc
(and tests) were all committed as a unit; but that has almost never been the case, and it is rare to see it in practice.

There's a different skill set in developing good documentation than there is in writing good code. Both types of skills are important
to a successful project, and especially to one as significant as Fabric. I don't see a problem in having the authored content
managed in a separate repository.

Another factor is that we wanted to integrate the i18n translations and associated workflow that us currently managed
as a Hyperledger Lab process to formally incorporate it into the same repository as we manage the english source
for the documentation. We had previously discussed reconsidering that when we had separated the docs from the
core Fabric repo, as Dave had suggested. I do think that we need to revisit all of that now that we are finally over on GH.

Chris


On Tue, Nov 26, 2019 at 9:45 AM Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:
    I agree that these would be two good additions to the docs maintainership. I approve.

    Chris


On Mon, Nov 25, 2019 at 5:26 PM Pam Andrejko <pama@...> wrote:
All,

I would like to nominate two new Documentation maintainers for the Hyperledger Fabric project. They are Chris Gabriel (Hyperchain Labs) and Joe Alewine (IBM).


Chris has been an instrumental member of the Documentation community workgroup for several years now. In addition to being a regular content reviewer and contributor, he is a consumer of Fabric in his own Hyperchain Labs business that he founded. The insights, perspective, and content that he's provided based on his experience have been invaluable to the documentation work group and Fabric community as a whole.

Joe has been providing important Fabric documentation for over two and half years, is recognized as an expert on the ordering service, the Fabric upgrade process and channel capabilities, and was recently recognized as a
Hyperledger significant contributor.

Adding two more Documentation Maintainers will greatly facilitate the addition and approval of Fabric documentation content going forward.

I have opened a separate PR for each nomination:

Chris Gabriel - https://github.com/hyperledger/fabric/pull/317
Joe Alewine -
https://github.com/hyperledger/fabric/pull/316

I'm requesting that existing maintainers review the nominations and indicate whether they agree with a comment in the PR. Other’s are welcome to provide their input.

Warm regards,
Pam Andrejko





4161 - 4180 of 11433