Date   

Re: Hyperledger Fabric Vs Composer ACLs

Brett T Logan <brett.t.logan@...>
 

There is a finite set of resources you can place an ACL on using the following documentation:
 
 
To create more fine-grained control you can do Attribute-based Access Control by specify attributes in the x590 identity which can then be used in chaincode to determine if a user should have access to a specific operation at invocation. You can find that doc here:
 
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Kimheng SOK" <sok.kimheng@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperledger Fabric Vs Composer ACLs
Date: Mon, Nov 18, 2019 3:48 AM
 
Dear all,
 
In Hyperledger Composer Access Control List is define in a file.acl,
Where is the equivalent access control list in Hyperledger Fabric to the one in Composer?
 
Bests,
 


Re: Fabric SDK resource usage spike issue

Michael Wang
 

If you have more info, eg. version, it would be easier to get more useful info from community.


On Mon, Nov 18, 2019 at 2:46 PM Adhav Pavan <adhavpavan@...> wrote:

Hello Team,

We have containerized an express app using fabric node SDK to interact with the blockchain network.

We have deployed this alongside the fabric network on a single VM.

While testing with a certain load, we are observing that express app (fabric SDK) is consuming a lot of CPU and memory resources compared to other fabric components.

What I have observed is that, generating client object and channel object inside invoke-chaincode.js taking 50ms to 200ms collectively(fluctuating).

Could be this reason we have a spike in CPU and memory usage?

Machine Specification:

4 core, 8GB RAM, 256GB SSD


Network Spec:

Two ORG having two peers each, Two CA, one couch DB for each peer, solo orderer.


Thank you.

Regards,
Pavan Adhav

Cell Phone:+91-8390114357  E-Mail: adhavpavan@...



--
This is my life,but world of us~~


Hyperledger Fabric Vs Composer ACLs

Kimheng SOK
 

Dear all,

In Hyperledger Composer Access Control List is define in a file.acl,
Where is the equivalent access control list in Hyperledger Fabric to the one in Composer?

Bests,


Fabric SDK resource usage spike issue

Adhav Pavan
 

Hello Team,

We have containerized an express app using fabric node SDK to interact with the blockchain network.

We have deployed this alongside the fabric network on a single VM.

While testing with a certain load, we are observing that express app (fabric SDK) is consuming a lot of CPU and memory resources compared to other fabric components.

What I have observed is that, generating client object and channel object inside invoke-chaincode.js taking 50ms to 200ms collectively(fluctuating).

Could be this reason we have a spike in CPU and memory usage?

Machine Specification:

4 core, 8GB RAM, 256GB SSD


Network Spec:

Two ORG having two peers each, Two CA, one couch DB for each peer, solo orderer.


Thank you.

Regards,
Pavan Adhav

Cell Phone:+91-8390114357  E-Mail: adhavpavan@...


Re: Extremely strange behavior with Fabric - modifying ledger out of band

Siddharth Jain
 


the resolution is very poor but it contains the steps to repro the issue.


From: David Enyeart <enyeart@...>
Sent: Saturday, November 16, 2019 6:52 AM
To: Siddharth Jain <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band
 

Something else must be going on, since what you've described is not possible. New blocks with validated transactions drive the CouchDB state database updates, never the other way around. Watch the peer log as you make updates and I expect you'll discovery something else going on.

Use a logging string when starting peer such as:
FABRIC_LOGGING_SPEC=info:kvledger,statecouchdb,couchdb=debug


Dave Enyeart

"Siddharth Jain" ---11/15/2019 08:35:29 PM---Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses Co

From: "Siddharth Jain" <siddjain@...>
To: "fabric@..." <fabric@...>
Date: 11/15/2019 08:35 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band
Sent by: fabric@...





Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils.

Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up!

Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre.

Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true.

Can anyone explain this?

e.g., we start with this:


we click on this record which gives


we change createdBy to david and click on save changes button



when we stop and re-start the network

the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!






Re: Extremely strange behavior with Fabric - modifying ledger out of band

David Enyeart
 

Something else must be going on, since what you've described is not possible. New blocks with validated transactions drive the CouchDB state database updates, never the other way around. Watch the peer log as you make updates and I expect you'll discovery something else going on.

Use a logging string when starting peer such as:
FABRIC_LOGGING_SPEC=info:kvledger,statecouchdb,couchdb=debug


Dave Enyeart

"Siddharth Jain" ---11/15/2019 08:35:29 PM---Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses Co

From: "Siddharth Jain" <siddjain@...>
To: "fabric@..." <fabric@...>
Date: 11/15/2019 08:35 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band
Sent by: fabric@...





Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils.

Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up!

Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre.

Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true.

Can anyone explain this?

e.g., we start with this:


we click on this record which gives


we change createdBy to david and click on save changes button



when we stop and re-start the network

the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!






Extremely strange behavior with Fabric - modifying ledger out of band

Siddharth Jain
 

Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils.

Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up!

Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre. 

Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true. 

Can anyone explain this?

e.g., we start with this:


we click on this record which gives


we change createdBy to david and click on save changes button



when we stop and re-start the network

the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!



Re: Python 3 support for #fabric-sdk-node

Gari Singh <garis@...>
 

It was not really a Node SDK limitation but rather a node-gyp issue.  We require node-gyp as we use native modules.  The latest versions of npm ship with versions of node-gyp which support Python 3.5, 3.6 and 3.7.

Can you file a JIRA requesting doc update?
Or of course you can submit the change as well.

/ G

Gari Singh
garis@...
978-846-7499



On Nov 15, 2019, at 3:54 PM, manojkumar.ragupathi@... wrote:


As per the Official Hyperledger Fabric Doc, "The Fabric Node.js SDK requires an iteration of Python 2.7 in order for npm install operations to complete successfully."
As per the https://pythonclock.org/ , "Python 2.7 will not be maintained past 2020. Originally, there was no official date. Recently, that date has been updated to January 1, 2020."

So, Hyperledger Fabric Node SDK, has to support Python 3 soon? Better to go with latest 
Python version, 3.8.0 for long run. 


Re: please create repo

Ry Jones
 

On Fri, Nov 15, 2019 at 6:01 AM Christopher Ferris <chris.ferris@...> wrote:
Ry, per the approved Fabric RFC [1], please create the following repo


Thanks,

Chris


--
Ry Jones
Community Architect, Hyperledger


Python 3 support for #fabric-sdk-node

manojkumar.ragupathi@...
 

As per the Official Hyperledger Fabric Doc, "The Fabric Node.js SDK requires an iteration of Python 2.7 in order for npm install operations to complete successfully."
As per the https://pythonclock.org/ , "Python 2.7 will not be maintained past 2020. Originally, there was no official date. Recently, that date has been updated to January 1, 2020."

So, Hyperledger Fabric Node SDK, has to support Python 3 soon? Better to go with latest 
Python version, 3.8.0 for long run. 


ANNOUNCEMENT: Hyperledger Fabric v1.4.4 is now available!

David Enyeart
 

The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v1.4.4!

Please see the release notes for the list of enhancements and fixes:
https://github.com/hyperledger/fabric/releases/tag/v1.4.4

Download instructions:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/install.html


Thank you,

The Hyperledger Fabric maintainers


Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

Faisal
 

Yes we have tried packaging, signing and then installing on each peer. We also confirmed by listing the chaincodes on both the peers and the IDs matched. The IDs also matched in the previous case as we did a "peer chaincode list --installed" on each peer and compared the IDs of chaincodes.


Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

Gari Singh <garis@...>
 

If you run "install" with the package option on two different machines then instantiation can fail due to the mismatch issue.
Did you try packaging first and then installing the same package on both peers prior to instantiating?

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

-----fabric@... wrote: -----
To: fabric@...
From: "Desktop Dev"
Sent by: fabric@...
Date: 11/15/2019 09:48AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

I can see how that is a problem when we are upgrading the chaincode (Hash might have changed due to the timestamp) but we tried installing and instantiating a chaincode with a different name first on the same channel and then on a different channel and even then we got the same Policy Violation error.


Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

Faisal
 

I can see how that is a problem when we are upgrading the chaincode (Hash might have changed due to the timestamp) but we tried installing and instantiating a chaincode with a different name first on the same channel and then on a different channel and even then we got the same Policy Violation error. 


Re: COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

Gari Singh <garis@...>
 

Looks like you were actually not persisting the storage for your peers (ledger, installed chaincode, etc).

It seems the orderer was still running so the channel already considered the chaincode to be instantiated.

I assume that when you started the peers, you installed the chaincode as well as joined the peer(s) to the channel.

The issue is likely that when you installed the chaincode on the "restarted" peer, the package that was built does not actually match the chaincode that was previously installed and instantiated.


please create repo

Christopher Ferris
 

Ry, per the approved Fabric RFC [1], please create the following repo


Thanks,

Chris


Re: Starting Fabric-CA without providing any root certificate #fabric-ca

shrugupt@...
 

Sorry for the delayed response!

Thank you Gari and Jean-Gaël. This is really helpful clearing my doubt!

On Thu, Oct 24, 2019 at 04:13 AM, Gari Singh wrote:
rtificate is actually not the same although the CN will always be the same unless you actually change it in the config.
You can run `fabric-ca-server init` to generate a default config and then edit the "csr" section of the config.


Proposal : Hyperledger Fabric block archiving

nekia <atsushin@...>
 

Hello everybody,

 

 

I’d like to propose a new feature ‘block archiving’ for Hyperledger Fabric. We are working on this block archiving project which is listed under Hyperledger Labs repository. Our current main efforts are focused on improvement of reliability. If we could get some feedback on our proposed feature from members involved in Hyperledger Fabric implementation, it’ll be quite useful for further improvement of UX.

 

- Hyperledger Fabric Block Archiving

    https://github.com/hyperledger-labs/fabric-block-archiving

 

    This enhancement for Hyperledger Fabric is aiming to:

 

        - Reduce the total amount of storage space required for an organisation to operate a Hyperledger Fabric network by archiving block data into repository.

        - For organisations, operate a Hyperledger Fabric network with low resourced nodes, such as a IoT edge devices for example.

 

- Our proposal

    https://github.com/hyperledger-labs/hyperledger-labs.github.io/blob/master/labs/fabric-block-archiving.md

 

- Technical overview

    https://github.com/nekia/fabric-block-archiving/blob/techoverview/BlockVault%20-%20Technical%20Overview.pdf

 

 

Kind regards,

Atsushi Neki

RocketChat:  nekia

 

Atsushi Neki
Senior Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd

14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9036 M +61 428 223 387
AtsushiN@...
fastware.com.au


Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.


Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.


If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@...


Documentation Workgroup: Agenda for Friday, 15 November

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

Hello All,

We hold our regular documentation workgroup call this week, both Eastern and Western hemispheres.

As is now usual, you can read the summary minutes for last week's call: https://wiki.hyperledger.org/display/fabric/2019+11+08+DWG+Agenda
and catch up via recordings page: https://wiki.hyperledger.org/display/fabric/Recordings

A particular last week was Nick Lincoln's walk through of the Performance website. Many thanks to Nick for a great session and the discussion that followed.

Please feel free to read, and contribute to, the agenda for this week: https://wiki.hyperledger.org/display/fabric/2019+11+15+DWG+Agenda
If you get a chance to review the MSP material from Pam, that would be very helpful too: https://gerrit.hyperledger.org/r/c/fabric/+/34174/

We've also added an outline agenda for next week's meeting : https://wiki.hyperledger.org/display/fabric/2019+11+22+DWG+Agenda

Again, feel free to add items.

Best regards,

Anthony, Pam, Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 105A: Friday 14 Nov
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 105B: Friday 14 Nov
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time


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: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Vipin Bharathan
 

Hello Ivan,
I have been following this thread for a while.
Thanks for raising some of these issues.
While it is important to question and to challenge the assumptions underlying Hyperledger Fabric, the best way to get attention, answers and influence the design may not be by using language like "Major Security hole...". This raises hackles and creates an atmosphere of defensiveness.

First- The issue you raised at first (the salted hash) may be just related to documentation according to all who debated this let us drop that from the list.
So that leaves:
1) hashes on chain cannot be validated by any third party, so they can be used by adversaries to trick honest participants (open)-
The design of private data collections, setup in effect "a covert channel" between the people who exchange that information. I use the term "covert channel" guardedly, before the cryptographers and crypto engineers among us object strenuously to that term. All those who need to know have access to methods to check the hash. Please re-examine this and re-read the private channel documentation. In terms of the veracity of the data (or the claim); this is a problem that has to be solved anyway-in any blockchain; through attestation by the party who put the data on the chain (in other words the issuers of the claim). There are many ways to share these "covert" claims  - Edge architectures with certain proof on the chain and so forth- a la Aries supported by Indy etc.

2) private data use gossip to transact data, which would require all participants be connected with any other participant part of a chain. if there are 20 participants in a channel, each participant must open up their firewalls to all other 19 participants of a single channel (open)

This may not be as it seems as gossip protocols can transmit information using connections to a limited number of "near peers". Overlay this with the three types of nodes (i.e. endorsing peers, validating peers and orderers- with Anchor peers being special types of peers that can serve as the "gateways" for endorsing and validating peers. As far as the orderers, I am not aware of the exact network that they participate in (i.e. is it gossip driven?). Also this interaction can be over TLS which is a widely used method today to protect communications over the open internet. I believe Fabric has this feature.

You have a point about firewalls, the disposition of the components in a regulated enterprise may need some design modifications to accommodate  firewalls. Since Firewalls, whether  on prem or in the cloud are not monolithic (include multiple layers like the DMZ etc.) currently use reverse proxies (for incoming messages) and Socks compliant protocols for outgoing. In Corda Enterprise, there is a component called the "Float" which functions as a reverse proxy. I was involved in conversations around the design of this component, when I was working in a regulated financial institution. I do not know the status of "the float" since that is available only in Enterprise Corda. There are also multiple architectural patterns written up on the provisioning of the components inside firewalls. We need that thought process in fabric if it does not exist.

Another feature that is demanded by IT architecture and security teams in Enterprise are the componentization of nodes. By that I mean the breaking up of (say) any endorsing or validating peer into data access and smart contact execution layers with the possibility of scaling and housing in various parts of the enterprise stack.

All this points to having community involvement in Architecture best practices for projects and the presence and participation in such exercises so that the Fabric team can take advantage of expertise such as yours that exist in the open source community.

We must collaborate, otherwise why be in an open source consortium?

Best,
Vipin

On Wed, Nov 13, 2019 at 10:09 PM Ivan Ch <acizlan@...> wrote:
Hi Yacov

again you are bypassing the question, to be honest I am quiet frustrated now.

the community is not about defending a stance but to find a solution to on going problems, and if something is wrong (which happens frequently in any open source project) we may need to discuss and consider another approach. the current questions about private data listed from various people are listed here:

Security issues
1) hashes put on chain don't have salt added to it, which is vulnerable to dictionary attack (solved)

Methodology issues
1) hashes on chain cannot be validated by any third party, so they can be used by adversaries to trick honest participants (open)
2) private data use gossip to transact data, which would require all participants be connected with any other participant part of a chain. if there are 20 participants in a channel, each participant must open up their firewalls to all other 19 participants of a single channel (open)

Engineering issues:
1) when using k8s and behind load-balancers or proxies, users do not even get a chance to use a shared port (in the aforementioned example, each participant can't even open firewalls to 19 other participants without extensive hacking, and I assumed all participants need to deployed these hacked code to make it work. (discussed)

4241 - 4260 of 11409