Bump rustls-webpki from 0.102.4 to 0.102.5 in the crates-io group

[dependabot]

Bumps the crates-io group with 1 update: rustls-webpki.

Updates rustls-webpki from 0.102.4 to 0.102.5

Release notes

Sourced from rustls-webpki's releases.

0.102.5

Notable changes

• EndEntityCert::subject_public_key_info() as added in 0.102.4 neglected to specify the return type's lifetime, limiting the visible lifetime to the lifetime of the EndEntityCert. The actual lifetime was 'static; we've made this explicit and enabled warnings for elided_lifetimes_in_paths to avoid similar issues in the future.

What's changed

• build(deps): bump the crates-io group with 2 updates by @​dependabot in rustls/webpki#257
• ci: update cargo-check-external-types toolchain by @​cpu in rustls/webpki#258
• build(deps): bump seanmiddleditch/gha-setup-ninja from 4 to 5 by @​dependabot in rustls/webpki#260
• build(deps): bump aws-lc-rs from 1.7.2 to 1.7.3 in the crates-io group by @​dependabot in rustls/webpki#261
• Enable some more warnings on lints by @​djc in rustls/webpki#262
• lib: warn for clippy::use_self by @​cpu in rustls/webpki#263
• build(deps): bump the crates-io group with 2 updates by @​dependabot in rustls/webpki#265
• Prepare 0.102.5 release by @​djc in rustls/webpki#266

Commits

• 056e987 Prepare 0.102.5 release
• 8337340 build(deps): bump the crates-io group with 2 updates
• dba3b84 lib: warn for clippy::use_self
• 36ee9b6 use Self where appropriate
• c399cd9 Warn on clippy::use_self
• 53b833b Warn on elided_lifetimes_in_paths
• 27cda7e build(deps): bump seanmiddleditch/gha-setup-ninja from 4 to 5
• bdb1b75 build(deps): bump aws-lc-rs from 1.7.2 to 1.7.3 in the crates-io group
• 8e0db69 ci: update cargo-check-external-types toolchain
• ff7917a build(deps): bump the crates-io group with 2 updates
• See full diff in compare view

Dependabot 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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[djc]

Not sure what's going on with these merge queue failures...

---- badssl_with_dir_from_env stdout ----
thread 'badssl_with_dir_from_env' panicked at tests\smoketests.rs:57:19:
unexpected end of file
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
   1: core::panicking::panic_fmt
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
   2: core::panicking::panic_display<std::io::error::Error>
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081\library\core\src\panicking.rs:263
   3: smoketests::check_site::panic_cold_display<std::io::error::Error>
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081\library\core\src\panic.rs:99
   4: smoketests::check_site
             at .\tests\smoketests.rs:57
   5: smoketests::badssl_with_dir_from_env::closure$0
             at .\tests\smoketests.rs:177
   6: core::ops::function::FnOnce::call_once<smoketests::badssl_with_dir_from_env::closure_env$0,tuple$<> >
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081\library\core\src\ops\function.rs:250
   7: serial_test::serial_code_lock::local_serial_core
             at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\serial_test-3.1.1\src\serial_code_lock.rs:36
   8: smoketests::badssl_with_dir_from_env
             at .\tests\smoketests.rs:146
   9: smoketests::badssl_with_dir_from_env::closure$0
             at .\tests\smoketests.rs:147
  10: core::ops::function::FnOnce::call_once<smoketests::badssl_with_dir_from_env::closure_env$0,tuple$<> >
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081\library\core\src\ops\function.rs:250
  11: core::ops::function::FnOnce::call_once
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\ops\function.rs:250
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[cpu]

Not sure what's going on with these merge queue failures...

I think all three are just flakyness from the remote badssl.com server:

• stable, ubuntu-latest: "Connection timed out"
• beta, ubuntu-latest: "Connection timed out"
• windows-latest, stable: "unexpected end of file" (seems odd initially, but one frame up from the pancining fn is check_site("self-signed.badssl.com")).

[cpu]

Let's try again. If it doesn't work we might want to consider moving some of these tests using remote servers to their own job ala the rustls daily-tests workflow. Remote servers outside of our control are always going to flake some % of the time.