feat(framework): Verify FAB hash on SuperNode #6005
Conversation
Signed-off-by: Patrick Foley <patrick@flower.ai>
psfoley
requested review from
danieljanes,
panh99 and
tanertopal
as code owners
| # Verify the FAB hash | ||
| verified_fab_hash = hashlib.sha256(fab.content).hexdigest() | ||
| if verified_fab_hash != fab.hash_str: | ||
| raise RuntimeError( |
There was a problem hiding this comment.
Note: a RuntimeError is thrown for consistency with SuperLink when it receives a FAB contents that can't be verified: https://github.com/adap/flower/blob/main/framework/py/flwr/superlink/servicer/control/control_servicer.py#L136-L138
There was a problem hiding this comment.
Thanks for pointing me to the ControlServicer. I think there’s a key difference between how it’s run by the SuperLink and how it works here: raising a RuntimeError won’t crash the SuperLink, but in this case, it could crash the SuperNode since the exception is raised in the main thread.
More broadly, one of our goals is to ensure the robustness of the SuperNode, i.e., it shouldn’t crash due to recoverable issues. So, we have two possible approaches here:
- Handle gracefully: Generate an error message as the reply to the original instruction message and suppress the exception, allowing the SuperNode to continue running.
- Fail fast: Crash the SuperNode (either by raising an exception or by setting an exit code and calling the
flwr_exitfunction). Receiving an invalid FAB from the SuperLink could indicate that the SuperLink is compromised, in which case it might not be safe to maintain the connection.
Personally, I lean toward option 2, which is essentially what you’re doing here, but I’m curious to hear your thoughts.
Cc @danieljanes and @jafermarq
github-actions
bot
added
the
Maintainer
No description provided.