chore(deps): bump self_update from 0.41.0 to 0.44.0

[dependabot]

Bumps self_update from 0.41.0 to 0.44.0.

Changelog

Sourced from self_update's changelog.

[0.44.0]

Added

• (s3) support generic S3 endpoints (#171)

Changed

• (s3) fix reverse release ordering (#173)
• (deps) update reqwest to 0.13 (#175)

Removed

[0.43.1]

Added

Changed

• Improve assert_for logic to fallback to identifier-only search if target/os-arch search fails
• Fix update logic to respect bin_install_path when not equal to the current exe. Logic was previously modified to use the self_replace crate, but that change assumed the installation was always replacing the current exe.

Removed

[0.43.0]

Added

• Docs: add documentation for [self_update::errors::Error]

Changed

• Improve assert_for logic to prioritize searching by asset name and identifier before looking for assets by OS/arch

Removed

[0.42.0]

Added

• Improved release search/lookup capability to support filtering assets by identifier
• Improved version specifications to support prerelease tags and parallel supported versions

Changed

• Update reqwest features to allow http2 negotiation
• Update quick-xml (0.37) and zipsign (0.1)
• Specify per_page=100 when fetching github releases

Removed

Commits

• See full diff in compare view

[claude]

Review: chore(deps): bump self_update from 0.41.0 to 0.44.0

This is a dependency-only change (Cargo.toml / Cargo.lock), no application source touched. Overall looks correct and well-handled.

What's good

• The follow-up commit (fix(deps): enable self_update's reqwest backend feature for 0.44) correctly catches a real breaking change: self_update 0.42→0.44 split reqwest out into its own feature, and rustls alone no longer implies an HTTP backend (it's reqwest?/rustls). Without this fix, dependabot's bare version bump would have compiled "successfully" but left self_update with no working http_client::get, silently breaking cook update / cook doctor's update check at runtime rather than at build time. Good catch, and the explanatory comment left in Cargo.toml is genuinely useful for the next person touching this dependency.
• Changelog for 0.42–0.44 (S3 backend fixes, reqwest 0.13 bump, assert_for improvements) doesn't show anything alarming from a security standpoint.

Worth a look before/soon after merging

1. Two reqwest majors + two rustls crypto providers now ship in the default binary. Cargo.lock shows self_update's new reqwest feature pulls in reqwest 0.13.4 (with aws-lc-rs/aws-lc-sys as new transitive deps), while the app itself still depends on reqwest 0.12.28 (via the import/sync/login features, which use ring). Since self-update and import are both in the default feature set (Cargo.toml:14), a default build now links both ring and aws-lc-rs as rustls crypto backends simultaneously.
   Today this is safe in practice because the two HTTP stacks never run in the same process — update::check_for_updates (used by cook update / cook doctor) never shares a call path with the reqwest-0.12-based import/login/sync code. But it's a latent footgun: if a future change ever exercises both in one process (e.g. a background update check wired into the long-running server command), rustls can panic at TLS-client construction time when more than one crypto provider is linked in and none has been explicitly installed as default. Not a blocker, just worth a mental note.

2. New build-time dependency: aws-lc-sys needs cmake (see the new cmake/aws-lc-sys entries in Cargo.lock), which plain ring didn't require. The release workflow cross-compiles several targets via cross (musl/arm targets) — worth confirming those cross-rs Docker images have cmake available before the next tagged release, since I can't verify that from here. GH-hosted ubuntu-latest/macos-*/windows-latest runners used for the native targets should be fine.

3. Test coverage: understandably no automated coverage for self_update itself (network-dependent, hits the GitHub releases API), but since the HTTP backend changed under the hood, a quick manual cook update --check-only smoke test would be reassuring before merge, per the repo's manual-testing convention.

No security or correctness concerns with the version bump itself — the feature-flag fix is the right one; just flagging the dual-TLS-backend situation and the new cmake build requirement for awareness.