-
Notifications
You must be signed in to change notification settings - Fork 3
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
Use vsss-rs for share generation and reconstruction #457
Conversation
wip wip get to compile Initial reshard provision and unit test code clean up fix n choose k refactor n choose k Finish tests for reshard add test for boot reshard Add generate reshard input wip wip wip wip Get reshard-renencrypt working Get post share working lint wip Build get reshard output Add new secrets for file key get full thing working e2e refactor wip get qos core to compile Get all of qos core working refactor to not use quorumpubkey wrapper wip Get e2e tests working with new input Add logic for checking that e2e share recombination works finish integration test lint stuff Improve human verifiactions clean up
Upgraded to vsss-rs v4.3.8 64ce106 |
Per discussion in Google Meet, I am removing the legacy (i.e. unfairly-named "insecure") code. This removes backwards compatibility for 1-of-1 shards, and will require us to reshard dev/preprod keys. Prod keys have already been resharded. |
50ca13f
to
605447b
Compare
@lthibault some comments and questions. The removal of the legacy code paths has the effect that this PR cannot land in actively-used contexts of dev/preprod until the resharding there has been done, right? The reason we've labeled the legacy code functions with In c264d9c , you've changed the unit tests by directly replacing the use of the legacy calls with the modern alternative. Unfortunately, that doesn't really make sense here. If you look at the unit test structure, the modern functions are already called directly one line above - the |
Correct. I currently have a resharded dev key (2-of-2), which is now supported as of d87496a.
Oh nice catch. I must have been on autopilot.
Done: d6db3e7 If there's nothing else (and CI passes), I intend to proceed with resharding preprod. |
@lthibault what's the status on this PR? From what I can see, https://github.com/tkhq/mono/pull/3323 exists as a springboard to do testing on preprod, but isn't actually meant to be merged - instead, this PR (#457) would need to land in QOS main, and then mono could bump the QOS submodule. https://github.com/tkhq/namespaces/pull/65 paves the road for mono to actually work with this new PR state that no longer handles 1-of-1 SSS situations, and that's out of the way now. @Ulexus 04b0c11 was a necessary Cargo configuration fix to make this work, right? What about 5ba801e , can/should this stay in as-is, given the https://github.com/tkhq/mono/pull/3397 seems to be related since it aims to un-break the qos handling, but there's probably a followup there that needs some attention.
Can you outline where the danger in this comes from? The host learning sensitive information via printed output on the console that is normally inaccessible to the host, for example, if the PR 3397 in mono seems to related to un-break QOS via a stagex/Linux kernel relevant revert, but there this followup probably still needs some attention. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Posting my partial review from months ago! I'll be taking over this PR; my strategy is going to be: let's break it up into multiple chunks. Some updates made here are very minor cleanup-style items (README updates, stale files); others are very critical (actual vsss-rs libarary).
- BREAKING CHANGE: qos_core: quorum key resharding service, new state machine transitions, and new `ProtocolMsg` variants (#428) | ||
- qos_client: commands to run quorum key resharding and high level documentation (#428) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
428 is a PR that seems closed. Why this mentioned in the context of this PR which is about VSSS?
@@ -50,4 +50,4 @@ COPY --from=file . / | |||
COPY --from=gcc . / | |||
COPY --from=linux-nitro /bzImage . | |||
COPY --from=linux-nitro /nsm.ko . | |||
COPY --from=linux-nitro /linux.config . | |||
COPY --from=linux-nitro /linux.config . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that's a good change? Typically we want a newline at the end of a file, that's how POSIX works: https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline
@@ -0,0 +1 @@ | |||
3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
counter-example here I suppose: this file + the pub keys are fine as-is without a newline because this is more like a binary blob and less like a text file? Depends on what loads this file exactly.
(but if it's all the same, I'd rather end with a newline character)
@@ -0,0 +1,338 @@ | |||
use std::{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we picking this up here? This test is related to a new reshard functionality which isn't related to VSSS afaict?
This change is now split into the following PRs:
|
@cr-tk thank you! I think we can close this PR for clarity. I have no issue with further discussion if needed but given the intent isn't to merge this PR, better to be explicit and close it. Thanks for flagging! |
Summary & Motivation (Problem vs. Solution)
Closes ENG-1687
Note, there is some extra diff in here from running a newer version of clippy. I can work on reverting if this causes issues
How I Tested These Changes
Pre merge check list