Bump rustls-webpki to v0.101

[paolobarbolini]

No description provided.

[cpu]

Let's hold this on rustls/webpki#112 getting resolved. I think we'll have a 0.101.1 in the near future.

[cpu]

Thanks for the PR 👍

I think this is OK to approve now. We cut a rustls-webpki v0.101.1 with the 32-bit regression fixed. My understanding of cargo dep resolution is that specifying 0.101.0 here will have rustls-webpki use that point release automatically.

[djc]

Our lives would probably be easier if we didn't publicly expose the webpki crate like this. I still wonder if there would be merit in a rustls-types crate with simple low-level types that can be used across crates like rustls-native-roots, webpki-roots, webpki and rustls to have a simpler interoperability story between these crates.

[cpu]

Our lives would probably be easier if we didn't publicly expose the webpki crate like this.

👍 @djc Maybe we can flesh that idea out over in rustls/rustls#709 ? I think that issue was similar in spirit if not exactly the same implementation strategy.

[ctz]

Because we hide rustls's webpki dependency, there's no longer a strict requirement to keep this crate's webpki dependency in sync with it. Though if we don't, people end up compiing two webpki versions in their dependency tree -- which is not great -- but the webpki-roots version is just used to determine the layout of the webpki::TrustAnchor type and actually lands zero code in the resulting binary:

$ nm -lC ./target/debug/limitedclient   | grep 'webpki-0.100' | wc -l
0
$ nm -lC ./target/debug/limitedclient   | grep 'webpki-0.101' | wc -l
158

With all that said, it's certainly worth keeping them in sync to avoid two copies. But we don't need to do this in lock-step with rustls releases any more.

[djc]

I have mentioned this strategy before, in rustls/rustls#758 (comment). I don't think #709 covers much of the same territory.

[ctz]

Released in https://crates.io/crates/webpki-roots/0.24.0