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

Bump most dependencies #1268

Merged
merged 22 commits into from
Oct 31, 2019
Merged

Bump most dependencies #1268

merged 22 commits into from
Oct 31, 2019

Conversation

Demi-Marie
Copy link
Contributor

This actually builds 😊.

@tomaka
Copy link
Member

tomaka commented Oct 10, 2019

For libp2p-core, I'd actually prefer to do something like this:

diff --git a/core/Cargo.toml b/core/Cargo.toml
index db014ec0..9d9fb5d6 100644
--- a/core/Cargo.toml
+++ b/core/Cargo.toml
@@ -13,7 +13,7 @@ categories = ["network-programming", "asynchronous"]
 asn1_der = "0.6.1"
 bs58 = "0.2.0"
 bytes = "0.4"
-ed25519-dalek = "1.0.0-pre.1"
+ed25519-dalek = "1.0.0-pre.2"
 failure = "0.1"
 fnv = "1.0"
 lazy_static = "1.2"
@@ -25,7 +25,7 @@ futures = "0.1"
 parking_lot = "0.8"
 protobuf = "2.3"
 quick-error = "1.2"
-rand = "0.6"
+rand = "0.7"
 rw-stream-sink = { version = "0.1.1", path = "../misc/rw-stream-sink" }
 libsecp256k1 = { version = "0.2.2", optional = true }
 sha2 = "0.8.0"
@@ -46,7 +46,7 @@ libp2p-swarm = { version = "0.2.0", path = "../swarm" }
 libp2p-tcp = { version = "0.12.0", path = "../transports/tcp" }
 libp2p-mplex = { version = "0.12.0", path = "../muxers/mplex" }
 libp2p-secio = { version = "0.12.0", path = "../protocols/secio" }
-rand = "0.6"
+rand = "0.7"
 quickcheck = "0.8"
 tokio = "0.1"
 wasm-timer = "0.1"
diff --git a/core/src/identity/ed25519.rs b/core/src/identity/ed25519.rs
index 1c6662c2..d1a2cbf1 100644
--- a/core/src/identity/ed25519.rs
+++ b/core/src/identity/ed25519.rs
@@ -22,6 +22,7 @@
 
 use ed25519_dalek as ed25519;
 use failure::Fail;
+use rand::RngCore;
 use super::error::DecodingError;
 use zeroize::Zeroize;
 
@@ -31,7 +32,9 @@ pub struct Keypair(ed25519::Keypair);
 impl Keypair {
     /// Generate a new Ed25519 keypair.
     pub fn generate() -> Keypair {
-        Keypair(ed25519::Keypair::generate(&mut rand::thread_rng()))
+        let mut bytes = [0u8; 64];
+        rand::thread_rng().fill_bytes(&mut bytes);
+        Keypair(ed25519::Keypair::from_bytes(&bytes).unwrap())
     }
 
     /// Encode the keypair into a byte array by concatenating the bytes
@@ -138,7 +141,9 @@ impl Clone for SecretKey {
 impl SecretKey {
     /// Generate a new Ed25519 secret key.
     pub fn generate() -> SecretKey {
-        SecretKey(ed25519::SecretKey::generate(&mut rand::thread_rng()))
+        let mut bytes = [0u8; 32];
+        rand::thread_rng().fill_bytes(&mut bytes);
+        SecretKey(ed25519::SecretKey::from_bytes(&bytes).unwrap())
     }
 
     /// Create an Ed25519 secret key from a byte slice, zeroing the input on success.

@tomaka
Copy link
Member

tomaka commented Oct 10, 2019

I derp'ed, as you can't build a valid Keypair from a random 64 bytes array. But you can generate a SecretKey, then deduce the corresponding PublicKey.

diff --git a/core/src/identity/ed25519.rs b/core/src/identity/ed25519.rs
index ea7d957d..b9b95162 100644
--- a/core/src/identity/ed25519.rs
+++ b/core/src/identity/ed25519.rs
@@ -32,9 +32,7 @@ pub struct Keypair(ed25519::Keypair);
 impl Keypair {
     /// Generate a new Ed25519 keypair.
     pub fn generate() -> Keypair {
-        let mut bytes = [0u8; 64];
-        rand::thread_rng().fill_bytes(&mut bytes);
-        Keypair(ed25519::Keypair::from_bytes(&bytes).unwrap())
+        Keypair::from(SecretKey::generate())
     }
 
     /// Encode the keypair into a byte array by concatenating the bytes

@romanb
Copy link
Contributor

romanb commented Oct 11, 2019

What is the relationship of this PR to #1268? Also, is it really a good idea to pin library dependencies to patch versions? As far as I'm aware, that is not desirable for a library, as it prevents consumers of the library from using the latest patch releases.

@tomaka
Copy link
Member

tomaka commented Oct 11, 2019

I'm going to merge #1265 as it came first and causes the least amount of conflicts with the stable-futures branch.

The only argument in favour of mentioning a patch version is that we might be inadvertently using a feature that has been added in a patch version of a crate (which theoretically shouldn't happen for crates after version >1.0.0, but we're mostly using crates v0.x.y).

On the other hand, backporting this PR to stable-futures might be hell on earth.

Also update the code to the latest Rust edition.
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.
instead of my own ugly hack.
@Demi-Marie
Copy link
Contributor Author

@tomaka your patch was far, far cleaner than my idea. Thank you.

Copy link
Contributor

@rphmeier rphmeier left a comment

Choose a reason for hiding this comment

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

i'm not a libp2p expert, but it seems fine except for the unwrap call.

@tomaka
Copy link
Member

tomaka commented Oct 25, 2019

I don't know how much of an effort it is, but if possible I'd prefer to undo all the "minor/patch" version bumps (e.g. foo 0.1.2 to 0.1.3).
As I repeat every time someone makes this kind of PR, they are useless, and will heavily conflict with the stable-futures branch.

Additionally, #1275 should have updated the Rust protobuf files, so I would expect this PR to not touch them.

`ed25519::SecretKey::from_bytes` will never fail for 32-byte inputs.
@Demi-Marie
Copy link
Contributor Author

@rphmeier can you re-review this PR?

Copy link
Member

@tomaka tomaka left a comment

Choose a reason for hiding this comment

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

I know I'm annoying, but a PR that bumps dependencies should just bump dependencies, and not add these <'_> everywhere or attempt to fix warnings.
One pull request = one change, with some minor tolerance.

core/src/peer_id.rs Outdated Show resolved Hide resolved
protocols/noise/src/io/handshake.rs Outdated Show resolved Hide resolved
muxers/yamux/Cargo.toml Outdated Show resolved Hide resolved
@tomaka tomaka removed the request for review from rphmeier October 31, 2019 16:14
@tomaka tomaka dismissed rphmeier’s stale review October 31, 2019 17:29

Resolved; asked him by DM if I could dismiss

@tomaka tomaka merged commit 979c820 into libp2p:master Oct 31, 2019
@Demi-Marie Demi-Marie deleted the demi-upgrade-deps branch October 31, 2019 21:08
tomaka pushed a commit to tomaka/libp2p-rs that referenced this pull request Nov 6, 2019
* Bump most dependencies

This actually builds 😊.

* Bump all dependencies

Includes the excellent work of @rschulman in libp2p#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
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants