Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FAB-17177] Config block shouldn't verify itself in block replication #355

Merged
merged 1 commit into from
Dec 3, 2019

Conversation

yacovm
Copy link
Contributor

@yacovm yacovm commented Dec 3, 2019

Type of change

  • Bug fix

Description and additional details

The cluster replication verifies blocks by pulling them in batches,
and performs hash chain verification + verifies the signatures of the last block in the chain.

It uses the bundle stored in the global config structures,
but in case it comes across a config block in the middle of the batch,
it switches to use a bundle constructed from that config block.

However, if the config block is the last block in the batch -
it accidentally verifies it twice:

  • once with the config block before it (as expected)
  • once with the config block itself (which is unexpected).

This change set simply adds a check to see if the last block in the batch
is a config block, and if so - doesn't verify it if it was already verified.

Change-Id: Id123c36e445a21b3081273ef0395aae759162818
Signed-off-by: yacovm yacovm@il.ibm.com

@yacovm yacovm changed the title FAB-17177] Config block shouldn't verify itself in block replication [FAB-17177] Config block shouldn't verify itself in block replication Dec 3, 2019
C0rWin
C0rWin previously approved these changes Dec 3, 2019
The cluster replication verifies blocks by pulling them in batches,
and performs hash chain verification + verifies the signatures of the last block in the chain.

It uses the bundle stored in the global config structures,
but in case it comes across a config block in the middle of the batch,
it switches to use a bundle constructed from that config block.

However, if the config block is the last block in the batch -
it accidentally verifies it twice:
 - once with the config block before it (as expected)
 - once with the config block itself (which is unexpected).

This change set simply adds a check to see if the last block in the batch
is a config block, and if so - doesn't verify it if it was already verified.

Change-Id: Id123c36e445a21b3081273ef0395aae759162818
Signed-off-by: yacovm <yacovm@il.ibm.com>
@yacovm
Copy link
Contributor Author

yacovm commented Dec 3, 2019

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@yacovm yacovm merged commit 9dcb65e into hyperledger:master Dec 3, 2019
@yacovm yacovm deleted the configBlockDoubleVerifyIsBad branch December 3, 2019 15:30
cendhu pushed a commit to cendhu/fabric that referenced this pull request Dec 11, 2019
…yperledger#355)

The cluster replication verifies blocks by pulling them in batches,
and performs hash chain verification + verifies the signatures of the last block in the chain.

It uses the bundle stored in the global config structures,
but in case it comes across a config block in the middle of the batch,
it switches to use a bundle constructed from that config block.

However, if the config block is the last block in the batch -
it accidentally verifies it twice:
 - once with the config block before it (as expected)
 - once with the config block itself (which is unexpected).

This change set simply adds a check to see if the last block in the batch
is a config block, and if so - doesn't verify it if it was already verified.

Change-Id: Id123c36e445a21b3081273ef0395aae759162818
Signed-off-by: yacovm <yacovm@il.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants