please note that today's call has been cancelled - the next call planned is on 9th July.

best regards Paul

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1
mahoney@...

----- Forwarded by Paul O'Mahoney/UK/IBM on 25/06/2020 14:37 -----

From:        Paul O'Mahoney/UK/IBM
To:        fabric@...
Date:        22/06/2020 09:49
Subject:        Next Hyperledger Fabric Application Developer Community call  -- this Thursday 25th June @ 3pm UTC time: 4pm UK, 11am ET, 8am PT

---

dear Fabric Application Developer,


the next  Fabric Application Developer community call is: Thursday 25th June - 3pm UTC,  4pm UK time (+1), 11am ET (-5 hrs), 8am PT (-8 hrs)  - other time zones here.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Agendas%3A+Fabric+Application+Developer+Community+Call+Meetings  

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts, client apps using the SDKs, tutorials/demos etc -  eg using NodeJS/TypeScript, Java, Go etc etc) 
- helping app developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes

The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1
mahoney@...


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


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

The easiest thing to do is to find the CKA_ID attribute of the private key stored in the HSM and then set the AltID property for the PKCS11 BCCSP.
AltID was added in 1.4.6 as I recall to help facilitate this type of config.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: carlos.ellery@...
From: "Brett T Logan"
Sent by: fabric@...
Date: 06/24/2020 07:57PM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Peer failed getting private key from HSM

Are you setting up the peer and orderer to communicate with the external CA's HSM?

Did you generate the CSR yourself, and thus you have the private key and you provided it to them for import, or did the external CA provider generate everything and they fully own the private key? BCCSP doesn't use the SKI extension of the cert, it computes its own SKI by doing a SHA256 over the private key, the corresponding public signing cert is named with this SKI (SHA256) of the private key. If you had the private key (or access to it via PKCS11) you could perform the same operation BCCSP does to compute the SHA256 SKI.

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 26 June 2020, 6:00am to 7:00am, (GMT+01:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

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

Hi everyone,

I'm trying to use a certificate issued by an external CA trough an HSM integration but it's not working. The peer node (v1.4.7) doesn't start and gives the following output (complete log available at https://pastebin.com/J6npgd6G):

...
Failed getting key for SKI [[214 159 229 72 115 120 224 145 78 141 101 135 1 40 168 212 181 93 5 165 2 196 93 173 222 163 12 116 82 161 254 44]]
...
2020-06-24 22:32:42.231 UTC [main] InitCmd -> ERRO 03a Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: KeyMaterial not found in SigningIdentityInfo

I've found that my certificate (located at msp/signcerts) doesn't have the SKID extension (https://tools.ietf.org/html/rfc3280#section-4.2.1.2) and the CA tech support have the excuse that this is a non-critical extension for end certificates. Now, is there a way BCCSP can find the corresponding private key of my certificate on the HSM?


Thanks for the help,

Hello all,
I'm building a university course on Hyperledger Technologies, with focus on Hyperledger Fabric. This course is open source and will be exposed as an Hyperledger Lab.

We try to ensure that we do not do anything which would prevent the code from compiling on platforms supported by Golang.
That being said, the official open source Fabric deliverable is the source code. You are free to use it / compile it how you see fit.
We don't want to be in the business of building and maintaining binaries for every possible platform.

And while we are happy to accept pull requests, historically we find that people will submit a change and then not maintain things going forward.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: huyinsong@...
From: "Brett T Logan"
Sent by: fabric@...
Date: 06/23/2020 11:43PM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Fabric support on MIPS 64 based architecture

Hi Ethan,

You can check out a pull request we had recently around this same request with regard to supporting arm64 which has a lot of information and feedback from the Fabric maintainers: https://github.com/hyperledger/fabric/pull/1086

I think Gari says it best: https://github.com/hyperledger/fabric/pull/1086#issuecomment-615883076

The gist of it is, there haven't been a lot of requests for this, and there is more than just providing the images and binaries. In particular, project contributors and maintainers have to commit to fixing any code that may not work on MIPS. Just publishing the images and binaries isn't enough, without a strong commitment from contributors who have a history of contributing to fabric, moving forward with this request is difficult. Providing official artifacts and support for maintaining the code on MIPS is a much much larger undertaking than most realize.

That being said, major requests like this go through an RFC process that is documented here: https://github.com/hyperledger/fabric-rfcs

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

I am using the following Fabric Versions:
1. Fabric binaries: 1.4.4.
2. Fabric Node SDK version: 1.4.9 (fabric-network, fabric-client, fabric-ca-client).
3. Node.js version: v8.10.0

I wish to perform "query" operation on the channel using Fabric Node SDK, preferably using the "fabric-network" components. I have only 1 peer as the endorsing peer (one that has chaincode installed on it) out of 3 peers in total on the channel for that peer organization. NOTE: I do not have the roles assigned to these peers in the "connection-profile" explicitly and I am using "discovery" to be enabled on the channel. 

I assumed that the SDK function "setEndorsingPeers" from the "transaction.js" module will allow me to dynamically assign role to the peers based upon user input. But when I deep-dived into the Fabric Node SDK code, I saw that, the "evaluate" function in the "transaction.js" calls the default query handler, which sends the proposal randomly to one of the peers using "MSPID_SCOPE_SINGLE" phenomenon.

But because the discovery is enabled, the request may go to dynamically a committing peer, and returns failure. I know one possible solution is to use my custom query handler. But, I wish to identify, if dynamically I can assign endorsing or chaincode query role to channel peers in the Fabric Node SDK (v1.4.9)?

Hi, I'm trying to register a user via Fabric Java SDK but I get the error: "Registration of 'UserToRegister' failed: Error adding identity 'UserToRegister' to the database: attempt to write a readonly database".

To register the user I'm using the certificates of an organization admin previously registerd and enrolled on the same CA. 
The registration was made using the following command (sensible infos are replaced with variables):

fabric-ca-client register -d --id.name Admin@$DOMAIN --id.secret $ADMINPSW --id.type admin --id.attrs "hf.Registrar.Roles=client,hf.Registrar.Attributes=*,hf.Revoker=true,hf.GenCRL=true,admin=true:ecert,abac.init=true:ecert" -u https://ca.$DOMAIN:$CAPORT

And enrolled with:
fabric-ca-client enroll -d -u https://Admin@$DOMAIN:$ADMINPSW@ca.$DOMAIN:$CAPORT

I'm trying to register users with client roles, ad looking at the register command I understand that the Admin@$Domain user can do so, but when I try I get the error above:
Registration of 'UserToRegister' failed: Error adding identity 'UserToRegister' to the database: attempt to write a readonly database

What I'm missing?

Hi all,

Hello David,

 

We are also trying to leverage the chaincode as an external service feature since it brings new possibility of deployment model for chaincode...

I'm also interested in contributing to this feature including integration test.

 

----- Original message -----
From: "David Enyeart" <enyeart@...>
Sent by: fabric@...
To: fabric <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode as an external service
Date: Mon, Jun 22, 2020 5:28 PM
 

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf

Thank you Pancham and Taku for offering to help with the integration test. Sounds like there is interest to keep the feature moving forward. I've sent you both a note with some additional background to get the ball rolling.


Dave Enyeart

taku.shimosawa---06/22/2020 06:08:34 PM---Hello, We started to try the chaincode server feature because we consider the server model is

From: taku.shimosawa@...
To: fabric <fabric@...>
Date: 06/22/2020 06:08 PM
Subject: [EXTERNAL] Re: [EXT] [Hyperledger Fabric] Chaincode as an external service
Sent by: fabric@...

---

Hello,

We started to try the chaincode server feature because we consider the server model is
more suitable when HLF is used with Kubernetes.
I recently contributed to the implementation of the feature in node.js chaincode,
and also am interested in the contribution to the integration tests.

Regards,
Taku Shimosawa

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart

dear Fabric Application Developer,


the next  Fabric Application Developer community call is: Thursday 25th June - 3pm UTC,  4pm UK time (+1), 11am ET (-5 hrs), 8am PT (-8 hrs)  - other time zones here.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Agendas%3A+Fabric+Application+Developer+Community+Call+Meetings  

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts, client apps using the SDKs, tutorials/demos etc -  eg using NodeJS/TypeScript, Java, Go etc etc) 
- helping app developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes

The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1
mahoney@...


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

Thanks Adhav, I think you've assessed correctly. If the client gets two endorsements back it may randomly pick one of the responses to submit and apply both peer endorser signatures. In this case one of endorsed results is different and therefore one of the signatures won't match the results. Upon validation on each peer, the non-matching signature gets thrown out with warning "signature for identity 1 is invalid: The signature is invalid". Half the time org1 endorsement results will be passed, and half the time org2 endorsement results will be passed, hence the inconsistency. A well behaving client should detect the different endorsed results before submitting the transaction to orderer, so that it fails early rather than failing at validation time. I *think* Fabric Network can do that comparison, at least, it should be an option if not already.

As for the questions...

Question 1: I tried this field with both (true/false) value, giving the same result and it is expected. If anyone is able to read PDC then it beat the purpose of having private data. What is the purpose of having this field- "MemberReadOnly"?
                    If we make it false, do other members of org can read data? Does this field relate to signature policy?


Answer 1: PDC specifies which org PEERS are able to persist the private data, and request it from other peers if needed. The access control for CLIENTS may or may not align with that definition. Here's how the documentation explains MemberOnlyRead:
"a value of true indicates that peers automatically enforce that only clients belonging to one of the collection member organizations are allowed read access to private data. If a client from a non-member org attempts to execute a chaincode function that performs a read of a private data key, the chaincode invocation is terminated with an error. Utilize a value of false if you would like to encode more granular access control within individual chaincode functions."


Question2: If transactions require only one endorsement, does SDK(Fabric Network) send tx to all endorsing peers or only one?

Answer 2: With service discovery you can pass in a collection name, and it will return the minimum set of peers required to get an endorsement (one of either org's peers in this scenario). For using Fabric Network Node.js SDK with service discovery, see https://hyperledger.github.io/fabric-sdk-node/master/tutorial-discovery-fabric-network.html. I suspect in this scenario the collection name was not passed correctly to service discovery.


Question 3: If the client gets both endorsements (One is correct and one is wrong(peer from org2 could not read data)) from endorsing peer and client send tx(Having both endorsement response from both peer) to orderer and orderer to committing peer.                         Does Committing peer check only one endorsement or both?

Answer 3: As stated at the top, only one result is submitted, and both signatures are applied. If the endorsing peers signed over different data, then the signature that doesn't match gets thrown out as invalid. This leaves only one endorsement to be evaluated against the endorsement policy. In this scenario, the 'right' endorsement was being provided half the time.


Dave Enyeart