aws_config default provider (incorrectly?) requires rustls

[ereOn]

I am in the process of cleaning up the dependency graph of our monorepo, and I noticed we are still pulling hyper 0.14 due to aws_config still referencing it.

I understand it still references it mainly through rustls and possibly also the "hyper 0.14 connector" facility.

Looking through the code I noticed here that the default provider seems to be gated for the rustls feature.

#[cfg(feature = "rustls")]
/// Default Credentials Provider chain
///
/// The region from the default region provider will be used
pub async fn default_provider() -> impl ProvideCredentials {
    DefaultCredentialsChain::builder().build().await
}

This seems to be confirmed by the comment here too:

/// Creates a `DefaultCredentialsChain`
    ///
    /// ## Panics
    /// This function will panic if no connector has been set or the `rustls`
    /// feature has been disabled.
    pub async fn build(self) -> DefaultCredentialsChain {
        let region = match self.region_override {
            Some(provider) => provider.region().await,
            None => self.region_chain.build().region().await,
        };

        let conf = self.conf.unwrap_or_default().with_region(region);

        let env_provider = EnvironmentVariableCredentialsProvider::new_with_env(conf.env());
        let profile_provider = self.profile_file_builder.configure(&conf).build();
        let web_identity_token_provider = self.web_identity_builder.configure(&conf).build();
        let imds_provider = self.imds_builder.configure(&conf).build();
        let ecs_provider = self.ecs_builder.configure(&conf).build();

        let provider_chain = CredentialsProviderChain::first_try("Environment", env_provider)
            .or_else("Profile", profile_provider)
            .or_else("WebIdentityToken", web_identity_token_provider)
            .or_else("EcsContainer", ecs_provider)
            .or_else("Ec2InstanceMetadata", imds_provider);

        DefaultCredentialsChain { provider_chain }
    }

Looking a all the referenced providers, it seems that none of those actually depends on rustls so I'm not sure whether the feature-gate is still legitimate or if I'm missing something obvious.

Also, if the rustls feature-gate is still legitimate, the comment seems to indicate that one might avoid the panic by specifying a connector. Is there any example of that ?

Thank you and sorry if this turns out to be a false positive.

[aajtodd]

This is a bit convoluted and I'm probably missing some historical context but effectively this boils down to the default HTTP client plugin from aws-smithy-runtime requires both the tls-rustls and connector-hyper-0-14-x which are both enabled by the rustls feature of aws-config. So in other words this rustls feature flag is being used as a proxy for enabling a default HTTP client supplied by the runtime (which is required for several of the credential providers of the default chain to work).

This should eventually be addressed by #1925

[aajtodd]

aws-config still has the rustls and client-hyper flags but they are now synonymous with the new default-https-client feature flag which is more appropriately named with the intent behind it.

For now the legacy hyper stack based on hyper 0.14.x is still included and built by default but the default HTTPS stack is based on hyper 1.x, rustls, and aws-lc. At some point in the future we will disable the legacy stack from being enabled by default and require users to opt-in to enabling it. You can find more information on the changes in this discussion post.

I'm going to go ahead and close.