Date   

Re: How to get inside docker container and debug code with breakpoints?

David Enyeart
 

Close... some key within the [Group] config has an illegal character. You can see the valid characters here:
https://github.com/hyperledger/fabric/blob/release-1.4/common/configtx/validator.go#L43-L48

I suspect it is this one - keys must "Contain only ASCII alphanumerics, dots '.', dashes '-'"

Unfortunately it looks like the underlying root cause is not printed in the error message. I've opened a bug on your behalf so that the next person to hit it gets a better error message:
https://jira.hyperledger.org/browse/FAB-16940

For cryptic errors, please do open bugs so that they can get improved.


Thanks,

Dave Enyeart

"Nye Liu" ---10/24/2019 08:46:00 PM---I might also add that in this case, the error message and backtrace are actually extremely informat

From: "Nye Liu" <nye@...>
To: fabric@...
Date: 10/24/2019 08:46 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] How to get inside docker container and debug code with breakpoints?
Sent by: fabric@...





I might also add that in this case, the error message and backtrace are actually extremely informative

"Illegal characters in key: [Group]"

I'm guessing it doesn't like the brackets in "[Group]"

"/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:98"

Tells you exactly where the "Failed validating bootstrap block" problem is.

A debugger would absolutely not tell you much more.

On 10/24/2019 5:29 PM, Siddharth Jain wrote:

      Very often I keep into running cryptic errors with Fabric. E.g., today I ran into this:
      2019-10-25 00:20:00.915 UTC [orderer.common.server] Start -> PANI 003 Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]
      panic: Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]

      goroutine 1 [running]:
      github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc000434a50, 0x0, 0x0, 0x0)
      /opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore/entry.go:229 +0x515
      github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).log(0xc00000e1e8, 0xc0002c0c04, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1, 0x0, 0x0, 0x0)
      /opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:234 +0xf6
      github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).Panicf(0xc00000e1e8, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
      /opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:159 +0x79
      github.com/hyperledger/fabric/common/flogging.(*FabricLogger).Panicf(0xc00000e1f0, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
      /opt/gopath/src/github.com/hyperledger/fabric/common/flogging/zap.go:74 +0x60
      github.com/hyperledger/fabric/orderer/common/server.Start(0x1018e03, 0x5, 0xc000437200)
      /opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:98 +0xcd
      github.com/hyperledger/fabric/orderer/common/server.Main()
      /opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
      main.main()
      /opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20

      With these kinds of errors, its not possible to know what caused it just by looking at trace above and I am helpless what to do next. So I am wondering if there is a way for me to log into the container and be able to debug with a debugger (like the way we could do using gdb or ddd)? Would appreciate step by step instructions please which can be followed by a poor man like me (not hand wavy answers)




Re: Join the mailing list

Christopher Ferris
 

visit lists.hyperledger.org and you can sign up with your Linux Foundation ID

Chris

On Oct 24, 2019, at 7:17 PM, Rachid Amine <r.amine35@...> wrote:


Hi, 

  I would like to join the hyperledger  mailing list.

Best regards.

--


Amine Rachid

Ingénieur DevOps
École nationale supérieure d'informatique et d'analyse des systèmes
+212 6 35 80 36 53







Re: How to get inside docker container and debug code with breakpoints?

Nye Liu <nye@...>
 

I might also add that in this case, the error message and backtrace are actually extremely informative


"Illegal characters in key: [Group]"


I'm guessing it doesn't like the brackets in "[Group]"


"/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:98"


Tells you exactly where the "Failed validating bootstrap block" problem is.


A debugger would absolutely not tell you much more.


On 10/24/2019 5:29 PM, Siddharth Jain wrote:

Very often I keep into running cryptic errors with Fabric. E.g., today I ran into this:
2019-10-25 00:20:00.915 UTC [orderer.common.server] Start -> PANI 003 Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]
panic: Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]

goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc000434a50, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore/entry.go:229 +0x515
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).log(0xc00000e1e8, 0xc0002c0c04, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:234 +0xf6
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).Panicf(0xc00000e1e8, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:159 +0x79
github.com/hyperledger/fabric/common/flogging.(*FabricLogger).Panicf(0xc00000e1f0, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/common/flogging/zap.go:74 +0x60
github.com/hyperledger/fabric/orderer/common/server.Start(0x1018e03, 0x5, 0xc000437200)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:98 +0xcd
github.com/hyperledger/fabric/orderer/common/server.Main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20

With these kinds of errors, its not possible to know what caused it just by looking at trace above and I am helpless what to do next. So I am wondering if there is a way for me to log into the container and be able to debug with a debugger (like the way we could do using gdb or ddd)? Would appreciate step by step instructions please which can be followed by a poor man like me (not hand wavy answers)


Re: How to get inside docker container and debug code with breakpoints?

Nye Liu <nye@...>
 

Debuggers are overrated. For this sort of thing you just need better error messages. Fabric is full of very cryptic and non-informative error messages.


go get the repo, add better error reporting code, build it, run it.


I might be in the minority, but in 20+ years of dev I can count the times I've been forced to use a debugger on one hand.


My two sents.

On 10/24/2019 5:29 PM, Siddharth Jain wrote:

Very often I keep into running cryptic errors with Fabric. E.g., today I ran into this:
2019-10-25 00:20:00.915 UTC [orderer.common.server] Start -> PANI 003 Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]
panic: Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]

goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc000434a50, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore/entry.go:229 +0x515
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).log(0xc00000e1e8, 0xc0002c0c04, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:234 +0xf6
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).Panicf(0xc00000e1e8, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:159 +0x79
github.com/hyperledger/fabric/common/flogging.(*FabricLogger).Panicf(0xc00000e1f0, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/common/flogging/zap.go:74 +0x60
github.com/hyperledger/fabric/orderer/common/server.Start(0x1018e03, 0x5, 0xc000437200)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:98 +0xcd
github.com/hyperledger/fabric/orderer/common/server.Main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20

With these kinds of errors, its not possible to know what caused it just by looking at trace above and I am helpless what to do next. So I am wondering if there is a way for me to log into the container and be able to debug with a debugger (like the way we could do using gdb or ddd)? Would appreciate step by step instructions please which can be followed by a poor man like me (not hand wavy answers)


How to get inside docker container and debug code with breakpoints?

Siddharth Jain
 

Very often I keep into running cryptic errors with Fabric. E.g., today I ran into this:
2019-10-25 00:20:00.915 UTC [orderer.common.server] Start -> PANI 003 Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]
panic: Failed validating bootstrap block: initializing configtx manager failed: error converting config to map: Illegal characters in key: [Group]

goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc000434a50, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/zapcore/entry.go:229 +0x515
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).log(0xc00000e1e8, 0xc0002c0c04, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:234 +0xf6
github.com/hyperledger/fabric/vendor/go.uber.org/zap.(*SugaredLogger).Panicf(0xc00000e1e8, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/go.uber.org/zap/sugar.go:159 +0x79
github.com/hyperledger/fabric/common/flogging.(*FabricLogger).Panicf(0xc00000e1f0, 0x103a88e, 0x25, 0xc000413d10, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/common/flogging/zap.go:74 +0x60
github.com/hyperledger/fabric/orderer/common/server.Start(0x1018e03, 0x5, 0xc000437200)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:98 +0xcd
github.com/hyperledger/fabric/orderer/common/server.Main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20

With these kinds of errors, its not possible to know what caused it just by looking at trace above and I am helpless what to do next. So I am wondering if there is a way for me to log into the container and be able to debug with a debugger (like the way we could do using gdb or ddd)? Would appreciate step by step instructions please which can be followed by a poor man like me (not hand wavy answers)


Re: Join the mailing list

Gari Singh <garis@...>
 


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

----- Original message -----
From: "Rachid Amine" <r.amine35@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Join the mailing list
Date: Thu, Oct 24, 2019 7:17 PM
 
Hi, 
 
  I would like to join the hyperledger  mailing list.
 
Best regards.
 
--

 

Amine Rachid

Ingénieur DevOps
École nationale supérieure d'informatique et d'analyse des systèmes
+212 6 35 80 36 53

 
 
 
 
 
 
 
 


Join the mailing list

r.amine35@...
 

Hi, 

  I would like to join the hyperledger  mailing list.

Best regards.

--


Amine Rachid

Ingénieur DevOps
École nationale supérieure d'informatique et d'analyse des systèmes
+212 6 35 80 36 53







Re: Second Channel

White, Spencer (S.)
 

My apologies, the below error:

Error: got unexpected status: BAD_REQUEST -- Unknown consortium name: LoanchainConsortium

Spencer


From: White, Spencer (S.)
Sent: Thursday, October 24, 2019 1:57 PM
To: fabric@... <fabric@...>
Subject: Second Channel
 
Hello,

I am attempting to create a second channel after my test network has already been up and running for awhile. Is it possible to do this? I am encountering the below error and the few comments available suggest spinning my network down and removing volumes. I would prefer to avoid that if possible.

Error: got unexpected status: BAD_REQUEST -- Unknown consortium name: LoanchainConsortium


Sincerely,

Spencer


Second Channel

White, Spencer (S.)
 

Hello,

I am attempting to create a second channel after my test network has already been up and running for awhile. Is it possible to do this? I am encountering the below error and the few comments available suggest spinning my network down and removing volumes. I would prefer to avoid that if possible.

Error: got unexpected status: BAD_REQUEST -- Unknown consortium name: LoanchainConsortium


Sincerely,

Spencer


Re: 回复: [Hyperledger Fabric] #fabric #configtxgen Configtxgen alternative #fabric #configtxgen

Jean-Gaël Dominé <jgdomine@...>
 

Did this discussion take place a long time ago?

I hope it will go beyond the concept then :)


Documentation Workgroup: Agenda for Friday, 25 October

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

Hello All,

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

We moved to the Fabric wiki last week for agenda building and minutes.  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 below and see this week's agenda :https://wiki.hyperledger.org/display/fabric/2019+10+25+DWG+Agenda I've also added an outline agenda for next week's meeting : https://wiki.hyperledger.org/display/fabric/2019+11+01+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.  I will open the call 5 minutes early so that folks can test it out. I'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 102A: Friday 25 Oct
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   1000 Moscow Standard Time
                   0700 Greenwich Mean Time
                   0800 Central European Time    

Meeting 102B: Friday 25 Oct
              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


回复: [Hyperledger Fabric] #fabric #configtxgen Configtxgen alternative #fabric #configtxgen

david liu <david-khala@...>
 

FYI, I have discussed with one of fabric-sdk-node maintainer, in concept-wise it is possible to implement a nodejs version of configtxgen: "see it as an inverse operation of BlockDecoder“

发件人: fabric@... <fabric@...> 代表 Ross Tang <tangross@...>
发送时间: 2019年10月24日 16:16
收件人: Jean-Gaël Dominé <jgdomine@...>
抄送: fabric@... <fabric@...>
主题: Re: [Hyperledger Fabric] #fabric #configtxgen Configtxgen alternative
 
Sorry, I misunderstood the question, giving wrong response.


On 24 Oct 2019, at 2:41 PM, Jean-Gaël Dominé <jgdomine@...> wrote:

That is what I was also thinking but did not know for sure as well.
But when I read your previous post stating:
The creation of genesis block can be done by SDK, along with the use of Fabric CA
I admit I had hope ;)


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

David Enyeart
 

You are essentially suggesting to add a warning that private data content can't be known by non-members of the collection. That is the whole point of private data and anybody considering an implementation will already know this. The non-members only validate against a hash of the data. The members can later share the private data content with non-members if a need-to-know arises, and the non-member can then validate the pre-image content against the hash on chain, with an understanding that only the group of transactors may have come to agreement on the data. This is the fundamental design of private data. Like any feature, It will be fit for some use cases, and not fit for others. I believe these considerations were already obvious, but hopefully this thread has provided some clarification. I am glad the thread has at least helped to improve the documentation around the importance of including a salt in your private data if it is predictable, to keep it secure.


Dave Enyeart

"Ivan Ch" ---10/24/2019 06:02:26 AM---Dave, Yacov, and Alex Seems that the general response to this scenario is “this is an application de

From: "Ivan Ch" <acizlan@...>
To: fabric@...
Date: 10/24/2019 06:02 AM
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@...





Dave, Yacov, and Alex

Seems that the general response to this scenario is “this is an application design problem and should be solved by chaincode”
       
      here is an example:
       my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.
But my argument here is that chaincode design can’t solve this problem, and I can assure you that there is a large number of DLT deployments are at risk because of this.
 
As I stated earlier, hashes cannot be verified by third parties like digital signature or ZKP algorithm.  There is almost no way to guard against adversaries from putting fake data and then trick others to believe the fake data is real.
 
Since chaincode can’t decode hashes so the only thing a chaincode can perform is to limit on number of updates. In most financial use cases (e.g. trade transactions) this is irrelevant since pre-image data are not constants in the first place. Even for constant data such as “national ID” in the aforementioned scenario, chaincode most likely will still allow at least a few updates to cover typos.
 
Leaving it to applications is easier said than done since there are so few ways to get it right and this functionality simply opens door for attackers and yet offers almost nothing.
 
This bug is neither an application design issue nor fabric implementation issue, but a methodology problem that private data feature promotes. My humble recommendation is to depreciate this functionality or at least put warning signs to people still plan to use it





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

Senthil Nathan
 

Hi Ivan,

  

    As far as I know, Blockchain/DLT platform itself does not claim to find fake data. However, one may build an application using blockchain to find fake data. An example from real-world  -- https://www.coindesk.com/new-york-times-confirms-its-using-blockchain-to-combat-fake-news


    Detecting fake data is a hard problem to solve. Some overview of ongoing research can be found here -- https://www.dropbox.com/s/pwoqrlfcyhw13pc/CombatingFakeNews.pdf?dl=0


Regards,

Senthil


On Thu, Oct 24, 2019 at 3:32 PM Ivan Ch <acizlan@...> wrote:

Dave, Yacov, and Alex

Seems that the general response to this scenario is “this is an application design problem and should be solved by chaincode”

 
here is an example: my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.

But my argument here is that chaincode design can’t solve this problem, and I can assure you that there is a large number of DLT deployments are at risk because of this.

 

As I stated earlier, hashes cannot be verified by third parties like digital signature or ZKP algorithm.  There is almost no way to guard against adversaries from putting fake data and then trick others to believe the fake data is real.

 

Since chaincode can’t decode hashes so the only thing a chaincode can perform is to limit on number of updates. In most financial use cases (e.g. trade transactions) this is irrelevant since pre-image data are not constants in the first place. Even for constant data such as “national ID” in the aforementioned scenario, chaincode most likely will still allow at least a few updates to cover typos.

 

Leaving it to applications is easier said than done since there are so few ways to get it right and this functionality simply opens door for attackers and yet offers almost nothing.

 

This bug is neither an application design issue nor fabric implementation issue, but a methodology problem that private data feature promotes. My humble recommendation is to depreciate this functionality or at least put warning signs to people still plan to use it


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

Gari Singh <garis@...>
 

To be clear, the root certificate 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.

-----------------------------------------
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: "shrugupt via Lists.Hyperledger.Org"
Sent by: fabric@...
Date: 10/24/2019 02:30AM
Cc: fabric@...
Subject: [EXTERNAL] [Hyperledger Fabric] Starting Fabric-CA without providing any root certificate

Hi All,

I am using Fabric-CA to generate enrollment and TLS certificates. I am using below command to start the Fabric-CA:

fabric-ca-server start -b admin:adminpw --port 7054

I am not providing any root certificate keypair to Fabric-CA.

Fabric-CA is getting started successfully but I am seeing that Root Certificate is always the same. So, if I have started 2 instances of Fabric-CA- 1 for orderer org and 1 for peer org- root certificate is same for both the organizations. This behavior is consistently same.

Is it mandatory to supply a root certificate to Fabric-CA while starting it? Does it not generate a different root certificate on its own? Am I missing any step?

Thanks & Regards,
Shruti Gupta


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

Ivan Ch <acizlan@...>
 

Dave, Yacov, and Alex

Seems that the general response to this scenario is “this is an application design problem and should be solved by chaincode”

 
here is an example: my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.

But my argument here is that chaincode design can’t solve this problem, and I can assure you that there is a large number of DLT deployments are at risk because of this.

 

As I stated earlier, hashes cannot be verified by third parties like digital signature or ZKP algorithm.  There is almost no way to guard against adversaries from putting fake data and then trick others to believe the fake data is real.

 

Since chaincode can’t decode hashes so the only thing a chaincode can perform is to limit on number of updates. In most financial use cases (e.g. trade transactions) this is irrelevant since pre-image data are not constants in the first place. Even for constant data such as “national ID” in the aforementioned scenario, chaincode most likely will still allow at least a few updates to cover typos.

 

Leaving it to applications is easier said than done since there are so few ways to get it right and this functionality simply opens door for attackers and yet offers almost nothing.

 

This bug is neither an application design issue nor fabric implementation issue, but a methodology problem that private data feature promotes. My humble recommendation is to depreciate this functionality or at least put warning signs to people still plan to use it


Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Ross Tang <tangross@...>
 

Sorry, I misunderstood the question, giving wrong response.


On 24 Oct 2019, at 2:41 PM, Jean-Gaël Dominé <jgdomine@...> wrote:

That is what I was also thinking but did not know for sure as well.
But when I read your previous post stating:
The creation of genesis block can be done by SDK, along with the use of Fabric CA
I admit I had hope ;)


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

Jean-Gaël Dominé <jgdomine@...>
 

Hi,

This is a tricky thing. I had the same issue and it took me a while to figure out the issue.

This is definitely not mandatory to provide the root certificate and the private key to the CA because it will generate them if needed.
BUT (and that's where your issue lies) the provided fabric-ca image was packaged with already a root certificate and a private key... I suppose you always see that example.com issued everything right?

The workaround I found was to delete these two files before starting the CA so that it creates them.
I did it like this:
rm -Rf /etc/hyperledger/fabric-ca-server

Pretty ugly but at least all my CAs use the CN I was defining :)

Hope this helps

JG


Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Jean-Gaël Dominé <jgdomine@...>
 

That is what I was also thinking but did not know for sure as well.
But when I read your previous post stating:
The creation of genesis block can be done by SDK, along with the use of Fabric CA
I admit I had hope ;)


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

shrugupt@...
 

Hi All,

I am using Fabric-CA to generate enrollment and TLS certificates. I am using below command to start the Fabric-CA:

fabric-ca-server start -b admin:adminpw --port 7054

I am not providing any root certificate keypair to Fabric-CA.

Fabric-CA is getting started successfully but I am seeing that Root Certificate is always the same. So, if I have started 2 instances of Fabric-CA- 1 for orderer org and 1 for peer org- root certificate is same for both the organizations. This behavior is consistently same.

Is it mandatory to supply a root certificate to Fabric-CA while starting it? Does it not generate a different root certificate on its own? Am I missing any step?

Thanks & Regards,
Shruti Gupta

4501 - 4520 of 11512