-
Notifications
You must be signed in to change notification settings - Fork 287
[Alternative] Allow deserializing from owned types #218
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
Closed
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
use core::fmt; | ||
use core::marker::PhantomData; | ||
use core::str::{self, FromStr}; | ||
use serde::de; | ||
|
||
pub struct HexVisitor<T> { | ||
expectation: &'static str, | ||
_pd: PhantomData<T>, | ||
} | ||
|
||
impl<T> HexVisitor<T> { | ||
pub fn new(expectation: &'static str) -> Self { | ||
HexVisitor { | ||
expectation, | ||
_pd: PhantomData, | ||
} | ||
} | ||
} | ||
|
||
impl<'de, T> de::Visitor<'de> for HexVisitor<T> | ||
where | ||
T: FromStr, | ||
<T as FromStr>::Err: fmt::Display, | ||
{ | ||
type Value = T; | ||
|
||
fn expecting(&self, formatter: &mut fmt::Formatter) -> fmt::Result { | ||
formatter.write_str(self.expectation) | ||
} | ||
|
||
fn visit_bytes<E: de::Error>(self, v: &[u8]) -> Result<Self::Value, E> { | ||
if let Ok(hex) = str::from_utf8(v) { | ||
FromStr::from_str(hex).map_err(E::custom) | ||
} else { | ||
Err(E::invalid_value(de::Unexpected::Bytes(v), &self)) | ||
} | ||
} | ||
|
||
fn visit_str<E: de::Error>(self, v: &str) -> Result<Self::Value, E> { | ||
FromStr::from_str(v).map_err(E::custom) | ||
} | ||
} | ||
|
||
pub struct BytesVisitor<F> { | ||
expectation: &'static str, | ||
parse_fn: F, | ||
} | ||
|
||
impl<F, T, Err> BytesVisitor<F> | ||
where | ||
F: FnOnce(&[u8]) -> Result<T, Err>, | ||
Err: fmt::Display, | ||
{ | ||
pub fn new(expectation: &'static str, parse_fn: F) -> Self { | ||
BytesVisitor { | ||
expectation, | ||
parse_fn, | ||
} | ||
} | ||
} | ||
|
||
impl<'de, F, T, Err> de::Visitor<'de> for BytesVisitor<F> | ||
where | ||
F: FnOnce(&[u8]) -> Result<T, Err>, | ||
Err: fmt::Display, | ||
{ | ||
type Value = T; | ||
|
||
fn expecting(&self, formatter: &mut fmt::Formatter) -> fmt::Result { | ||
formatter.write_str(self.expectation) | ||
} | ||
|
||
fn visit_bytes<E: de::Error>(self, v: &[u8]) -> Result<Self::Value, E> { | ||
(self.parse_fn)(v).map_err(E::custom) | ||
} | ||
} |
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.
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.
Seems like this is encouraging user to serialize their secrets. Do we really want to be doing that?
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.
As an alternative, we could provide a module so users have to explicitly opt-in to this by saying
#[serde(with = "secp256k1::serde::secret_key")]
. This has the downside that we need to provide a module forOption
andVec
as well if we want it to work out of the box with those containers.However, I am not sure if this makes things actually better? Some situations require secret keys to be serialized (a backup functionality for example). Additionally,
SecretKey
also implementsDebug
andDisplay
which are basically the same.I am not convinced that we should be introducing a policy on this abstraction level. Whether or not serializing a secret key is dangerous depends completely on the application.
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'll just note that this is already the case: https://docs.rs/secp256k1/0.20.0/secp256k1/key/struct.SecretKey.html#impl-Serialize
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.
(At least as long as we don't have HD derivation natively in this library), serializing secret keys is essential. Keys need to be stored.
In one case, the caller has the secret key in serialized form already and just passes it to the library. Then letting the user serialize keys won't hurt either.
In the other case, the caller relies on the library to generate (or tweak) keys. Then it's essential to serialize them for storage.
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.
Yeah, concept ACK having serialization. You need to store secret key material somehow.
This PR needs a rebase though.