Hive storePasswordPath uses the Java Hadoop credential-provi

Error message

Hive storePasswordPath uses the Java Hadoop credential-provider format; configure trustStorePassword explicitly for the native agent

What it means

When sslTrustStore is configured and no explicit trustStorePassword parameter is present, the driver checks whether a Java Hadoop credential-provider path (storePasswordPath) was supplied. Since the native Go agent cannot read the Java credential-provider JCEKS format, it rejects the config and asks the user to provide the trust store password directly.

Source

Thrown at agents/drivers/hive-go/config.go:1068

	if parameterBool(values, "sslinsecureskipverify") || parameterBool(values, "allowselfsigned") {
		config.InsecureSkipVerify = true
	}
	var customRoots *x509.CertPool
	credentialProviderPath := parameter(values, "storepasswordpath")
	if path := strings.TrimSpace(params.CACertPath); path != "" {
		contents, err := os.ReadFile(path)
		if err != nil {
			return nil, fmt.Errorf("read Hive CA certificate: %w", err)
		}
		customRoots = x509.NewCertPool()
		if !customRoots.AppendCertsFromPEM(contents) {
			return nil, errors.New("Hive CA certificate contains no certificates")
		}
	}
	trustStoreLocation := parameter(values, "ssltruststore")
	if trustStoreLocation != "" {
		if parameter(values, "truststorepassword") == "" && credentialProviderPath != "" {
			return nil, errors.New("Hive storePasswordPath uses the Java Hadoop credential-provider format; configure trustStorePassword explicitly for the native agent")
		}
		certificates, err := loadTrustStore(
			trustStoreLocation,
			parameter(values, "truststorepassword"),
			parameter(values, "truststoretype"),
		)
		if err != nil {
			return nil, fmt.Errorf("load Hive truststore: %w", err)
		}
		if customRoots == nil {
			customRoots = x509.NewCertPool()
		}
		for _, certificate := range certificates {
			customRoots.AddCert(certificate)
		}
	}
	config.RootCAs = customRoots
	if params.ClientCertPath != "" || params.ClientKeyPath != "" {

View on GitHub (pinned to c0390bff16)

Solutions

Set the truststorepassword parameter explicitly in the connection parameters.
Remove the Java credential-provider storePasswordPath setting; extract the password from the JCEKS provider once and configure it plainly.
Load the trust store into PEM form (sslCACertificate) to bypass Java keystores entirely.

Example fix

// before
// sslTrustStore=/etc/certs/truststore.jks, storePasswordPath=jceks://hdfs/secrets/pass
// after
// sslTrustStore=/etc/certs/truststore.jks, trustStorePassword=changeit

Defensive patterns

Strategy: validation

Validate before calling

if params["ssltruststore"] != "" && params["truststorepassword"] == "" &&
	strings.HasPrefix(params["storepasswordpath"], "jceks://") {
	return fmt.Errorf("native agent needs an explicit trustStorePassword, not a Hadoop credential provider")
}

Prevention

Audit migrated JDBC URLs and strip credentialProvider/storePasswordPath options
Inject store passwords as environment variables or secret files, not Java credential providers
Document that the Go agent reads no JCEKS files

When it happens

Trigger: A config with sslTrustStore set, no truststorepassword parameter, and a credential-provider style storePasswordPath value (e.g. jceks://hdfs/path or the Hadoop provider syntax) carried over from a JDBC/Hive Java client URL.

Common situations: Migrating Java Hive JDBC connection strings (with credentialProvider/hadoop-credential store passwords) to the native Go agent; copying enterprise connection settings verbatim from DBeaver/JDBC configs.

Related errors

AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05). Data as JSON: /api/errors/53e778f9c3eabe5c. Report an issue: GitHub.