chore: patch for RUSTSEC-2026-0007 and RUSTSEC-2026-0049

[smallstepman]

What changed:

Updated Cargo.lock only:

• bytes 1.11.0 → 1.11.1
• rustls-webpki 0.103.8 → 0.103.10

Why:

These are the exact patched versions recommended by the reported advisories:

• RUSTSEC-2026-0007
• RUSTSEC-2026-0049

Validation:

cargo fmt --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-features
cargo deny check

All passed, cargo deny check now reports: advisories ok, bans ok, licenses ok, sources ok

Agent-Logs-Url: https://github.com/smallstepman/rbw/sessions/c1a926dd-380e-4b90-ae9a-99bf86eba411

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[smallstepman]

output from cargo deny pre-fix:

Run cargo deny check
error[vulnerability]: Integer overflow in `BytesMut::reserve`
   ┌─ /home/runner/work/rbw/rbw/Cargo.lock:26:1
   │
26 │ bytes 1.11.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0007
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0007
   ├ In the unique reclaim path of `BytesMut::reserve`, the condition
     ```rs
     if v_capacity >= new_cap + offset
     ```
     uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.
     
     This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.
     
     ## PoC
     
     ```rs
     use bytes::*;
     
     fn main() {
         let mut a = BytesMut::from(&b"hello world"[..]);
         let mut b = a.split_off(5);
     
         // Ensure b becomes the unique owner of the backing storage
         drop(a);
     
         // Trigger overflow in new_cap + offset inside reserve
         b.reserve(usize::MAX - 6);
     
         // This call relies on the corrupted cap and may cause UB & HBO
         b.put_u8(b'h');
     }
     ```
     
     # Workarounds
     
     Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.
   ├ Announcement: https://github.com/advisories/GHSA-434x-w66g-qw3r
   ├ Solution: Upgrade to >=1.11.1 (try `cargo update -p bytes`)
     │   ├── ssh-agent-lib v0.5.1
     │   │   └── rbw v1.15.0 (*)
     │   ├── tokio-rustls v0.26.4
     │   │   ├── hyper-rustls v0.27.7 (*)
     │   │   ├── reqwest v0.12.28 (*)
     │   │   └── tokio-tungstenite v0.28.0 (*)
     │   ├── tokio-stream v0.1.17
     │   │   └── rbw v1.15.0 (*)
     │   ├── tokio-tungstenite v0.28.0 (*)
     │   ├── tokio-util v0.7.17
     │   │   └── ssh-agent-lib v0.5.1 (*)
     │   └── tower v0.5.2
     │       ├── axum v0.8.8 (*)
     │       ├── reqwest v0.12.28 (*)
     │       └── tower-http v0.6.8 (*)
     ├── tokio-util v0.7.17 (*)
     ├── tower-http v0.6.8 (*)
     └── tungstenite v0.28.0 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/rbw/rbw/Cargo.lock:190:1
    │
190 │ rustls-webpki 0.103.8 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.8
      └── rustls v0.23.35
          ├── hyper-rustls v0.27.7
          │   └── reqwest v0.12.28
          │       └── rbw v1.15.0
          ├── reqwest v0.12.28 (*)
          ├── tokio-rustls v0.26.4
          │   ├── hyper-rustls v0.27.7 (*)
          │   ├── reqwest v0.12.28 (*)
          │   └── tokio-tungstenite v0.28.0
          │       └── rbw v1.15.0 (*)
          ├── tokio-tungstenite v0.28.0 (*)
          └── tungstenite v0.28.0
              └── tokio-tungstenite v0.28.0 (*)

advisories FAILED, bans ok, licenses ok, sources ok
Error: Process completed with exit code 1.