Date   

Documentation Workgroup: Agenda for Friday, 28 Feb

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

Hello!

We will hold the documentation workgroup call this Friday as usual -- with both an Eastern hemisphere and Western hemisphere call.

You can read all about last week's call at https://wiki.hyperledger.org/display/fabric/2020+02+21+DWG+Agenda It included a V2 status update from Pam and Joe, a review of the 1.4.5 LTS release, an update on the Deployment guide including CA deployment instructions.  

Thanks again to Joe for recording. Catch up here: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+02+28+DWG+Agenda

Please feel free to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+03+06+DWG+Agenda

Thanks!

Pam, Anthony,  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 117A: Friday 28 Feb
                   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 117B: Friday 28 Feb
              1100 Central Daylight Time
                   1200 Eastern Daylight Time
                   0900 Pacific Daylight Time
                   1400 Brasil Time (BRT)
                   1700 Greenwich Mean Time
                   1800 Central European Time
                   1900 Moscow Standard Tim

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


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 02/28/2020 6:00am-7:00am #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 28 February 2020, 6:00am to 7:00am, (GMT+00:00) Europe/London

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

View Event

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

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


ANNOUNCEMENT: Hyperledger Fabric v2.0.1 is now available!

David Enyeart
 

The first set of fixes on v2.0 is now available. See release notes for details:
https://github.com/hyperledger/fabric/releases/tag/v2.0.1

We expect the next quarterly release v2.1 to be available by end of April.


Thanks,

Dave Enyeart


Re: Doubt in defining an Asset

Matthew White
 

Hi - the world state is a set of key-value pairs - the value can be whatever data format you wish. Marshalling these is part of the job of the client applications.
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Ameya Sinha via Lists.Hyperledger.Org" <t-amsi=microsoft.com@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc: fabric@...
Subject: [EXTERNAL] [Hyperledger Fabric] Doubt in defining an Asset
Date: Wed, Feb 26, 2020 12:02 PM
 

Hi,

 

I had two questions.

 

I wanted to know if it would be possible to define an asset which is self-referential. Also when defining assets such as these, do they work in the traditional way of how we think about self-referential structures? i.e do they store the address of the node but now the address is on the blockchain DB.

 

I’m trying something that would look like –

             

              type playlist struct {

    name       string `json:"name"`

    head       *song `json:"head"`

    nowPlaying *song `json:"nowPlaying"`

}

 

Thanks for any help!

 

Ameya Sinha.

 
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


Doubt in defining an Asset

t-amsi@...
 

Hi,

 

I had two questions.

 

I wanted to know if it would be possible to define an asset which is self-referential. Also when defining assets such as these, do they work in the traditional way of how we think about self-referential structures? i.e do they store the address of the node but now the address is on the blockchain DB.

 

I’m trying something that would look like –

             

              type playlist struct {

    name       string `json:"name"`

    head       *song `json:"head"`

    nowPlaying *song `json:"nowPlaying"`

}

 

Thanks for any help!

 

Ameya Sinha.


回复: [Hyperledger Fabric] Hashing of World State.

david liu <david-khala@...>
 

in what aspect you mean hashing the world state?

发件人: fabric@... <fabric@...> 代表 qwert limframe <qwertlimframe@...>
发送时间: 2020年2月27日 0:00
收件人: hyperledger-fabric@... <hyperledger-fabric@...>
主题: [Hyperledger Fabric] Hashing of World State.
 
Is the World State Hashed?
If yes, though world state is a constantly changing database. why is it hashed?


Hashing of World State.

qwert limframe
 

Is the World State Hashed?
If yes, though world state is a constantly changing database. why is it hashed?


Re: ANNOUNCEMENT: Hyperledger Fabric v1.4.6 is now available!

David Enyeart
 

A few more fixes got merged in the last week, so we went ahead and released Fabric and Fabric CA v1.4.6 today.

https://github.com/hyperledger/fabric/releases/tag/v1.4.6
https://github.com/hyperledger/fabric-ca/releases/tag/v1.4.6



Dave Enyeart

"David Enyeart" ---02/20/2020 08:58:02 AM---Hyperledger Fabric and Fabric CA v1.4.5 are now available. See details of the included fixes in the

From: "David Enyeart" <enyeart@...>
To: fabric <fabric@...>
Date: 02/20/2020 08:58 AM
Subject: [EXTERNAL] [Hyperledger Fabric] ANNOUNCEMENT: Hyperledger Fabric v1.4.5 is now available!
Sent by: fabric@...





Hyperledger Fabric and Fabric CA v1.4.5 are now available. See details of the included fixes in the release notes:
https://github.com/hyperledger/fabric/releases/tag/v1.4.5
https://github.com/hyperledger/fabric-ca/releases/tag/v1.4.5

We have received some questions about LTS release status. v1.4.x continues to be the LTS release and 3rd digit patch releases will continue to be made available on the v1.4.x release stream. Once the maintainers designate a v2.x minor release as the next LTS release, there will be an overlap period where maintenance fixes will continue to be provided for both releases, to allow existing production networks time to perform rolling upgrades.

Thanks to all the community members who reported an issue or provided a fix in the v1.4.5 release! Your efforts help to ensure that Fabric is well tuned for production workloads and operations.


Dave Enyeart
_._,_._,_



回复: [Hyperledger Fabric] #fabric #fabric-questions #fabric-ca #fabric-ca-client

david liu <david-khala@...>
 

Before you blame it to fabric-ca-client, please help to re-test it again with `fabric-ca-client` command tool. 

发件人: fabric@... <fabric@...> 代表 chauhan.kartik25@... <chauhan.kartik25@...>
发送时间: 2020年2月21日 20:15
收件人: fabric@... <fabric@...>
主题: [Hyperledger Fabric] #fabric #fabric-questions #fabric-ca #fabric-ca-client
 

I tried to register & enroll a user with the name 苏南 on Fabric-CA. The registration is getting successful but getting below error during enrollment.

error: [FabricCAClientService.js]: Failed to enroll 苏南, error:%o message=Enrollment failed with errors [[{"code":0,"message":"asn1: invalid UTF-8 string"}]], stack=Error: Enrollment failed with errors [[{"code":0,"message":"asn1: invalid UTF-8 string"}]]

The error clearly says that the letters are not supported in UTF-8 encoding. Can I change the default encoding while enrolling? If yes, which enoding scheme do I've to use to support Chinese letters?

Also, I tried to create a CSR and then a certificate using OpenSSL utility with Chinese letters in CN(CommonName). I was successfully able to create a certificate. So it seems like the issue is with the fabric-ca-client SDK. Is there any way I can add Chinese letters in a certificate while enrolling a user on Hyperledger Fabric?


Re: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

Eryargi, Hakan
 

I see.

 

Then maybe orderer should accept a version it doesn’t recognize only when

 

  1. It’s higher than orderer’s binary version
  2. some –force flag or similar used

 

This way, at least you can give the users a chance to notice and correct their errors instead of making the channel unusable for good.

 

Best,

Hakan

 

From: Joe Alewine <Joe.Alewine@...>
Sent: Monday, 24 February 2020 16:22
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

Hakan,

 

I understand your concern. However, the only way for the ordering service to know about the newest application capability levels is to keep it at the latest binary version. A 1.3 ordering node would not, for example, know about any 1.4.x application capabilities, and would therefore reject even valid ones. I'm not sure that's a better system than what we currently have.

 

Regards,

 

Joe Alewine

IBM Blockchain, Raleigh

 

rocket chat: joe-alewine

slack: joe.alewine

 

 

 

----- Original message -----
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <
hakan.eryargi=accenture.com@...>
Sent by:
fabric@...
To: Joe Alewine <
Joe.Alewine@...>
Cc:
fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Date: Mon, Feb 24, 2020 10:10 AM
 

Hi Joe,

 

Thanks for the clarification. So, there is no way of reverting back from that state except restoring from a backup.

 

I guess it’s a good idea to guard against this at orderer as it’s so easy to make a mistake here, especially regarding capability versions does not necessarily follow Fabric versions.

 

Best,

Hakan

 

From: Joe Alewine <Joe.Alewine@...>
Sent: Monday, 24 February 2020 14:41
To: Eryargi, Hakan <
hakan.eryargi@...>
Cc:
fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

As it says in our conceptual documentation on capabilities:

 

Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability.

 

 

Regards,

 

Joe Alewine

IBM Blockchain, Raleigh

 

rocket chat: joe-alewine

slack: joe.alewine

 

 

 

----- Original message -----
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <
hakan.eryargi=accenture.com@...>
Sent by:
fabric@...
To: Yacov Manevich <
YACOVM@...>
Cc:
fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Date: Mon, Feb 24, 2020 7:29 AM
 

Sure, they are attached.

 

From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:56
To: Eryargi, Hakan <
hakan.eryargi@...>
Cc:
fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

Can you attach logs?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        02/24/2020 01:51 PM
Subject:        Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...





Yup exactly that happened.
 
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
 
Below json path to be more precise:
.channel_group.groups.Application.values.Capabilities.value.capabilities
 
Fabric binary version is 1.4.4 for both peers and orderers.
 
 
From: Yacov Manevich <
YACOVM@...>
Sent: Monday, 24 February 2020 12:45
To: Eryargi, Hakan <
hakan.eryargi@...>
Cc:
fabric@...
Subject: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.



 
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "
fabric@..." <fabric@...>
Cc:        
fabric@...
Date:        02/24/2020 01:41 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        
fabric@...






Hi,

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

Maybe orderers should not accept the value in the first place?

Thanks,
Hakan

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com

 

 

 

 

 

 

 

 


Re: Reverting from incorrect capability version

Jason Yellick <jyellick@...>
 

Unfortunately, this is "working as designed".  We could revisit the validation that ordering does, but the original capabilities concept was to allow independent management of the orderers and peers.  From the documentation:

https://hyperledger-fabric.readthedocs.io/en/release-1.4/capabilities_concept.html

"Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability."

Basically, the idea is to allow you to keep your orderers at an older level, while upgrading your peers and enabling new functionality for them.

As far as recovery goes, your only practical option is to revert to a backup taken before the capability was introduced.  The other option would be to create a custom build of your peer which supports this capability (add an entry with your capability to this map: https://github.com/hyperledger/fabric/blob/add77fa9803c768897f0bbfb9046c64345179de2/common/capabilities/application.go#L50-L60 ) though you would need to maintain this forked code indefinitely.

Thanks,
~Jason

----- Original message -----
From: "Yacov" <yacovm@...>
Sent by: fabric@...
To: hakan.eryargi@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Date: Mon, Feb 24, 2020 6:56 AM
 
Can you attach logs?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        02/24/2020 01:51 PM
Subject:        Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...



Yup exactly that happened.
 
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
 
Below json path to be more precise:
.channel_group.groups.Application.values.Capabilities.value.capabilities
 
Fabric binary version is 1.4.4 for both peers and orderers.
 
 
From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:45
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version

 
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.

 
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "fabric@..." <fabric@...>
Cc:        fabric@...
Date:        02/24/2020 01:41 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...





Hi,

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

Maybe orderers should not accept the value in the first place?

Thanks,
Hakan

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________


www.accenture.com
 



 

 


Re: Reverting from incorrect capability version

Joe Alewine <joe.alewine@...>
 

Hakan,
 
I understand your concern. However, the only way for the ordering service to know about the newest application capability levels is to keep it at the latest binary version. A 1.3 ordering node would not, for example, know about any 1.4.x application capabilities, and would therefore reject even valid ones. I'm not sure that's a better system than what we currently have.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
Sent by: fabric@...
To: Joe Alewine <Joe.Alewine@...>
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Date: Mon, Feb 24, 2020 10:10 AM
 

Hi Joe,

 

Thanks for the clarification. So, there is no way of reverting back from that state except restoring from a backup.

 

I guess it’s a good idea to guard against this at orderer as it’s so easy to make a mistake here, especially regarding capability versions does not necessarily follow Fabric versions.

 

Best,

Hakan

 

From: Joe Alewine <Joe.Alewine@...>
Sent: Monday, 24 February 2020 14:41
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

As it says in our conceptual documentation on capabilities:

 

Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability.

 

 

Regards,

 

Joe Alewine

IBM Blockchain, Raleigh

 

rocket chat: joe-alewine

slack: joe.alewine

 

 

 

----- Original message -----
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
Sent by: fabric@...
To: Yacov Manevich <YACOVM@...>
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Date: Mon, Feb 24, 2020 7:29 AM
 

Sure, they are attached.

 

From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:56
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

Can you attach logs?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        02/24/2020 01:51 PM
Subject:        Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...





Yup exactly that happened.
 
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
 
Below json path to be more precise:
.channel_group.groups.Application.values.Capabilities.value.capabilities
 
Fabric binary version is 1.4.4 for both peers and orderers.
 
 
From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:45
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.



 
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?




From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "
fabric@..." <fabric@...>
Cc:        
fabric@...
Date:        02/24/2020 01:41 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        
fabric@...






Hi,

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

Maybe orderers should not accept the value in the first place?

Thanks,
Hakan

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________


www.accenture.com

 

 

 

 

 

 

 


Re: Reverting from incorrect capability version

Eryargi, Hakan
 

Hi Joe,

 

Thanks for the clarification. So, there is no way of reverting back from that state except restoring from a backup.

 

I guess it’s a good idea to guard against this at orderer as it’s so easy to make a mistake here, especially regarding capability versions does not necessarily follow Fabric versions.

 

Best,

Hakan

 

From: Joe Alewine <Joe.Alewine@...>
Sent: Monday, 24 February 2020 14:41
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

As it says in our conceptual documentation on capabilities:

 

Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability.

 

 

Regards,

 

Joe Alewine

IBM Blockchain, Raleigh

 

rocket chat: joe-alewine

slack: joe.alewine

 

 

 

----- Original message -----
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
Sent by: fabric@...
To: Yacov Manevich <YACOVM@...>
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Date: Mon, Feb 24, 2020 7:29 AM
 

Sure, they are attached.

 

From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:56
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

Can you attach logs?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        02/24/2020 01:51 PM
Subject:        Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...





Yup exactly that happened.
 
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
 
Below json path to be more precise:
.channel_group.groups.Application.values.Capabilities.value.capabilities
 
Fabric binary version is 1.4.4 for both peers and orderers.
 
 
From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:45
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.



 
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "
fabric@..." <fabric@...>
Cc:        
fabric@...
Date:        02/24/2020 01:41 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        
fabric@...






Hi,

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

Maybe orderers should not accept the value in the first place?

Thanks,
Hakan

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________


www.accenture.com

 

 

 

 

 


Re: Reverting from incorrect capability version

Joe Alewine <joe.alewine@...>
 

As it says in our conceptual documentation on capabilities:
 
Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability.
 
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
Sent by: fabric@...
To: Yacov Manevich <YACOVM@...>
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Date: Mon, Feb 24, 2020 7:29 AM
 

Sure, they are attached.

 

From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:56
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

Can you attach logs?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        02/24/2020 01:51 PM
Subject:        Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...





Yup exactly that happened.
 
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
 
Below json path to be more precise:
.channel_group.groups.Application.values.Capabilities.value.capabilities
 
Fabric binary version is 1.4.4 for both peers and orderers.
 
 
From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:45
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version

 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.



 
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "
fabric@..." <fabric@...>
Cc:        
fabric@...
Date:        02/24/2020 01:41 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        
fabric@...






Hi,

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

Maybe orderers should not accept the value in the first place?

Thanks,
Hakan

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________


www.accenture.com



 


Re: Reverting from incorrect capability version

Eryargi, Hakan
 

Sure, they are attached.

 

From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:56
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version

 

Can you attach logs?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        02/24/2020 01:51 PM
Subject:        Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...





Yup exactly that happened.
 
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
 
Below json path to be more precise:
.channel_group.groups.Application.values.Capabilities.value.capabilities
 
Fabric binary version is 1.4.4 for both peers and orderers.
 
 
From: Yacov Manevich <YACOVM@...>
Sent:
Monday, 24 February 2020 12:45
To:
Eryargi, Hakan <hakan.eryargi@...>
Cc:
fabric@...
Subject:
[External] Re: [Hyperledger Fabric] Reverting from incorrect capability version

 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.



 
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        
"Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        
"
fabric@..." <fabric@...>
Cc:        
fabric@...
Date:        
02/24/2020 01:41 PM
Subject:        
[EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        
fabric@...






Hi,

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

Maybe orderers should not accept the value in the first place?

Thanks,
Hakan

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




Re: Reverting from incorrect capability version

Yacov
 

Can you attach logs?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        02/24/2020 01:51 PM
Subject:        Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...




Yup exactly that happened.
 
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
 
Below json path to be more precise:
.channel_group.groups.Application.values.Capabilities.value.capabilities
 
Fabric binary version is 1.4.4 for both peers and orderers.
 
 

From: Yacov Manevich <YACOVM@...>
Sent:
Monday, 24 February 2020 12:45
To:
Eryargi, Hakan <hakan.eryargi@...>
Cc:
fabric@...
Subject:
[External] Re: [Hyperledger Fabric] Reverting from incorrect capability version

 
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.


 
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        
"Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        
"fabric@..." <fabric@...>
Cc:        
fabric@...
Date:        
02/24/2020 01:41 PM
Subject:        
[EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        
fabric@...





Hi,

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

Maybe orderers should not accept the value in the first place?

Thanks,
Hakan

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com





Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version

Eryargi, Hakan
 

Yup exactly that happened.

 

I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.

 

Below json path to be more precise:

.channel_group.groups.Application.values.Capabilities.value.capabilities

 

Fabric binary version is 1.4.4 for both peers and orderers.

 

 

From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:45
To: Eryargi, Hakan <hakan.eryargi@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version

 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.


 

Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "fabric@..." <fabric@...>
Cc:        fabric@...
Date:        02/24/2020 01:41 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...





Hi,
 
Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)
 
For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.
 
If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.
 
Maybe orderers should not accept the value in the first place?
 
Thanks,
Hakan

 



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com



Re: Reverting from incorrect capability version

Yacov
 

Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?



From:        "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...>
To:        "fabric@..." <fabric@...>
Cc:        fabric@...
Date:        02/24/2020 01:41 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version
Sent by:        fabric@...




Hi,
 
Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)
 
For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.
 
If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.
 
Maybe orderers should not accept the value in the first place?
 
Thanks,
Hakan




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




Reverting from incorrect capability version

Eryargi, Hakan
 

Hi,

 

Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)

 

For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.

 

If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.

 

Maybe orderers should not accept the value in the first place?

 

Thanks,

Hakan




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com


Error in Commercial Paper Example

Trevor Lee Oakley <trevor@...>
 

The first part works, then the final commit fails (page 202 of the Fabric 2.0 manual) - 
 
 
 
 peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA} --channelID mychannel --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent
Error: proposal failed with status: 500 - failed to invoke backing implementation of 'CommitChaincodeDefinition': chaincode definition not agreed to by this org (Org1MSP)
ubuntu@ip-10-0-1-151:~/fabric-samples/commercial-paper/organization/magnetocorp$ 
 
I tried switching to Digibank, sourcing the file for that Org and the same error. It seems related to the definition but that was approved. 
 
:~/fabric-samples/commercial-paper/organization/magnetocorp$ peer lifecycle chaincode queryinstalled
Installed chaincodes on peer:
Package ID: cp_0:71f681bb6359681f7bcde58ce3521cd49364409668e361b90255496a0be31bc6, Label: cp_0
ubuntu@ip-10-0-1-151:~/fabric-samples/commercial-paper/organization/magnetocorp$ 
 
What am I missing?