Date   

Re: consensus metadata update for channel creation is invalid: invalid new config metadata: verifying tls client cert with serial number #fabric-peer

Kumar Shantanu
 

Hi Gari, 

I am executing the peer command from the CLI pod, for example, 

peer channel create -c mychannel -f ./channel.tx --outputBlock ./mychannel.block -o orderer:7050 --tls --cafile /tls/tlscacerts/tls-fabric-ca-build-dlt.pem


On Tue, May 11, 2021 at 11:26 PM Gari Singh <gari.r.singh@...> wrote:
How were you submitting this transaction?

On Sun, May 9, 2021 at 7:13 AM Kumar Shantanu <km.shantanu@...> wrote:

Hello Team,

I am getting this error while creating a channel when I am using docker version 
"2.3.0"


Error: got unexpected status: BAD_REQUEST -- consensus metadata update for channel creation is invalid: invalid new config metadata: verifying tls client cert with serial number 655870291441848262300363997014741113584133644600: x509: certificate signed by unknown authority

Everything works fine with docker version amd64-2.2.0.

Has there been a change in the later versions?


Permission denied from "peer channel create" command using certificate generated by third-party certificate authority (HyperLedger Fabric 2.2.2) #tls #signcerts

Robert Broeckelmann
 

Hello. Thanks in advance.

For a while now (at least two years), we've had the following channel create command working (originally with HLF 1.4.x and more recently with HLF 2.2.2):

docker exec -e CORE_PEER_LOCALMSPID=Org1MSP -e CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/users/Admin@.../msp peer0.org1.example.org peer channel create -o orderer0.example.org:7050 -c example-channel -f /etc/hyperledger/configtx/channel.tx --tls --cafile /var/hyperledger/orderer/tls/ca.crt --certfile /etc/hyperledger/fabric/tls/server.crt --keyfile /etc/hyperledger/fabric/tls/server.key --clientauth

I've changed the names of certain configuration elements to avoid references to the client.

Recently, we replaced our crypto material with certificate/keys that were generated by a third-party certificate authority product--Hashicorp Vault. The certificate Subject DN naming conventions are preserved from the standpoint of OU--well, it's close. I am attempting to create a new network from scratch. So, configtxgen is run to create a new genesis block. The peer & orderer successfully start, but when we go to run this first command in our configuration script, we get the following error:

2021-05-10 17:03:55.867 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: FORBIDDEN -- implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied

The PEER_MSPCONFIGPATH value above points at a directory structure that matches what is generated by cryptogen, but the CA, key, and certificate files have been updated with information for our new private CA and certificates.The TLS client certificate and key files mentioned in the command arguments above are for the peer. The peer is in a separate organization from the orderer cluster.

The orderer logs contains the following (I had to sanitize the log, but I replaced the actual names with Org1, Org2, etc, and any domain names with example.org):

2021-05-10 23:09:14.397 UTC [msp] newBccspMsp -> DEBU 1d8 Creating BCCSP-based MSP instance

2021-05-10 23:09:14.398 UTC [msp] New -> DEBU 1d9 Creating Cache-MSP instance

2021-05-10 23:09:14.398 UTC [msp] Setup -> DEBU 1da Setting up MSP instance OrdererMSP

2021-05-10 23:09:14.398 UTC [msp.identity] newIdentity -> DEBU 1db Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIChDCCAiugAw...

-----END CERTIFICATE-----

2021-05-10 23:09:14.398 UTC [msp.identity] newIdentity -> DEBU 1dc Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIDzzCCA3WgAwIBA...

-----END CERTIFICATE-----

2021-05-10 23:09:14.398 UTC [msp] hasOURole -> DEBU 1dd MSP OrdererMSP checking if the identity is a client

2021-05-10 23:09:14.398 UTC [msp] getCertificationChain -> DEBU 1de MSP OrdererMSP getting certification chain

2021-05-10 23:09:14.399 UTC [msp] hasOURole -> DEBU 1df MSP OrdererMSP checking if the identity is a client

2021-05-10 23:09:14.399 UTC [msp] newBccspMsp -> DEBU 1e0 Creating BCCSP-based MSP instance

2021-05-10 23:09:14.399 UTC [msp] New -> DEBU 1e1 Creating Cache-MSP instance

2021-05-10 23:09:14.399 UTC [msp] Setup -> DEBU 1e2 Setting up MSP instance Org1MSP

2021-05-10 23:09:14.399 UTC [msp.identity] newIdentity -> DEBU 1e3 Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIICkTCCAjegAw…

-----END CERTIFICATE-----

2021-05-10 23:09:14.400 UTC [msp.identity] newIdentity -> DEBU 1e4 Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIEBjCCA6ygAwIBAgIUN...

-----END CERTIFICATE-----

2021-05-10 23:09:14.401 UTC [msp] hasOURole -> DEBU 1e5 MSP Org1MSP checking if the identity is a client

2021-05-10 23:09:14.401 UTC [msp] getCertificationChain -> DEBU 1e6 MSP Org1MSP getting certification chain

2021-05-10 23:09:14.401 UTC [msp] hasOURole -> DEBU 1e7 MSP Org1MSP checking if the identity is a client

2021-05-10 23:09:14.401 UTC [msp] newBccspMsp -> DEBU 1e8 Creating BCCSP-based MSP instance

2021-05-10 23:09:14.401 UTC [msp] New -> DEBU 1e9 Creating Cache-MSP instance

2021-05-10 23:09:14.401 UTC [msp] Setup -> DEBU 1ea Setting up MSP instance Org2MSP

2021-05-10 23:09:14.401 UTC [msp.identity] newIdentity -> DEBU 1eb Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIICojCCAkmgAwIBAgIUQnfd…

-----END CERTIFICATE-----

2021-05-10 23:09:14.402 UTC [msp.identity] newIdentity -> DEBU 1ec Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIEWzCCBAGgAwIBAgIU…

-----END CERTIFICATE-----

2021-05-10 23:09:14.402 UTC [msp] hasOURole -> DEBU 1ed MSP Org2MSP checking if the identity is a client

2021-05-10 23:09:14.402 UTC [msp] getCertificationChain -> DEBU 1ee MSP Org2MSP getting certification chain

2021-05-10 23:09:14.402 UTC [msp] hasOURole -> DEBU 1ef MSP Org2MSP checking if the identity is a client

2021-05-10 23:09:14.402 UTC [msp] newBccspMsp -> DEBU 1f0 Creating BCCSP-based MSP instance

2021-05-10 23:09:14.402 UTC [msp] New -> DEBU 1f1 Creating Cache-MSP instance

2021-05-10 23:09:14.402 UTC [msp] Setup -> DEBU 1f2 Setting up MSP instance Org3MSP

2021-05-10 23:09:14.403 UTC [msp.identity] newIdentity -> DEBU 1f3 Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIClDCCAjmgAwIBAgIUd…

-----END CERTIFICATE-----

2021-05-10 23:09:14.404 UTC [msp.identity] newIdentity -> DEBU 1f4 Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIEDjCCA7WgAwIBAg...

-----END CERTIFICATE-----

2021-05-10 23:09:14.404 UTC [msp] hasOURole -> DEBU 1f5 MSP Org3MSP checking if the identity is a client

2021-05-10 23:09:14.404 UTC [msp] getCertificationChain -> DEBU 1f6 MSP Org3MSP getting certification chain

2021-05-10 23:09:14.404 UTC [msp] hasOURole -> DEBU 1f7 MSP Org3MSP checking if the identity is a client

2021-05-10 23:09:14.404 UTC [msp] newBccspMsp -> DEBU 1f8 Creating BCCSP-based MSP instance

2021-05-10 23:09:14.404 UTC [msp] New -> DEBU 1f9 Creating Cache-MSP instance

2021-05-10 23:09:14.404 UTC [msp] Setup -> DEBU 1fa Setting up MSP instance Org4MSP

2021-05-10 23:09:14.404 UTC [msp.identity] newIdentity -> DEBU 1fb Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIICkTCCAjegAwIBAgIUcckxGcnYwCQ...

-----END CERTIFICATE-----

2021-05-10 23:09:14.406 UTC [msp.identity] newIdentity -> DEBU 1fc Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIEBTCCA6ugAwIBAgI...

-----END CERTIFICATE-----

2021-05-10 23:09:14.406 UTC [msp] hasOURole -> DEBU 1fd MSP Org4MSP checking if the identity is a client

2021-05-10 23:09:14.406 UTC [msp] getCertificationChain -> DEBU 1fe MSP Org4MSP getting certification chain

2021-05-10 23:09:14.406 UTC [msp] hasOURole -> DEBU 1ff MSP Org4MSP checking if the identity is a client

2021-05-10 23:09:14.406 UTC [msp] Setup -> DEBU 200 Setting up the MSP manager (5 msps)

2021-05-10 23:09:14.406 UTC [msp] Setup -> DEBU 201 MSP manager setup complete, setup 5 msps

2021-05-10 23:09:14.407 UTC [msp] DeserializeIdentity -> DEBU 202 Obtaining identity

2021-05-10 23:09:14.407 UTC [msp.identity] newIdentity -> DEBU 203 Creating identity instance for cert -----BEGIN CERTIFICATE-----

MIIEBTCCA6ygAwIBAgIUN/TW0leZER...

-----END CERTIFICATE-----

2021-05-10 23:09:14.407 UTC [msp.identity] Verify -> DEBU 204 Verify: digest = 00000000  98 a6 d0 82 56 95 eb eb  02 1b 73 d3 f1 22 02 50  |....V.....s..".P|

00000010  58 e1 b8 2c 21 bd 23 1a  75 1a 7a d4 fa f4 91 fc  |X..,!.#.u.z.....|

2021-05-10 23:09:14.407 UTC [msp.identity] Verify -> DEBU 205 Verify: sig = 00000000  30 44 02 20 58 c6 c5 27  40 65 3c d3 45 90 f9 03  |0D. X..'@e<.E...|

00000010  44 09 8a e9 5f 1c a3 69  64 47 27 e4 d5 bd 85 16  |D..._..idG'.....|

00000020  d0 73 33 6a 02 20 36 de  d3 54 58 df 20 b2 bf ec  |.s3j. 6..TX. ...|

00000030  83 89 98 2c 52 60 a3 ce  72 29 5d dc 19 7e 62 03  |...,R`..r)]..~b.|

00000040  3b b4 12 69 b6 8c                                 |;..i..|

2021-05-10 23:09:14.407 UTC [msp.identity] Verify -> DEBU 206 Verify: digest = 00000000  98 a6 d0 82 56 95 eb eb  02 1b 73 d3 f1 22 02 50  |....V.....s..".P|

00000010  58 e1 b8 2c 21 bd 23 1a  75 1a 7a d4 fa f4 91 fc  |X..,!.#.u.z.....|

2021-05-10 23:09:14.407 UTC [msp.identity] Verify -> DEBU 207 Verify: sig = 00000000  30 44 02 20 58 c6 c5 27  40 65 3c d3 45 90 f9 03  |0D. X..'@e<.E...|

00000010  44 09 8a e9 5f 1c a3 69  64 47 27 e4 d5 bd 85 16  |D..._..idG'.....|

00000020  d0 73 33 6a 02 20 36 de  d3 54 58 df 20 b2 bf ec  |.s3j. 6..TX. ...|

00000030  83 89 98 2c 52 60 a3 ce  72 29 5d dc 19 7e 62 03  |...,R`..r)]..~b.|

00000040  3b b4 12 69 b6 8c                                 |;..i..|

2021-05-10 23:09:14.407 UTC [msp] satisfiesPrincipalInternalV142 -> DEBU 208 Checking if identity has been named explicitly as an admin for Org1MSP

2021-05-10 23:09:14.408 UTC [msp.identity] Sign -> DEBU 209 Sign: plaintext: ...

2021-05-10 23:09:14.408 UTC [msp.identity] Sign -> DEBU 20a Sign: digest: 98343EBCEE7E1709A1D974F702D0018881D4FFF173062DA05D5E09AECBE5A235

2021-05-10 23:09:14.408 UTC [msp.identity] Sign -> DEBU 20b Sign: plaintext: ...

2021-05-10 23:09:14.408 UTC [msp.identity] Sign -> DEBU 20c Sign: digest: C45BC19C1D6C873C1300A363C2ED9BFB0734C118EB97149289DF8F55143FE76F

2021-05-10 23:09:14.409 UTC [msp.identity] Verify -> DEBU 20d Verify: digest = 00000000  c4 5b c1 9c 1d 6c 87 3c  13 00 a3 63 c2 ed 9b fb  |.[...l.<...c....|

00000010  07 34 c1 18 eb 97 14 92  89 df 8f 55 14 3f e7 6f  |.4.........U.?.o|

2021-05-10 23:09:14.409 UTC [msp.identity] Verify -> DEBU 20e Verify: sig = 00000000  30 44 02 20 31 55 c3 76  31 ef a6 93 f6 cf 73 31  |0D. 1U.v1.....s1|

00000010  d8 86 3a 6f 7d 3a 97 d6  a4 91 82 6b 84 2c a5 fc  |..:o}:.....k.,..|

00000020  44 4b 67 9a 02 20 47 69  6a 31 f0 8b db fd 33 7a  |DKg.. Gij1....3z|

00000030  28 89 e7 f9 d3 fc b3 5e  b6 18 33 ed c3 c8 3a 24  |(......^..3...:$|

00000040  23 80 91 90 00 7c                                 |#....||

2021-05-10 23:09:14.409 UTC [orderer.common.broadcast] ProcessMessage -> WARN 20f [channel: Org1-channel] Rejecting broadcast of config message from 172.28.0.24:38316 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

2021-05-10 23:09:14.409 UTC [comm.grpc.server] 1 -> INFO 210 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Broadcast grpc.peer_address=172.28.0.24:38316 grpc.peer_subject="CN=Admin@...,OU=admin,O=Example Org,L=Somewhere,ST=WA,C=US" grpc.code=OK grpc.call_duration=11.582222ms

2021-05-10 23:09:14.411 UTC [common.deliver] Handle -> WARN 211 Error reading from 172.28.0.24:38314: rpc error: code = Canceled desc = context canceled

2021-05-10 23:09:14.411 UTC [comm.grpc.server] 1 -> INFO 212 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.28.0.24:38314 grpc.peer_subject="CN=Admin@...,OU=admin,O=Example Org,L=Somewhere,ST=WA,C=US" error="rpc error: code = Canceled desc = context canceled" grpc.code=Canceled grpc.call_duration=17.109561ms

In our original cryptogen setup, we did not have a config.yaml file on the orderer. I tried adding:

/etc/hyperledger/msp/orderer/msp/config.yaml
NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.example.com-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.example.com-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.example.com-cert.pem
    OrganizationalUnitIdentifier: admin

The result is the same.

Any idea what I might be doing wrong?

Thank you for your time in advance.


Re: consensus metadata update for channel creation is invalid: invalid new config metadata: verifying tls client cert with serial number #fabric-peer

Gari Singh
 

How were you submitting this transaction?


On Sun, May 9, 2021 at 7:13 AM Kumar Shantanu <km.shantanu@...> wrote:

Hello Team,

I am getting this error while creating a channel when I am using docker version 
"2.3.0"


Error: got unexpected status: BAD_REQUEST -- consensus metadata update for channel creation is invalid: invalid new config metadata: verifying tls client cert with serial number 655870291441848262300363997014741113584133644600: x509: certificate signed by unknown authority

Everything works fine with docker version amd64-2.2.0.

Has there been a change in the later versions?


Re: Fabric contributor meeting - May 12, 2021 - any agenda topics?

Chris Gabriel
 

Security Guideline development based on input from consultant report and Fabric Community.  Develop path forward on writing, reviewing, and issuing.

On May 11, 2021, at 4:24 PM, David Enyeart <enyeart@...> wrote:

Hello, does anybody have topics for the contributor meeting tomorrow? If there are no topics, I'll send out a cancel notice...


Hyperledger Fabric Contributor Meeting

When: Every other Wednesday 9am US Eastern, 13:00 UTC

Where: https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings



Fabric contributor meeting - May 12, 2021 - any agenda topics?

David Enyeart
 

Hello, does anybody have topics for the contributor meeting tomorrow? If there are no topics, I'll send out a cancel notice...


Hyperledger Fabric Contributor Meeting

When: Every other Wednesday 9am US Eastern, 13:00 UTC

Where: https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings


Private Chaincode Lab - Tue, 05/11/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
Tuesday, 11 May 2021
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Single Channel BC network. Is it a good approach?

Nikos Karamolegkos
 

Perfect. I think I am ok.

To summarize (for future reference). Endorsement policies are based on organizations only. So you can set either the majority of N orgs to endorse or a part of them (e.g 3 of N, or more specific org A, org B, and org D). Also, you can define which peers in each organization will participate in the endorsement for this organization to generate it's "vote".


回复: [Hyperledger Fabric] 回复: missing tags for go chaincode developement dependencies

david liu
 

Thanks Dave,

What I get from Matt is he was "suggesting we get in front of any potential future incompatibility by creating release branches in advance"

I also agree that "doing it for each LTS release is a good middle ground". Actually that is pretty enough. 

发件人: David Enyeart <enyeart@...>
发送时间: 2021年5月8日 1:18
收件人: david liu <david-khala@...>
抄送: fabric@... <fabric@...>; Matthew Sykes <matthew.sykes@...>
主题: Re: [Hyperledger Fabric] 回复: missing tags for go chaincode developement dependencies
 

In the early days we created release branches in every repository. More recently we haven't been creating release branches unless there was some incompatibility or fixes across releases that required it.

Matt - are you suggesting that there is an incompatibility in fabric-chaincode-go that warrants release branches today? Or are you simply suggesting we get in front of any potential future incompatibility by creating release branches in advance? Perhaps doing it for each LTS release is a good middle ground?


Dave Enyeart

"david liu" ---05/07/2021 10:18:48 AM---Hi Matt, Thanks so much for your clarification.

From: "david liu" <david-khala@...>
To: "fabric@..." <fabric@...>, Matthew Sykes <matthew.sykes@...>
Date: 05/07/2021 10:18 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] 回复: missing tags for go chaincode developement dependencies
Sent by: fabric@...





Hi Matt, Thanks so much for your clarification. And I would like to follow your last point that can we create a r2 branch for it first? From: fabric@... <fabric@...> on behalf of Matthew Sykes <matthew.sykes@...> ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi Matt,

Thanks so much for your clarification.

And I would like to follow your last point that can we create a r2 branch for it first?





From: fabric@... <fabric@...> on behalf of Matthew Sykes <matthew.sykes@...>
Sent:
Thursday, May 6, 2021 6:43:02 AM
To:
fabric@... <fabric@...>
Subject:
Re: [Hyperledger Fabric] 回复: missing tags for go chaincode developement dependencies

We have chosen not to add version tags to the modules because they tend to evolve compatibly and are mostly disconnected from the fabric releases. For example, if you pull any version of fabric-chaincode-go, it should work with any version of fabric. A similar statement can be made for the protocol buffers (barring additions made to support recent versions).

If we started adding tags that reflected the fabric versions, this would break the semantic versioning and require consumers to change their import paths to reflect `v2` of Fabric. If we started doing proper semantic versioning, we would end up bumping minor versions regularly and it would skew heavily from the released versions. Instead, we've chosen to stay with v0 semantics.

To make a long story short, the module versioning is disjoint from the fabric versioning and in place of tags we've used branches that map to the fabric version. When you `go get` your module, you can use `@branch` to pull the latest from the branch. The `go.mod` will then be updated with the commit timestamp and hash of the repository hosting the module. We are not the only ones to do this. (See golang.org/x/{crypto,sync,sys,time.tools}).

It does seem we've messed up with fabric-chaincode-go, however, since we don't have any branches there. That should probably be fixed for release-2.2+.

On Tue, May 4, 2021 at 9:20 PM david liu <david-khala@...> wrote:
    Hi Fabric maintainers,

    Is there any updates on this? I am happy to hear any consideration on why not pushing named git tag to fabric-chaincode-go and fabric-protos-go.

    If it is intended and designed as a WON’T DO, an clarification is welcomed to help us feedback to community members.

    发件人: 刘 宇翔
    发送时间:
    2021年4月20日 21:05
    收件人:
    fabric@...; twg-china@...
    主题:
    missing tags for go chaincode developement dependencies

    Hi Fabric maintainers,


    As some community member and me found for a while,

    Both following repositories have no git tags yet pushed to Github

    github.com/hyperledger/fabric-chaincode-go
    github.com/hyperledger/fabric-protos-go

    This will introduce a result that fabric go chaincode developer have to suffer from go.mod dependency versioning issue. such as

    v0.0.0-20200511190512-bcfeb58dd83a

    Each time we get lost in what 20200511190512 indicates. We have to guess whether it is 2.2.x or 2.3.x

    Can you consider give tags to them, in a similar way in fabric itself. then we could pin to use v2.2.x as dependency version.


    Best Regards,

    David Liu




--
Matthew Sykes
matthew.sykes@...




consensus metadata update for channel creation is invalid: invalid new config metadata: verifying tls client cert with serial number #fabric-peer

Kumar Shantanu
 

Hello Team,

I am getting this error while creating a channel when I am using docker version 
"2.3.0"


Error: got unexpected status: BAD_REQUEST -- consensus metadata update for channel creation is invalid: invalid new config metadata: verifying tls client cert with serial number 655870291441848262300363997014741113584133644600: x509: certificate signed by unknown authority

Everything works fine with docker version amd64-2.2.0.

Has there been a change in the later versions?


Re: 回复: missing tags for go chaincode developement dependencies

David Enyeart
 

In the early days we created release branches in every repository. More recently we haven't been creating release branches unless there was some incompatibility or fixes across releases that required it.

Matt - are you suggesting that there is an incompatibility in fabric-chaincode-go that warrants release branches today? Or are you simply suggesting we get in front of any potential future incompatibility by creating release branches in advance? Perhaps doing it for each LTS release is a good middle ground?


Dave Enyeart

"david liu" ---05/07/2021 10:18:48 AM---Hi Matt, Thanks so much for your clarification.

From: "david liu" <david-khala@...>
To: "fabric@..." <fabric@...>, Matthew Sykes <matthew.sykes@...>
Date: 05/07/2021 10:18 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] 回复: missing tags for go chaincode developement dependencies
Sent by: fabric@...





Hi Matt, Thanks so much for your clarification. And I would like to follow your last point that can we create a r2 branch for it first? From: fabric@... <fabric@...> on behalf of Matthew Sykes <matthew.sykes@...> ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi Matt,

Thanks so much for your clarification.

And I would like to follow your last point that can we create a r2 branch for it first?





From: fabric@... <fabric@...> on behalf of Matthew Sykes <matthew.sykes@...>
Sent:
Thursday, May 6, 2021 6:43:02 AM
To:
fabric@... <fabric@...>
Subject:
Re: [Hyperledger Fabric] 回复: missing tags for go chaincode developement dependencies

We have chosen not to add version tags to the modules because they tend to evolve compatibly and are mostly disconnected from the fabric releases. For example, if you pull any version of fabric-chaincode-go, it should work with any version of fabric. A similar statement can be made for the protocol buffers (barring additions made to support recent versions).

If we started adding tags that reflected the fabric versions, this would break the semantic versioning and require consumers to change their import paths to reflect `v2` of Fabric. If we started doing proper semantic versioning, we would end up bumping minor versions regularly and it would skew heavily from the released versions. Instead, we've chosen to stay with v0 semantics.

To make a long story short, the module versioning is disjoint from the fabric versioning and in place of tags we've used branches that map to the fabric version. When you `go get` your module, you can use `@branch` to pull the latest from the branch. The `go.mod` will then be updated with the commit timestamp and hash of the repository hosting the module. We are not the only ones to do this. (See golang.org/x/{crypto,sync,sys,time.tools}).

It does seem we've messed up with fabric-chaincode-go, however, since we don't have any branches there. That should probably be fixed for release-2.2+.

On Tue, May 4, 2021 at 9:20 PM david liu <david-khala@...> wrote:
    Hi Fabric maintainers,

    Is there any updates on this? I am happy to hear any consideration on why not pushing named git tag to fabric-chaincode-go and fabric-protos-go.

    If it is intended and designed as a WON’T DO, an clarification is welcomed to help us feedback to community members.

    发件人: 刘 宇翔
    发送时间:
    2021年4月20日 21:05
    收件人:
    fabric@...; twg-china@...
    主题:
    missing tags for go chaincode developement dependencies

    Hi Fabric maintainers,


    As some community member and me found for a while,

    Both following repositories have no git tags yet pushed to Github

    github.com/hyperledger/fabric-chaincode-go
    github.com/hyperledger/fabric-protos-go

    This will introduce a result that fabric go chaincode developer have to suffer from go.mod dependency versioning issue. such as

    v0.0.0-20200511190512-bcfeb58dd83a

    Each time we get lost in what 20200511190512 indicates. We have to guess whether it is 2.2.x or 2.3.x

    Can you consider give tags to them, in a similar way in fabric itself. then we could pin to use v2.2.x as dependency version.


    Best Regards,

    David Liu




--
Matthew Sykes
matthew.sykes@...




Re: Single Channel BC network. Is it a good approach?

David Enyeart
 

You can keep the chaincode endorsement policy as majority of orgs ( the default example at https://github.com/hyperledger/fabric-samples/blob/main/test-network/configtx/configtx.yaml#L187-L189 ) so that each org gets one vote regardless of their number of peers. But what endorsement means for each org can be configured in an org level policy here:
https://github.com/hyperledger/fabric-samples/blob/main/test-network/configtx/configtx.yaml#L70-L72

So if Org1 wants at least two peers from its org to endorse, you could configure that policy to be:
"AND('Org1MSP.peer','Org1MSP.peer')"

Note that you call out the identity role (*.peer), not individual peers, so that an org can more easily add/remove peers without having to change the channel config.

This all goes well beyond the Medium article that you mentioned... I believe that article was simply assuming that each org has one peer. So when they said "At least 3 peers of A, B, C, D, E, F, G must endorse transactions" they were talking about 3 of 7 orgs.


Dave Enyeart

"Nikos Karamolegkos" ---05/07/2021 10:06:42 AM---Nice as described in the docs. If we are talking about peers then "AND('A.peer0', 'A.peer1', 'A.pee

From: "Nikos Karamolegkos" <nkaram@...>
To: Yacov Manevich <YACOVM@...>
Cc: fabric@...
Date: 05/07/2021 10:06 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?
Sent by: fabric@...





Nice as described in the docs. If we are talking about peers then "AND('A.peer0', 'A.peer1', 'A.peer2')". Thus, the org A participate with 3 peers in the endorsement but his participation in the endorsing counts as 1 "vote". Correct? So in ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Nice as described in the docs. If we are talking about peers then "AND('A.peer0', 'A.peer1', 'A.peer2')". Thus, the org A participate with 3 peers in the endorsement but his participation in the endorsing counts as 1 "vote". Correct? So in case we have N orgs with different number of peers each one and we need the majority to approve we need approve "votes" of N/2 + 1 orgs? (without caring about the number of peer at all because it is a internal thing of the organization)

To conclude, how can I write my policy for this case to include majority of orgs and at the same time specific peers of each org?

.On 7/5/21 3:39 μ.μ., Yacov Manevich wrote:

      Yes:
      "AND('A.member', 'A.member', 'A.member')"
--
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)





Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 05/07/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 7 May 2021
11:00am to 12:00pm
(GMT-04:00) America/New York

Where:
https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

Organizer:
pama@...

Description:
Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


Re: 回复: missing tags for go chaincode developement dependencies

david liu
 

Hi Matt,

Thanks so much for your clarification.

And I would like to follow your last point that can we create a r2 branch for it first?




From: fabric@... <fabric@...> on behalf of Matthew Sykes <matthew.sykes@...>
Sent: Thursday, May 6, 2021 6:43:02 AM
To: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] 回复: missing tags for go chaincode developement dependencies
 
We have chosen not to add version tags to the modules because they tend to evolve compatibly and are mostly disconnected from the fabric releases. For example, if you pull any version of fabric-chaincode-go, it should work with any version of fabric. A similar statement can be made for the protocol buffers (barring additions made to support recent versions).

If we started adding tags that reflected the fabric versions, this would break the semantic versioning and require consumers to change their import paths to reflect `v2` of Fabric. If we started doing proper semantic versioning, we would end up bumping minor versions regularly and it would skew heavily from the released versions. Instead, we've chosen to stay with v0 semantics.

To make a long story short, the module versioning is disjoint from the fabric versioning and in place of tags we've used branches that map to the fabric version. When you `go get` your module, you can use `@branch` to pull the latest from the branch. The `go.mod` will then be updated with the commit timestamp and hash of the repository hosting the module. We are not the only ones to do this. (See golang.org/x/{crypto,sync,sys,time.tools}).

It does seem we've messed up with fabric-chaincode-go, however, since we don't have any branches there. That should probably be fixed for release-2.2+.

On Tue, May 4, 2021 at 9:20 PM david liu <david-khala@...> wrote:

Hi Fabric maintainers,

Is there any updates on this? I am happy to hear any consideration on why not pushing named git tag to fabric-chaincode-go and fabric-protos-go.

If it is intended and designed as a WON’T DO, an clarification is welcomed to help us feedback to community members.

 

发件人: 刘 宇翔
发送时间: 2021420 21:05
收件人: fabric@...; twg-china@...
主题: missing tags for go chaincode developement dependencies

 

Hi Fabric maintainers, 


As some community member and me found for a while, 

Both following repositories have no git tags yet pushed to Github

github.com/hyperledger/fabric-chaincode-go
github.com/hyperledger/fabric-protos-go

This will introduce a result that fabric go chaincode developer have to suffer from go.mod dependency versioning issue. such as 

v0.0.0-20200511190512-bcfeb58dd83a
 
Each time we get lost in what 20200511190512 indicates. We have to guess whether it is 2.2.x or 2.3.x
 
Can you consider give tags to them, in a similar way in fabric itself. then we could pin to use v2.2.x as dependency version.


Best Regards,

David Liu



--
Matthew Sykes
matthew.sykes@...


Re: Single Channel BC network. Is it a good approach?

Nikos Karamolegkos
 

Nice as described in the docs. If we are talking about peers then "AND('A.peer0', 'A.peer1', 'A.peer2')". Thus, the org A participate with 3 peers in the endorsement but his participation in the endorsing counts as 1 "vote". Correct? So in case we have N orgs with different number of peers each one and we need the majority to approve we need approve "votes" of N/2 + 1 orgs? (without caring about the number of peer at all because it is a internal thing of the organization)

To conclude, how can I write my policy for this case to include majority of orgs and at the same time specific peers of each org?

.On 7/5/21 3:39 μ.μ., Yacov Manevich wrote:
Yes:
"AND('A.member', 'A.member', 'A.member')"
-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Single Channel BC network. Is it a good approach?

Yacov
 

> Can I set that I need endorsement from the 3 nodes (because I paranoid and I would like to avoid the case that a peer is compromised )
Yes:
"AND('A.member', 'A.member', 'A.member')"


> Also, in the same scenario/content can I specify that for a specific type of transaction I need endorsement from A and B while for a second type o transaction I need endorsement just for C?
You either have an endorsement policy for an entire chaincode namespace, or for a collection, or you just use a state based endorsement policy.



From:        "Nikos Karamolegkos" <nkaram@...>
To:        fabric@...
Date:        05/07/2021 10:57 AM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?
Sent by:        fabric@...




Thank you for the answers you are really fast and helpful. Although I solved some issues I am a bit confused. If endorsement policies are based on organizations only, not the number of peers, what happens in case an org has 3 peers (A,B,C)? ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Thank you for the answers you are really fast and helpful. Although I solved some issues I am a bit confused. If endorsement policies are based on organizations only, not the number of peers, what happens in case an org has 3 peers (A,B,C)? Is enough to endorse only one of the three? Can I set that I need endorsement from the 3 nodes (because I paranoid and I would like to avoid the case that a peer is compromised )? Also, in the same scenario/content can I specify that for a specific type of transaction I need endorsement from A and B while for a second type o transaction I need endorsement just for C? (as the guy here describe in paragraph Endorsement Policy).




Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Mattia Bolzonella
 

Hi Chris,
Thanks for the advice, the certs are correct. I will explain better the situation:

Currently I have 2 channels, 3 orderers with the TLS certs expired. 

  • the system channel
  • an application channel, called 'mychannel'
I've updated the admins of orderer and peer organization (2 separate orgs) in the system channel, and after that I executed a channel config update to change the certs of the first orderer (called ord0).

After that i restart the orderer and now I have:
  • In mychannel ord0 cannot partecipate in the consensus, as expected since the channel config is not updated
  • in the system channel i continuosly have TLS handshake error with the others orderers (ord1 & ord2)


The configuration of the orderer containers are the following:

ORD0
ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS=true

ORD1 & ORD2

ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS=true
ORDERER_GENERAL_TLS_TLSHANDSHAKETIMESHIFT=200h
ORDERER_GENERAL_CLUSTER_TLSHANDSHAKETIMESHIFT=200h

Now, since ord1 & ord2 have expired certs i think i need the TimeShift, in fact they are able to reach consensus (I can pull the latest config block from the system channel). 
But with this settings, certs of ord0 result not yet valid since ord1 & ord2 are in the past. 

So I tried a different configuration just to see what happens:
 
ORD0
ORDERER_GENERAL_TLS_TLSHANDSHAKETIMESHIFT=200h
ORD1 -> no timeshift set
ORD2 -> Stopped to not flood the logs of the others orderer

In this way on the system channel I can get the quorum using ord0 (new certs) and ord1 (expired). I think I got the procedure. But there is a thing that I'm not sure of:
Now I'm in a situation in which I'm able to get 2 orderers out of 3 to communicate thanks to the time shift parameter. If update all the orderers in the system channel with new certs i would have the system channel correctly configured and all the certs on the FS of the orderers updated.
 
Now the problem comes with the application channel  "mychannel"
 
After udpating the system channel I have new certs in the FS of the orderers, but the update wouldn't be possible on mychannel because I have a mismatch between the certs on the FS and the certs on the config block of the channel, am I right?
 
So I should update a orderer at a time in every channel, that's what I'm considering


Re: Single Channel BC network. Is it a good approach?

Nikos Karamolegkos
 

Thank you for the answers you are really fast and helpful. Although I solved some issues I am a bit confused. If endorsement policies are based on organizations only, not the number of peers, what happens in case an org has 3 peers (A,B,C)? Is enough to endorse only one of the three? Can I set that I need endorsement from the 3 nodes (because I paranoid and I would like to avoid the case that a peer is compromised )? Also, in the same scenario/content can I specify that for a specific type of transaction I need endorsement from A and B while for a second type o transaction I need endorsement just for C? (as the guy here describe in paragraph Endorsement Policy).


Re: [External] : Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?

Mark Rakhmilevich
 

One clarification – this works only when both chaincodes are resident on the same peer, which means you would need an organization and at least one peer that belongs to both channels.  Here’s an example of how this is implemented: https://kctheservant.medium.com/cross-chaincode-invoking-in-hyperledger-fabric-8b8df1183c04

 

Thanks,

    Mark

 

From: fabric@... <fabric@...> On Behalf Of Mark Rakhmilevich
Sent: Thursday, May 6, 2021 12:48 PM
To: Mahwish Anwar <mahwish.anwar@...>; fabric@...
Subject: Re: [External] : Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?

 

Mahwish,

    You can do cross-channel queries: e.g., chaincode1 invokes chancode2’s query function for some data from channel 2 as part of its business logic, which ultimately creates a RWset as part a transaction committed on channel1.

 

Best Regards,

   Mark

 

From: fabric@... <fabric@...> On Behalf Of Mahwish Anwar
Sent: Thursday, May 6, 2021 8:14 AM
To: fabric@...
Subject: [External] : Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?

 

Been reading the comments.
2 channels would make sense when, for example:

Org 1-5 keep the same data. They will see chain code 1, and ledger 1. Let's say servers. 
Majority orgs approve, meaning 3 would endorse.

Org 6-7 for example, are on channel 2. They will see chain code 2, and ledger 2. Let's say data-generating devices.
Majority orgs approve, meaning 2 would endorse.

Is there a way to link both ledgers? for example, some data from ledger 2 becomes input (transaction) for org 1?


Re: [External] : Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?

Mark Rakhmilevich
 

Mahwish,

    You can do cross-channel queries: e.g., chaincode1 invokes chancode2’s query function for some data from channel 2 as part of its business logic, which ultimately creates a RWset as part a transaction committed on channel1.

 

Best Regards,

   Mark

 

From: fabric@... <fabric@...> On Behalf Of Mahwish Anwar
Sent: Thursday, May 6, 2021 8:14 AM
To: fabric@...
Subject: [External] : Re: [Hyperledger Fabric] Single Channel BC network. Is it a good approach?

 

Been reading the comments.
2 channels would make sense when, for example:

Org 1-5 keep the same data. They will see chain code 1, and ledger 1. Let's say servers. 
Majority orgs approve, meaning 3 would endorse.

Org 6-7 for example, are on channel 2. They will see chain code 2, and ledger 2. Let's say data-generating devices.
Majority orgs approve, meaning 2 would endorse.

Is there a way to link both ledgers? for example, some data from ledger 2 becomes input (transaction) for org 1?


Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Chris Gabriel
 

Hi Mattia,
You have a cert mismatch. Make sure to double check where you placed the newly created certs and make sure they match.
Chris 


On May 6, 2021, at 11:27 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:



Hi Chris,
I updated one orderer TLS certs in the system channel but it's not included in the raft consensus. If i try to fecth the channel confing block from the updated orderer i get SERVICE UNAVAILABLE.
On the updated orderer i get:
2021-05-06 18:21:23.035 CEST [orderer.consensus.etcdraft] campaign -> INFO 272 2 [logterm: 364, index: 371] sent MsgPreVote request to 1 at term 364 channel=sys-channel node=2 2021-05-06 18:21:23.036 CEST [orderer.consensus.etcdraft] campaign -> INFO 273 2 [logterm: 364, index: 371] sent MsgPreVote request to 3 at term 364 channel=sys-channel node=2 2021-05-06 18:21:27.220 CEST [comm.tls] ClientHandshake -> ERRO 274 Client TLS handshake failed after 1.087456ms with error: public key of server certificate presented by orderer0.obsucureddomain:7050 doesn't match the expected public key remoteaddress=xxxxxx:7050


So I'm no confident to update one more orderer in the system channel. Plus to that, if I updated all my orderers in the system channel, then replace the tls certs, and restart the orderer then i would find 2 orderers updatet in the system channel and not in the application channel which will lose the quorum.

 

I don't understand what's wrong, I cannot lose my production channels and data.


1 - 20 of 9941