-
Notifications
You must be signed in to change notification settings - Fork 25
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
[Decrypt script] In case decryption fails for a record, ignore and continue to decrypt #1270
base: main
Are you sure you want to change the base?
Conversation
1caf7d5
to
afbe29c
Compare
afbe29c
to
794c9ae
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1270 +/- ##
==========================================
- Coverage 93.55% 93.54% -0.02%
==========================================
Files 223 223
Lines 37003 37020 +17
==========================================
+ Hits 34620 34632 +12
- Misses 2383 2388 +5 ☔ View full report in Codecov by Sentry. |
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.
Do we still want to use this command to verify end-to-end encryption cycle with iOS/Android? Swallowing errors may prevent us from catching issues here. Maybe we should provide an extra flag (disabled by default) that will instruct the CLI to skip over malformed reports
ipa-core/src/cli/crypto.rs
Outdated
trigger_value, | ||
)?; | ||
} | ||
_ => println!("Decryption failed for record no {idx}"), |
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.
_ => println!("Decryption failed for record no {idx}"), | |
_ => eprintln!("Decryption failed for record no {idx}"), |
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.
FYI I ended up not adding a flag for this as this is useful information while decrypting rows @akoshelev
Yes, let me add a flag to do this. Having said that, is there a way to "throw away" non-decryptable records while running query today @akoshelev ? |
I'm not convinced this is the right approach. For example, if different records are not decryptable across helpers, it will result in errors downstream or potentially just incorrect results. Moreover, decryption happens independently across helpers, so there would be some need for helpersto align o. which events they dropped. I think we should instead require the report collector to only include events encrypted towards a given HPN to be submitted, and to panic if any are not decryptable. |
Just wanted to check the purpose of this decrypt script? I assume it is for our own testing as a validation step before we can run a real test (where we won't be able to use this script due to no access to private keys). While testing our integration, before this change, the script just returned an error. However, it was able to decrypt most of them except a few rows due to public key mismatch. With this change, hoping we can get to finer details with a single run. And we can gate this with an argument as Alex suggested. WDYT? |
it's concerning to me that we wouldn't know what keys an event was encrypted with. this util is to assist with testing, and it doesn't aid in that functionality if it succeeds on files that would fail given this is a testing util, we could provide better error handling, such as notifying the user as to which reports were not decryptable. |
We don't have it currently, but we discussed it with @danielmasny and this should be eventually in our roadmap. It requires communication across helpers, but generally they should be able to tell others to toss certain reports away. There should be some limits on this functionality (what if one helpers tells others to remove everything but two), but generally it is desirable to have I think |
it makes sense to eventually support (bits will inevitably get flipped occasionally). until we have that functionality, I think we should keep this util |
There are several things we would need, one is to sync with the other helpers that the report should be ignored. The second is that we also need to check the shares for consistency, i.e. both helper decrypt the same share. It would be quite bad if the whole query fails just because of a single bad report. |
1e0395b
to
9baca44
Compare
4e68877
to
bd65cb5
Compare
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.
a few comments below, but this approach works much better. we need to make sure we log all the errors, and we may even want to differentiate the case where a given row is un-decryptable by all 3 helpers vs only an individual helper.
ipa-core/src/cli/crypto.rs
Outdated
)?; | ||
} | ||
// error handling in case decryption failed | ||
(Err(e1), _, _) => { |
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.
this will end up only matching one of the errors, but it's probably useful to log all 3 if they fail, right?
ipa-core/src/cli/crypto.rs
Outdated
} | ||
// error handling in case decryption failed | ||
(Err(e1), _, _) => { | ||
writeln!(writer, "Decryption failed Record: {idx} Reason:{e1}",)?; |
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.
do we actually want to write these to the file?
ipa-core/src/cli/crypto.rs
Outdated
|
||
for (dec_report1, (dec_report2, dec_report3)) in | ||
decrypted_reports1.zip(decrypted_reports2.zip(decrypted_reports3)) | ||
let mut first_error = Ok(()); |
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.
what is this for?
ipa-core/src/cli/crypto.rs
Outdated
breakdown_key, | ||
trigger_value, | ||
)?; | ||
match (dec_report1, dec_report2, dec_report3) { |
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.
it may make sense to check each for errors explicitly up top, so that we make sure we log all 3. we'll want to make sure that all 3 are not decryptable. the suggestion is just a sketch, don't merge it directly.
match (dec_report1, dec_report2, dec_report3) { | |
if dec_report1.is_err() { # log here } | |
if dec_report2.is_err() { # log here } | |
if dec_report3.is_err() { # log here } | |
match (dec_report1, dec_report2, dec_report3) { | |
(Ok(dec_report1), Ok(dec_report2), Ok(dec_report3)) => { ... } | |
_ => { ... } | |
} |
move error printing into iterator trait
fix clippy error
In case a record fails decryption, we will log it on the console and the output file. However, we will let the processing complete for all the records before erroring out completely.
File output
Console output
FYI: i ended up not adding a flag for this as this is useful information while running a script