Spring framework 6.2 placeholder parser rewrite breaks the secret manager prefix sm://

[elg-entur]

Describe the bug
Please provide details of the problem, including the version of Spring Cloud that you
are using.

spring-cloud-gcp-starter-secretmanager: 5.8.0
Spring framework 6.2.0 (i.e, spring boot 3.4.0)

The rewrite of springs property placeholder parser (6.1 vs 6.2) changes the way default values are parsed. This change breaks hardcoded prefix of the secret manager, sm://.

For example a property defined as secret: ${sm://MY_SECRET} will be be parsed differently in spring framework 6.1 and 6.2. In 6.1 it will be resolved correctly to the actual secret. In 6.2 it will be parsed as //MY_SECRET (unless a property called sm is defined) which is clearly wrong

The workaround is to change the prefix in each application config to sm\://, e.g., secret: ${sm\://MY_SECRET}, but this is not only ugly but not at all intuitive to do.

At the very least I expect the documentation to be updated with the workaround.

Would it be possible to either

1. Make the prefix configurable
2. Add an alternative to the current prefix which does not contain :, such as sm//

Workaround (yaml)

unquoted_secret: ${sm\://MY_SECRET}
single_quoted_secret: '${sm\://MY_SECRET}'
double_quoted_secret: "${sm\\://MY_SECRET}"

[keesvandieren]

For our project, the workaround to use sm\:// does not work.

We've rolled back to spring-boot 3.3.6 to ensure spring-framework 6.1.x is used.

[elg-entur]

If the secret is in a quoted string it should be double escaped, as so secret: "${sm\\://MY_SECRET}"

[keesvandieren]

It is in a properties file

[headegg]

Thanks for raising this and providing a workaround. Mine was in a single quoted string in a helm values.yaml file and a single backslash did the trick.

spring.datasource.password: '${sm\://{{ .Values.env }}-database-password}'

[aptituz]

I can also confirm that the workaround with escaping the double-colon works. Any plans from google side to address this issue with a fix, though?

[bendb-instacart]

Registering my interest in a bugfix - this is quite a problematic breaking change from Spring. I wish that I had a good solution to offer.

[JoeWang1127]

We don't support spring boot 3.4.0 right now and we've been working on the support, see #3320.

Please see the compatibility with spring project versions.

[diegomarquezp]

This will be solved by Framework 6.2.2, it's in their next milestone's roadmap - see spring-projects/spring-framework#34124. We are still working on upgrading to Cloud 2024 as per #3320 (comment).

[snicoll]

The rewrite of springs property placeholder parser (6.1 vs 6.2) changes the way default values are parsed. This change breaks hardcoded prefix of the secret manager, sm://.

For the record, this was never meant to be supported in the first place. : always was a reserved keyword that separates the key from the fallback. In 6.2 we introduced consistent way to escape it (as you found out).

That being said, we've decided to restore this use case for backward compatible reason with 6.x but we might revisit this in the future. In short, please don't rely on a placeholder with a non escaped reserved keyword in it.

[tompson]

so just to confirm: currently there is no way to use escape sm:// in properties files correctly to make it work with Spring Boot 3.4 / Spring Framework 6.2 ? /cc @keesvandieren

[keesvandieren]

For us it didn't work, but for some others it seemed to work?

[joaotab]

Worked for us with: api-key: ${sm\://my-api-key-secret} but I read somewhere the escaping required depends if you're using quoted or unquoted strings

[breun]

There is currently no version of Spring Cloud GCP yet that is compatible with Spring Cloud 2024.0 / Spring Boot 3.4 / Spring Framework 6.2 (see Compatibility with Spring Project Versions). I would recommend just waiting for Spring Cloud GCP 6 to be released before upgrading.