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

 

 

 

 

 

 

 

Join fabric@lists.hyperledger.org to automatically receive all group messages.