org.springframework.boot.autoconfigure.couchbase.CouchbaseProperties.Authentication.Jks#getPrivateKeyPassword isn't used anywhere. Investigate if that's an oversight or if the property can be removed.

Comment From: Sarankumar18

@mhalbritter Removing privateKeyPassword from CouchbaseProperties.Authentication.Jks. This property is not used anywhere internally in Spring Boot's Couchbase auto-configuration. It is not bound from configuration files, nor referenced in any logic or tests. Removing it helps eliminate dead code and reduces confusion for users.

Comment From: wilkinsona

@Sarankumar18 Apologies if it's not the case, but that comment reads to me like it was generated by an LLM. If that is the case, it's not beneficial to the project as we could ask an LLM ourselves if we wanted to do so. It also doesn't add anything new as the issue already states that getPrivateKeyPassword "isn't used anywhere". We now need to investigate why it's not being used and either start using it if that's an oversight or remove it if it's not.

Comment From: HyunSangHan

Hi Spring Boot team,

I found this issue interesting and took some time to investigate.

I cannot say for sure, but I would like to share what I found:

  • The CouchbaseProperties.Authentication.Jks#getPrivateKeyPassword method was introduced in add3d87ea1904dba893f32365e4493d384205e73, as part of the changes to #45883.
  • In that commit, logic for using privateKeyPassword was added for PEM-based authentication, but not for JKS. The field was defined for JKS but is not actually used.
  • The documentation(nosql.adoc) updated in the same commit does not mention privateKeyPassword for JKS either.
  • Based on my understanding, JKS keystores typically require only the keystorePassword, so a separate privateKeyPassword is usually not needed.
  • This seems to be consistent with the Couchbase SDK as well. For example, the fromKeyStore method does not require a privateKeyPassword either.
  • Given this, it seems that privateKeyPassword is not necessary in the JKS case. Removing it might help reduce confusion for users.

I hope this helps!