fix: potential attack risks in storage module #114
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fynnss
force-pushed
the
fynn/fix_potential_attack_risks_in_storage_module
branch
from
65eee0a to
5d30dd6
Compare
fynnss
force-pushed
the
fynn/fix_potential_attack_risks_in_storage_module
branch
from
20161ff to
ffef26d
Compare
joeylichang
approved these changes
Mar 17, 2023
j75689
approved these changes
Mar 17, 2023
This was referenced Mar 17, 2023
Closed
Closed
This was referenced Mar 17, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fix potential attack risks in storage module
Rationale
After SecondarySP stores redundant data, it needs to hand over the signature to PrimarySP, and PrimarySP sends SealObject to the chain. The chain checks SecondarySP's signature to confirm that it has received the data sent by PrimarySP and stored it completely.
Previously, the only fields that SecondarySP signed were the SP address and checksum. When two objects with the same content were uploaded, PrimarySP could act maliciously by not sending the data to SecondarySP, and instead use the signature of the previous object to complete the seal action of the object and then instruct them to challenge SecondarySP to lower the quality of their service and profit from it.
Example
NA
Changes
Notable changes: