Details
Description
Remove the s3a://user:secret@host auth mechanism from S3a.
As well as being insecure, it causes problems with S3Guard's URI matching code.
Proposed: cull it utterly. We've been telling people to stop using it since HADOOP-3733
Attachments
Attachments
Issue Links
- blocks
-
HADOOP-14556 S3A to support Delegation Tokens
-
- Resolved
-
- causes
-
HADOOP-15750 remove obsolete S3A test ITestS3ACredentialsInURL
-
- Resolved
-
- contains
-
HADOOP-14762 S3A warning of obsolete encryption key which is never used
-
- Resolved
-
- is related to
-
HADOOP-15747 warning about user:pass in URI to explicitly call out Hadoop 3.2 as removal
-
- Resolved
-
-
HADOOP-14439 regression: secret stripping from S3x URIs breaks some downstream code
-
- Resolved
-
- relates to
-
HADOOP-13252 Tune S3A provider plugin mechanism
-
- Resolved
-
-
HADOOP-15422 s3guard doesn't init when the secrets are in the s3a URI
-
- Resolved
-
-
HADOOP-3733 "s3:" URLs break when Secret Key contains a slash, even if encoded
-
- Resolved
-
-
SPARK-20799 Unable to infer schema for ORC/Parquet on S3N when secrets are in the URL
-
- Closed
-