Update dependencies#460
Conversation
📝 WalkthroughWalkthroughThis PR upgrades the rust-s3 workspace to Rust 1.88.0 MSRV. It bumps dependencies including hmac, quick-xml, reqwest, sha2, and minidom across the crates. Source code is updated to use the new ChangesDependency Upgrade and MSRV Specification
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Brownian Motion (Brass)Recommendation: Refactor Summary: Dependency updates are sound but lack clear justification for MSRV changes. Highlights
Unknowns
Next actions
Reflection questions
|
MSRV impact is listed in PR summary. No impact. MSRV remains as 1.88.0. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@s3/Cargo.toml`:
- Line 100: The crate enables the tokio-rustls-tls feature with
reqwest/rustls-no-provider which requires callers to initialize a process-level
CryptoProvider before any TLS connections; update examples/tokio-backend.rs and
relevant documentation to show calling CryptoProvider::install_default() (for
example via rustls::crypto::ring::default_provider().install_default()) during
startup so code using the tokio-rustls-tls feature won't panic with "no
process-level CryptoProvider available."
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e6e5d851-44e1-4498-b831-44866bad4f60
📒 Files selected for processing (6)
aws-creds/Cargo.tomlaws-region/Cargo.tomls3/Cargo.tomls3/src/post_policy.rss3/src/request/request_trait.rss3/src/signing.rs
|
|
||
| tokio-native-tls = ["aws-creds/native-tls", "reqwest/native-tls", "with-tokio"] | ||
| tokio-rustls-tls = ["aws-creds/rustls-tls", "reqwest/rustls-tls", "with-tokio"] | ||
| tokio-rustls-tls = ["aws-creds/rustls-tls", "reqwest/rustls-no-provider", "with-tokio"] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether a rustls CryptoProvider is explicitly installed in the codebase.
rg -n -C2 'install_default|CryptoProvider|rustls::crypto|aws_lc_rs|ring::default_provider' --type rust
# Verify all reqwest rustls feature usages in manifests.
rg -n -C2 'reqwest/.*rustls' --type tomlRepository: durch/rust-s3
Length of output: 340
🌐 Web query:
For reqwest 0.13, what does the rustls-no-provider feature require at runtime, and does it require explicit CryptoProvider installation?
💡 Result:
The rustls-no-provider feature in reqwest 0.13 enables rustls TLS without automatically including or activating a specific crypto provider (like aws-lc-rs or ring), unlike the default rustls feature which includes rustls-aws-lc-rs[1][2][3]. It still depends on rustls-platform-verifier for platform root certificates[1][3]. At runtime, since no crypto provider is automatically installed by this feature, rustls requires a CryptoProvider to be available, either via a process-global default set by CryptoProvider::install_default() (called early in the application, e.g., using rustls::crypto::ring::default_provider().install_default() or similar)[4][5], or by explicitly passing one when building the ClientConfig (e.g., via ClientConfig::builder_with_provider())[4][6]. Without this, attempts to use TLS will panic with "no process-level CryptoProvider available -- call CryptoProvider::install_default before this point"[7][8]. Thus, yes, it requires explicit CryptoProvider installation (process-global or per-config) at runtime for correct operation[2][9][7][4].
Citations:
- 1: https://docs.rs/crate/reqwest/^0.13.1/features
- 2: https://github.com/seanmonstar/reqwest/releases/tag/v0.13.0
- 3: https://docs.rs/crate/reqwest/latest/features
- 4: https://docs.rs/rustls/latest/rustls/crypto/struct.CryptoProvider.html
- 5: https://rustls.dev/docs/crypto/struct.CryptoProvider.html
- 6: https://docs.rs/rustls-platform-verifier/latest/rustls_platform_verifier/index.html
- 7: Switching to rustls-tls - no process-level CryptoProvider available -- call CryptoProvider::install_default() before this point seanmonstar/reqwest#2630
- 8: Using rustls-no-provider causes panic algesten/ureq#970
- 9: Use
rustlsdefault provider unless specified seanmonstar/reqwest#2423
🏁 Script executed:
# Check if this is a library or binary crate
head -20 s3/Cargo.toml
# Search more broadly for any crypto provider initialization
find . -name "*.rs" -type f | xargs grep -l "CryptoProvider\|install_default" 2>/dev/null | head -20
# Check the aws-creds dependency definition
rg -A5 "^\[dependencies\]" s3/Cargo.toml | head -40
# Look for lib.rs or main initialization code
find s3/src -name "lib.rs" -o -name "main.rs" | xargs head -50Repository: durch/rust-s3
Length of output: 2340
🏁 Script executed:
# Find examples using tokio-rustls-tls or showing usage patterns
find . -name "*.rs" -type f | xargs grep -l "tokio-rustls-tls\|tokio_rustls_tls" 2>/dev/null
# Check if aws-creds/rustls-tls feature pulls in a provider
rg -A10 "feature.*rustls-tls" aws-creds/ --type toml 2>/dev/null || echo "aws-creds dir not found, checking dependencies"
# Look for any examples directory and see what's there
find . -type d -name examples -o -type d -name example 2>/dev/null | head -5
# List example files
ls -la examples/ 2>/dev/null || echo "No examples directory"Repository: durch/rust-s3
Length of output: 692
🏁 Script executed:
# Check the tokio example
cat examples/tokio-backend.rs
# Check if aws-creds is referenced with feature flags anywhere
rg "aws-creds" s3/Cargo.toml -A2 -B2
# Try to find aws-creds crate online documentation or check if it's in workspace
find . -name "Cargo.toml" | xargs grep -l "aws.creds\|awscreds" | head -10Repository: durch/rust-s3
Length of output: 2506
🏁 Script executed:
# Check aws-creds Cargo.toml to see what rustls-tls feature includes
cat aws-creds/Cargo.toml | grep -A20 "rustls-tls"Repository: durch/rust-s3
Length of output: 187
🏁 Script executed:
# Check if there's documentation about rustls-tls in README or lib.rs
grep -r "rustls-tls\|CryptoProvider" s3/src/lib.rs examples/ README.md 2>/dev/null || echo "No documentation found"
# Verify the exact reqwest and attohttpc versions and their feature behavior
rg "reqwest|attohttpc" s3/Cargo.toml -A1 | head -20Repository: durch/rust-s3
Length of output: 988
The tokio-rustls-tls feature requires explicit CryptoProvider initialization.
Line 100 enables reqwest/rustls-no-provider, which requires library users to call CryptoProvider::install_default() (e.g., rustls::crypto::ring::default_provider().install_default()) before making any TLS connections. Without this, code using tokio-rustls-tls will panic at runtime with "no process-level CryptoProvider available." The example in examples/tokio-backend.rs does not demonstrate this requirement. Add an example or documentation showing how users should initialize the provider when using this feature.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@s3/Cargo.toml` at line 100, The crate enables the tokio-rustls-tls feature
with reqwest/rustls-no-provider which requires callers to initialize a
process-level CryptoProvider before any TLS connections; update
examples/tokio-backend.rs and relevant documentation to show calling
CryptoProvider::install_default() (for example via
rustls::crypto::ring::default_provider().install_default()) during startup so
code using the tokio-rustls-tls feature won't panic with "no process-level
CryptoProvider available."
1 participant
Updated various dependencies. No user-facing breaking changes observed. All tests pass.
While I was at it, I noticed the project did not have an MSRV set. I checked what the MSRV was prior to crate update using cargo-msrv, it was 1.88.0. After the changes, it did not change.
Note:
I opted not to update sysinfo as it would bump the MSRV to 1.95.0 per this commit.
This change is
Summary by CodeRabbit