Date   

Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Yacov
 

I think that there are factors that people tend to overlook and it leads to frustration and questions such as: "I can do X easily in my cloud environment, why is it so complex to do it in Fabric?"
  1. Blockchains are often deployed in a non fully trusted environment where parties might even be competitors, and have incentives to be covertly malicious.
    This means that you can't assume the existence of a system that has a centralized administration.

    Sure, you can deploy Fabric in a setting where you have an organization that is trusted to perform some functions correctly (did anyone say Crash Fault Tolerant consensus ? ) if the parties in the network agree to it,
    however you wouldn't want a Blockchain project to depend on such a thing because it would severely limit its usefulness and would reduce the business problems it can solve.

    As a direct consequence, there are some things that are easily done in the cloud but are much more complex to do in Fabric, an obvious example would be - you need the consent of several parties to approve policies, and a non obvious example would be, that if you got a "discovery protocol" message from a party (say party A), it is possible that you can't just naively forward it to party B (as is implemented in many cloud native products), because it might be that party B should not even know the fact that you have a business relation with party A in the first place.
  2. It's true that nowadays it is very common to containerize everything and run it on Kubernetes, however to maximize adoption, Fabric should be deployable in every setup: Bare metal, docker compose / swarm, k8s, and the next cloud orchestration engine that is going to come out next year as well.

    Now, since not every user is a security expert, Fabric has to have built in security to protect itself so it can run in the simple primitive deployments where you don't have an Istio mesh to control which containers can communicate and which can't.

    So, these security mechanisms are sometimes not easy to integrate with your advanced environment, but there are efforts to make Fabric more cloud friendly (such as the server-side chaincode model, and the latest external builders which is supposed to give administrators more flexibility in how the chaincode is being run) .
- Yacov



From:        "Brian Behlendorf" <bbehlendorf@...>
To:        fabric@...
Date:        10/31/2019 09:19 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Would libp2p be helpful here?  I had a conversation with someone about how other blockchain projects use it to abstract away some of the issues with using gossip for networking between nodes and how it simplifies the dev experience. 

Brian


On 10/31/19 11:43 AM, Nye Liu wrote:

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

On 10/31/2019 11:38 AM, Alexandre Pauwels wrote:
You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex

On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:
Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:
I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@...wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...>wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.




From:        
arnes_chuzf@...
To:        
fabric@...
Date:        
10/31/2019 03:27 PM
Subject:        
[EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        
fabric@...





Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all


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





Documentation Workgroup: Agenda for Friday, 01 November

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

Hello All,

We hold our regular documentation workgroup call this week, both Eastern and Western hemispheres. Please note that if you're calling in from Europe both calls are an hour earlier this week as the US shifts their clocks this coming weekend.

As is now usual, you can see the new Wiki page : https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

You can read the summary minutes for last week's call and see this week's agenda :https://wiki.hyperledger.org/display/fabric/2019+11+01+DWG+Agenda We've also added an outline agenda for next week's meeting : https://wiki.hyperledger.org/display/fabric/2019+11+08+DWG+Agenda Feel free to add items to this as required.

Best regards,

Anthony, Pam, Joe, Nik

P.S We will include meeting details below for continuity for the next few weeks.

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

Zoom should work in the browser.  We will open the call 5 minutes early so that folks can test it out. We'll also monitor the RocketChat at https://chat.hyperledger.org/channel/fabric-release so that if anyone has issues, ping me there!

More Zoom connection options at the bottom of this note.

The meeting times are as follows:


Meeting 103A: Friday 01 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 103B: Friday 01 Nov
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1500 Greenwich Mean Time
                   1600 Central European Time
                   1700 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

Brian Behlendorf <bbehlendorf@...>
 

Would libp2p be helpful here?  I had a conversation with someone about how other blockchain projects use it to abstract away some of the issues with using gossip for networking between nodes and how it simplifies the dev experience. 

Brian

On 10/31/19 11:43 AM, Nye Liu wrote:

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

On 10/31/2019 11:38 AM, Alexandre Pauwels wrote:
You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex

On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




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


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Nye Liu <nye@...>
 

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

On 10/31/2019 11:38 AM, Alexandre Pauwels wrote:

You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex

On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Alexandre Pauwels
 

You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex


On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Nye Liu <nye@...>
 

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:

There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Alexandre Pauwels
 

There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex


On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Nye Liu <nye@...>
 

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:

Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Yacov
 

My point with 7051 was merely to say that there is only a single port that you need to map via a port forwarding rule in a firewall, not several.




From:        "email4tong@..." <email4tong@...>
To:        
Cc:        fabric@...
Date:        10/31/2019 04:21 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.




From:        
arnes_chuzf@...
To:        
fabric@...
Date:        
10/31/2019 03:27 PM
Subject:        
[EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        
fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan


I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.

And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.

Do you have solution for such issue?

Thank you all








Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

email4tong@gmail.com
 

Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Yacov
 

If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

arnes_chuzf@...
 

Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue? 
 
Thank you all


Docker Image Pulling - ERROR: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority #fabric #docker

soumya nayak <soumyarjnnayak@...>
 

Hi Team,

While pulling the orderer image i am getting the below issue . Any idea ?

Environment - Azure - Ubuntu VM - 16.04 LTS 

```
Pulling orderer3 (hyperledger/fabric-orderer:1.4.3)... ERROR: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority


Channel Registration Failed

White, Spencer (S.)
 

Hello,

I am getting "channel registration failed" when running peer chaincode instantiate, a similar error identified in these two JIRA issues: 
  1. https://jira.hyperledger.org/browse/FAB-14741
  2. https://jira.hyperledger.org/browse/FAB-14638
Any advice? The issues are closed. I am able to deploy a go chaincode in the network, but not a node chaincode.

Node Version: 10.15.3
NPM Version: 6.4.1
Go Version: go1.11 darwin/amd64


Spencer


Invitation to a research oriented blockchain developer conference - Genesis DevCon

Suzana Joel <suzana.joel@...>
 



Hi,

I am Suzana Joel from IBC Media. I'd like to invite you to Genesis DevCon - a blockchain developer conference on the 24th & 25th of November at NSSC, IISc, Bengaluru.

The objective of Genesis DevCon is to educate developers on recent developments in blockchain technology by bringing in some of the brilliant minds from India & across the globe.

There's a special discount for members of the Hyperledger Fabric community.
Coupon Code: GENESIS250
Buy Now
Coupon Code: GENESIS250
Buy Now
I really hope to see you at the conference.

Thanks & regards,
Suzana Joel

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This message and any files or text attached to it are intended only for the recipients named above, contain information that is confidential or privileged. If you are not an intended recipient, you must not read, copy, use or disclose this communication. Please also notify the sender by replying to this message, and then delete all copies of it from your system.


Update: Hyperledger Fabric Node/Java Chaincode/SDK Repository moves

heatherp@...
 

Morning,

Here's an update on moving the node/java chaincode/sdk repositories over to Github for code changes and Azure Pipelines for CI.
 
    Jira
fabric-sdk-java Move complete FABJ-486
fabric-gateway-java Move complete FGJ-48
fabric-sdk-node In progress FABN-1386
fabric-chaincode-java Move complete FAB-16712
fabric-chaincode-node Move complete FAB-16711
 
We are working towards moving fabric-sdk-node across this week, and we'll be in touch with the owners of open CRs in Gerrit to merge these changes, or request them to be re-opened in Githhub as pull requests. We are also in the process of cleaning up any migration issues across the other repositories (e.g. removing Jenkins files, publishing using Azure Pipelines etc) but please let us know if you have issues/spot anything related to the migration via the above jiras, which will be closed when this is complete.

We've also been working through the Jira backlog on all of these repositories to clean up old issues, close duplicates etc - please reach out to me if you need to discuss this further.
 
Thanks,
Heather

Software Engineer, IBM Blockchain
Autism Ambassador
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: Testing nodejs smart contracts without deploying to a network

Ross Tang <tangross@...>
 

Using Jest is very good option, you can easily mocking the context object of contract-api, something like.

const ctx: any = {
stub: {
createCompositeKey: jest.fn(),
deleteState: jest.fn(),
getState: jest.fn(),
putState: jest.fn(),
setEvent: jest.fn(),
getStateByPartialCompositeKey: jest.fn()
}
};
const context = {
stateList: new StateList(ctx, 'entities'),
...ctx
};

ctx.stub.createCompositeKey.mockResolvedValue('entities"en""entId""2019"');
ctx.stub.putState.mockResolvedValue(Buffer.from(''));

And, you can run unit like by directly invoke the transactions, calling the function.

describe('Chaincode Tests', () => {
it('should instantiate', async () =>
cc
.instantiate(context)
.then<any[]>((response: any) => JSON.parse(response))
.then(json =>

That save me great amount of time, in chaincode development. 

Besides, the manual mocking of Jest is very useful, to create mock database. Imagine you are using Commercial Paper example, the stateliest implementation can replaced by mocked database, in json format.

jest.mock('../ledger-api/statelist');

const context: any = {
clientIdentity: {
getMSPID: jest.fn(),
getID: jest.fn(),
getX509Certificate: jest.fn()
},

On 30 Oct 2019, at 5:17 AM, Siddharth Jain <siddjain@...> wrote:

What is the best way to test smart contracts written in nodejs using the fabric-contract-api and without having to deploy to a running network? https://github.com/wearetheledger/fabric-mock-stub seems to be geared towards smart contracts developed using the old fabric-shim API.


Testing nodejs smart contracts without deploying to a network

Siddharth Jain
 

What is the best way to test smart contracts written in nodejs using the fabric-contract-api and without having to deploy to a running network? https://github.com/wearetheledger/fabric-mock-stub seems to be geared towards smart contracts developed using the old fabric-shim API.


Re: CA Keys

Nye Liu <nye@...>
 

Out of band (ssh, scp etc) or via curl/wget http to a non-fabric public CA (e.g. letsencrypt) identified https endpoint.

On 10/29/2019 6:22 AM, Trevor Lee Oakley wrote:

If keys are generated by the CA then what is the best way to distribute these keys?
 
Thanks
Trevor


Attribute 'abac.init' was not found #fabric #fabricca #fabric-ca #fabric-chaincode #fabric-questions

suresh <tedlasuresh@...>
 

Hi all,

While Instantiating the chaincode I am getting following Error

2019-10-29 13:14:40.559 UTC [msp.identity] Sign -> DEBU 04a Sign: plaintext: 0ADE080A6708031A0C08C0F6E0ED0510...30300A000A04657363630A0476736363 
2019-10-29 13:14:40.559 UTC [msp.identity] Sign -> DEBU 04b Sign: digest: 2BEDE393711AA4E8F46F56AB235E79EDC7933B5B8FF8610C9ACFFB3B65390612 
Error: could not assemble transaction, err proposal response was not successful, error code 500, msg transaction returned with failure: Attribute 'abac.init' was not found

But I gave abac.init as true Please find below attachment

Name: admin-org0, Type: admin, Affiliation: , Max Enrollments: -1, Attributes: [{Name:hf.GenCRL Value:true ECert:false} {Name:admin Value:true ECert:true} {Name:abac.init Value:true ECert:true} {Name:hf.Registrar.Roles Value:client ECert:false} {Name:hf.Registrar.Attributes Value:* ECert:false} {Name:hf.Revoker Value:true ECert:false} {Name:hf.EnrollmentID Value:admin-org0 ECert:true} {Name:hf.Type Value:admin ECert:true} {Name:hf.Affiliation Value: ECert:true}]


Can anyone help me out regarding this issue

Thanks
Suresh




4461 - 4480 of 11527