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

Suboptimal Merlin dependency in 1.0.0-pre.3 breaks imports with batch feature #126

Closed
huitseeker opened this issue Apr 16, 2020 · 4 comments

Comments

@huitseeker
Copy link
Contributor

huitseeker commented Apr 16, 2020

Steps to reproduce

Cause

The batch feature activates both merlin and rand, and though the entire dalek suite recently updated its libraries to support a recent flavor of rand, the particular dependency set for merlin currently depends on the source-incompatible rand 0.4.2:

huitseeker@pegasus➜huitseeker/tmp/ed25519-dalek(master✗)» git rev-parse HEAD                                                                                                                                                                                          [15:46:06]
36a51acbf0ca2c10d974940182c0ff63f530c9d3
huitseeker@pegasus➜huitseeker/tmp/ed25519-dalek(master✗)» grep merlin Cargo.toml                                                                                                                                                                                      [15:46:21]
merlin = { version = "1", default-features = false, optional = true, git = "https://github.com/isislovecruft/merlin", branch = "develop" }

Since the demo repository above requires ed25519-dalek by version, the version requirement "wins" against the "conflicting" git attribute, making isislovecruft/merlin@c483190 irrelevant and leading to a resolution of crates-io's merlin 1.3.0.

Fix

The update of the rand dependencies to a version (much) posterior to 0.5 is already in merlin, all that's left is to update the merlin dependency to match.

huitseeker added a commit to huitseeker/ed25519-dalek that referenced this issue Apr 16, 2020
ma2bd pushed a commit to novifinancial/fastpay that referenced this issue Apr 20, 2020
Also introduces a workaround to dalek-cryptography/ed25519-dalek#126 (see workspace Cargo.toml)
asonnino pushed a commit to novifinancial/fastpay that referenced this issue Apr 24, 2020
remove deprecated comments for markdown generation

update README

fix licence line in python files

clean up .pyc file

Rename Libra into Primary

update cargo dependencies (except ed25519-dalek and rand)

Tiny cleanups / wart-removal

Removing env_logger from fastpay_core

Removing log from fastpay_core

Update version dependencies

Also introduces a workaround to dalek-cryptography/ed25519-dalek#126 (see workspace Cargo.toml)
asonnino pushed a commit to novifinancial/fastpay that referenced this issue Apr 25, 2020
remove deprecated comments for markdown generation

update README

fix licence line in python files

clean up .pyc file

Rename Libra into Primary

update cargo dependencies (except ed25519-dalek and rand)

Tiny cleanups / wart-removal

Removing env_logger from fastpay_core

Removing log from fastpay_core

Update version dependencies

Also introduces a workaround to dalek-cryptography/ed25519-dalek#126 (see workspace Cargo.toml)

Update license
@huitseeker
Copy link
Contributor Author

This should be closed by #127 as soon as a corresponding release is issued.

@tarcieri
Copy link
Contributor

tarcieri commented Jul 2, 2020

We're encountering this as well: https://github.com/OLSF/libra/pull/103/checks?check_run_id=825672145

@huitseeker
Copy link
Contributor Author

huitseeker commented Jul 6, 2020

@tarcieri this link is not public I'm afraid.

Until eddsa 1.0.0-pre4 is released, a workaround is to add this to the root Cargo.toml:

[patch.crates-io]
ed25519-dalek = { git = "http://github.com/dalek-cryptography/ed25519-dalek" }

which should not change the ed25519 version fundamentally (the default branch for ed25519 is its release branch), but will force cargo resolution for ed25519 to follow the "git" flavors over the conflicting version number, thereby depending on the particular patched ("gitted") merlin that "works" with the "batch" feature.

tarcieri pushed a commit to 0LNetworkCommunity/libra-legacy-v5 that referenced this issue Jul 7, 2020
0o-de-lally pushed a commit to 0LNetworkCommunity/libra-legacy-v5 that referenced this issue Jul 7, 2020
huitseeker added a commit to huitseeker/diem that referenced this issue Jul 13, 2020
The batch feature is not working due to a combination of:
- dalek-cryptography/ed25519-dalek#126 and:
- our x tooling unifying all features, and throwing batch into the mix as soon as it exists, despite it not being used,
- the new reoslver not being switched on (diem#3134)

A fix has been mered upstream in dalek-cryptography/ed25519-dalek#127 but is not released yet, leaving us bereft of a fixed ed25519_dalek version to point to. We could patch the merlin reference on crates.io, except the fixed merlin version is just at the boundary of a major version, and major version incompatibilities halt patch overrides (rust-lang/cargo#5640).

Since there is tooling that urgently relies on correct version resolution to work and is suggesting the rather extreme measure of putting this technical fix in our formally-verified-crypto fork  (novifinancial/ed25519-dalek-fiat#8), I think we would rather de-activate the feature entirely. A mention of it in code is explicitly left in (with no side effects) as a reminder to reinstate it once either of the following happens:
- we switch to the new resolver,
- a fixed dalek is released,
- x has the ability to not run with all features.
huitseeker added a commit to huitseeker/diem that referenced this issue Jul 13, 2020
The batch feature is not working due to a combination of:
- dalek-cryptography/ed25519-dalek#126 and:
- our x tooling unifying all features, and throwing batch into the mix as soon as it exists, despite it not being used,
- the new reoslver not being switched on (diem#3134)

A fix has been mered upstream in dalek-cryptography/ed25519-dalek#127 but is not released yet, leaving us bereft of a fixed ed25519_dalek version to point to. We could patch the merlin reference on crates.io, except the fixed merlin version is just at the boundary of a major version, and major version incompatibilities halt patch overrides (rust-lang/cargo#5640).

Since there is tooling that urgently relies on correct version resolution to work and is suggesting the rather extreme measure of putting this technical fix in our formally-verified-crypto fork  (novifinancial/ed25519-dalek-fiat#8), I think we would rather de-activate the feature entirely. A mention of it in code is explicitly left in (with no side effects) as a reminder to reinstate it once either of the following happens:
- we switch to the new resolver,
- a fixed dalek is released,
- x has the ability to not run with all features.
@isislovecruft
Copy link
Member

Thanks! I'm about to release a 1.0.0-pre.4 which should resolve this, but feel free to reopen if not.

bors-libra pushed a commit to diem/diem that referenced this issue Jul 14, 2020
The batch feature is not working due to a combination of:
- dalek-cryptography/ed25519-dalek#126 and:
- our x tooling unifying all features, and throwing batch into the mix as soon as it exists, despite it not being used,
- the new reoslver not being switched on (#3134)

A fix has been mered upstream in dalek-cryptography/ed25519-dalek#127 but is not released yet, leaving us bereft of a fixed ed25519_dalek version to point to. We could patch the merlin reference on crates.io, except the fixed merlin version is just at the boundary of a major version, and major version incompatibilities halt patch overrides (rust-lang/cargo#5640).

Since there is tooling that urgently relies on correct version resolution to work and is suggesting the rather extreme measure of putting this technical fix in our formally-verified-crypto fork  (novifinancial/ed25519-dalek-fiat#8), I think we would rather de-activate the feature entirely. A mention of it in code is explicitly left in (with no side effects) as a reminder to reinstate it once either of the following happens:
- we switch to the new resolver,
- a fixed dalek is released,
- x has the ability to not run with all features.

Closes: #5061
Approved by: rexhoffman
lucky-tensor pushed a commit to lucky-tensor/test-lib that referenced this issue Aug 3, 2023
lucky-tensor pushed a commit to lucky-tensor/test-lib that referenced this issue Aug 3, 2023
lucky-tensor pushed a commit to lucky-tensor/test-lib that referenced this issue Aug 3, 2023
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

No branches or pull requests

4 participants
@tarcieri @huitseeker @isislovecruft and others