-
Notifications
You must be signed in to change notification settings - Fork 55
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
build(deps): update tough requirement from 0.17.1 to 0.18.0 #389
Conversation
Updates the requirements on [tough](https://github.com/awslabs/tough) to permit the latest version. - [Release notes](https://github.com/awslabs/tough/releases) - [Commits](awslabs/tough@tough-v0.17.1...tough-v0.18.0) --- updated-dependencies: - dependency-name: tough dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
@jku FYI - i know you had mentioned dependency issues, looks like tests are passing here? |
the issue is a little complicated. I haven't tried reproducing myself but this seems to be the short of it:
I suppose the test suite does not have his specific situation -- explicit use of reqwest and then use of sigstore-rs api |
OMG, OMG! I found a solution to the awslabs/tough#769 problem that doesn't require any change to the aws/tough crate 🥳 I saw the comment on this PR and I immediately thought the test suite wasn't complete. I started looking into the test suite, but I found these tests are not failing. After a lot of digging I figured it out
A quick recap. Running with sigstore's default features enabled hides the problem: cargo test 'trust::sigstore::tests::trust_root_fetch::cache_1_None' -- --exact --nocapture
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.17s
Running unittests src/lib.rs (target/debug/deps/sigstore-0651a823d35f9ce7)
running 1 test
test trust::sigstore::tests::trust_root_fetch::cache_1_None ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 116 filtered out; finished in 2.36s Running with only the cargo test --no-default-features -F sigstore-trust-root 'trust::sigstore::tests::trust_root_fetch::cache_1_None' -- --exact --nocapture
[long error trace]
failures:
trust::sigstore::tests::trust_root_fetch::cache_1_None
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 64 filtered out; finished in 0.97s I'm going to add a commit to this PR that addresses the failure |
Fetching Sigstore's TUF repository is done using the `aws/tough` crate. This crate is currently using an older version of `reqwest`, which in turn uses an older version of `hyper`. When building the `sigstore` crate with the default features turned off and a limited set of "verification-related" features enabled (like `sigstore-trust-root` and `cosign-rustls-tls`), fetching the TUF repository causes a runtime panic. The panic happens because the old `reqwest` crate is built without TLS support. This was not a problem before, since both sigstore and `tough` used the same version of `reqwest`, hence enabling `cosign-rustls-tls` led to TLS support being enabled also for tough. This commit introduces two new feature flags: `sigstore-trust-root-native-tls` and `sigstore-trust-root-rustl-tls` which enable TLS support also for the old version of reqwest being currently used by tough. Worth of interest, building with the default flags doesn't currently expose this issue. That happens because of a happy coincidence. The "feature chain reaction" is the following one: - The "enable default features" cause the `full-native-tls` feature to be enabled - The `full-native-tls` feature enables `fulcio-native-tls` feature - The `fulcio-native-tls` features enables the `oauth-native-tls` feature - The `oauth-native-tls` features causes the `openidconnect` crate to be required, moreover it enables TLS support of `openidconnect` by enabling the `openidconnect/native-tls` feature. Currently the `openidconnect` crate depends on the same old version of `reqwest` used by aws/tough. Hence, enabling TLS support for `openidconnect` leads to TLS support being enabled also by tough. This coincidental fix is going to disappear as soon as `openidconnect` moves to the latest version of `reqwest`. Signed-off-by: Flavio Castelli <fcastelli@suse.com>
Commit pushed, checkout the commit message for a detailed recap: d80b800 |
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.
This can be merged :D
@Xynnn007 can you please approve the PR? I cannot merge it since I added that commit on top of it |
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.
👏 nice catch! I'm not a cargo expert but this looks reasonable to me.
Updates the requirements on tough to permit the latest version.
Release notes
Sourced from tough's releases.
Commits
ecab7eb
Merge pull request #817 from mgsharm/develop7cf66e9
Prepare for release446a460
Merge pull request #802 from jpculp/rust-1.80.029289de
Merge pull request #778 from flavio/timestamp.json-optional-fields-inside-of-...f2a8cce
fix: timestamp.json meta can has optional fieldsb3f16c9
Update rust dependencies18791c1
Bump rust to stable in actions runner864be9c
Bump cargo-deny in Makefile8fb4469
Merge pull request #780 from jpculp/rust-bumpa313b9f
Bump rust to 1.78.0 in actions runnerDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditions
will show all of the ignore conditions of the specified dependency@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)