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

FILE-613: retrieve private key always #340

Merged
merged 1 commit into from
Sep 24, 2024

Conversation

LukasPukenis
Copy link
Collaborator

@LukasPukenis LukasPukenis commented Jul 29, 2024

Private key retrieval was previously done on device::new() once and stored, however API users sometimes hcange the private key and need to recreate libdrop instance. However it's no tthe ideal way of doing things and thus this PR just queries for the private key each time it needs.

@LukasPukenis LukasPukenis requested a review from a team as a code owner July 29, 2024 14:44
@LukasPukenis LukasPukenis changed the title File 613 retrieve private key always FILE-613: retrieve private key always Jul 29, 2024
norddrop/src/device.rs Outdated Show resolved Hide resolved
norddrop/src/device.rs Outdated Show resolved Hide resolved
norddrop/src/device.rs Outdated Show resolved Hide resolved
@LukasPukenis LukasPukenis force-pushed the FILE-613_retrieve_private_key_always branch 2 times, most recently from ba6b4eb to b71daed Compare July 30, 2024 09:19
Lipt0nas
Lipt0nas previously approved these changes Jul 30, 2024
Copy link
Member

@Lipt0nas Lipt0nas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good from my side, don't know if we want to wait for Mateusz to return from vacation about the mutex question

norddrop/src/device.rs Outdated Show resolved Hide resolved
norddrop/src/device.rs Outdated Show resolved Hide resolved
norddrop/src/device.rs Outdated Show resolved Hide resolved
norddrop/src/uni.rs Outdated Show resolved Hide resolved
@LukasPukenis LukasPukenis force-pushed the FILE-613_retrieve_private_key_always branch from b71daed to 4216f84 Compare September 23, 2024 06:46
@LukasPukenis LukasPukenis force-pushed the FILE-613_retrieve_private_key_always branch from 4216f84 to 2dd815e Compare September 23, 2024 09:07
@LukasPukenis LukasPukenis force-pushed the FILE-613_retrieve_private_key_always branch 2 times, most recently from 8ab40ac to 52a7f91 Compare September 23, 2024 09:18
@LukasPukenis
Copy link
Collaborator Author

@matszczygiel addressed the comments

matszczygiel
matszczygiel previously approved these changes Sep 23, 2024
Copy link
Contributor

@matszczygiel matszczygiel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, however, I am not sure about dropping the mutex around privkey()

@LukasPukenis LukasPukenis force-pushed the FILE-613_retrieve_private_key_always branch 2 times, most recently from da0c702 to c30cbeb Compare September 23, 2024 10:56
Previously it was cached after the first call
and it so happens that the key might
sometimes change. Due to FFI layer issues, Libdrop
instance cannot be destroyed and recreated
thus leaving the only solution either a new API
or the easier one - passing KeyStore in Arc<>
and calling when needed.

Signed-off-by: Lukas Pukenis <[email protected]>
@LukasPukenis LukasPukenis force-pushed the FILE-613_retrieve_private_key_always branch from c30cbeb to 9704105 Compare September 23, 2024 10:59
@LukasPukenis
Copy link
Collaborator Author

All comments addressed @Lipt0nas @matszczygiel . I gave a pipeline build to Windows to test. The tests failing in natlab are due to flakyness

@LukasPukenis LukasPukenis merged commit 4576bd6 into main Sep 24, 2024
11 of 13 checks passed
@LukasPukenis LukasPukenis deleted the FILE-613_retrieve_private_key_always branch September 24, 2024 07:21
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