PasswordProvider abstraction could be abused for races

[leventov]

Some classes that have multiple PasswordProvider fields could inherently be subject to races:

• SSLClientConfig
• MySQLConnectorConfig
• ClientSSLContextBuilder
• TLSServerConfig
• BasicHTTPAuthenticator
• BasicAuthDBConfig
• AWSCredentialsConfig

[leventov]

AWSCredentialsConfig is confirmed to be a subject for a race.

[gianm]

What's the race that could be abused?

[leventov]

PasswordProvider abstraction allows (and actually is designed for) to be able to return different values over time. So in AWSCredentialsConfig and ConfigDrivenAwsCredentialsConfigProvider, accessKey and secreteKey are managed as separate PasswordProviders => allows the same kind of race as #6665.

[leventov]

I would suggest to replace it with an abstraction like this:

interface AbstractCredentialsProvider {
  List<String> getCredentials();
}

Where the implementation is responsible for making the values returned in the list to be consistent. On the user side, list.get(0) could be interpreted as "accessKey" or "username" or whatever, list.get(1) as "secretKey" or "password", etc.

[himanshug]

#7400 is good use case

I would prefer to remove "Abstract" from interface name and return map instead of list so as not to depend on ordering of elements for their meaning... something like (if that works)

interface CredentialsProvider {
  Map<String, String> getCredentials();
}

[github-actions]

This issue has been marked as stale due to 280 days of inactivity.
It will be closed in 4 weeks if no further activity occurs. If this issue is still
relevant, please simply write any comment. Even if closed, you can still revive the
issue at any time or discuss it on the dev@druid.apache.org list.
Thank you for your contributions.