Implement Debug for (ed25519/secp256k1)::(Keypair|SecretKey) #1285
Conversation
This file contains 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
|
We preferably don't want secret keys to be accidentally printed on stdout, ever. |
|
@tomaka I never had the change to tell this but I would like thank you for all the awesome work you did for Rust, specially in the gaming ecosystem |
c410-f3r
force-pushed
the
debug
branch
2 times, most recently
from
f26cc10
to
b600c82
Compare
tomaka
requested changes
Oct 24, 2019
core/src/identity/secp256k1.rs
Outdated
| @@ -51,6 +52,12 @@ impl Keypair { | |||
| } | |||
| } | |||
|
|
|||
| impl fmt::Debug for Keypair { | |||
| fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { | |||
| write!(f, "Keypair {{ secret: \"Secret Key\", public: \"{:?}\" }}", &self.public) | |||
There was a problem hiding this comment.
The Formatter has helpers for outputting structs:
Suggested change
| write!(f, "Keypair {{ secret: \"Secret Key\", public: \"{:?}\" }}", &self.public) | |
| f.debug_struct("Keypair").field("public", &self.public).finish() |
core/src/identity/ed25519.rs
Outdated
| @@ -135,6 +146,12 @@ impl Clone for SecretKey { | |||
| } | |||
| } | |||
|
|
|||
| impl fmt::Debug for SecretKey { | |||
| fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { | |||
| write!(f, "Secret Key") | |||
There was a problem hiding this comment.
Suggested change
| write!(f, "Secret Key") | |
| write!(f, "SecretKey") |
core/src/identity/secp256k1.rs
Outdated
| @@ -70,6 +77,12 @@ impl From<Keypair> for SecretKey { | |||
| #[derive(Clone)] | |||
| pub struct SecretKey(secp256k1::SecretKey); | |||
|
|
|||
| impl fmt::Debug for SecretKey { | |||
| fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { | |||
| write!(f, "Secret Key") | |||
There was a problem hiding this comment.
Suggested change
| write!(f, "Secret Key") | |
| write!(f, "SecretKey") |
core/src/identity/ed25519.rs
Outdated
| @@ -66,6 +67,16 @@ impl Keypair { | |||
| } | |||
| } | |||
|
|
|||
| impl fmt::Debug for Keypair { | |||
| fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { | |||
| write!( | |||
There was a problem hiding this comment.
Suggested change
| write!( | |
| f.debug_struct("Keypair").field("public", &self.0.public).finish() |
Thank you! |
|
Updated |
tomaka
approved these changes
Oct 24, 2019
tomaka
pushed a commit
to tomaka/libp2p-rs
that referenced
this pull request
Nov 6, 2019
tomaka
added a commit
that referenced
this pull request
Nov 6, 2019
* Implement Debug for (ed25519|secp256k1)::(Keypair|SecretKey) (#1285) * Fix possible arithmetic overflow in libp2p-kad. (#1291) When the number of active queries exceeds the (internal) JOBS_MAX_QUERIES limit, which is only supposed to bound the number of concurrent queries relating to background jobs, an arithmetic overflow occurs. This is fixed by using saturating subtraction. * protocols/plaintext: Add example on how to upgrade with PlainTextConfig1 (#1286) * [mdns] - Support for long mDNS names (Bug #1232) (#1287) * Dead code -- commenting out with a note referencing future implementation * Adding "std" feature so that cargo can build in other directories (notably `misc/mdns`, so that I could run these tests) * Permitting `PeerID` to be built from an `Identity` multihash * The length limit for DNS labels is 63 characters, as per RFC1035 * Allocates the vector with capacity for the service name plus additional QNAME encoding bytes * Added support for encoding/decoding peer IDs with an encoded length greater than 63 characters * Removing "std" from ring features Co-Authored-By: Pierre Krieger <pierre.krieger1708@gmail.com> * Retaining MAX_INLINE_KEY_LENGTH with comment about future usage * `segment_peer_id` consumes `peer_id` ... plus an early return for IDs that don't need to be segmented * Fixing logic * Bump most dependencies (#1268) * Bump most dependencies This actually builds 😊. * Bump all dependencies Includes the excellent work of @rschulman in #1265. * Remove use of ed25519-dalek fork * Monomorphize more dependencies * Add compatibility hack for rand Cargo allows a crate to depend on multiple versions of another, but `cargo-web` panics in that situation. Use a wrapper crate to work around the panic. * Use @tomaka’s idea for using a newer `rand` instead of my own ugly hack. * Switch to Parity master as its dependency-bumping PR has been merged. * Update some depenendencies again * Remove unwraps and `#[allow(deprecated)]`. * Remove spurious changes to dependencies Bumping minor or patch versions is not needed, and increases likelyhood of merge conflicts. * Remove some redundant Cargo.toml changes * Replace a retry loop with an expect `ed25519::SecretKey::from_bytes` will never fail for 32-byte inputs. * Revert changes that don’t belong in this PR * Remove using void to bypass ICE (#1295) * Publish 0.13.0 (#1294)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Sidenote: I see a bunch of deprecated functions, Rust 2015 stuff and
std::mem::uninitialized. Is anyone going to update this project?