Properties decryption not working correctly when they are on a list (yaml)

[FuRi0n]

When we have properties on a list that are encrypted and we overwrite them on another profile they will keep their initial value and ignore other profiles. This happens even to other properties but if we add them also ciphered on the other profiles then it will work correctly. I have a sample application to reproduce the issue: https://github.com/FuRi0n/decrypt

In the sample, with this yml file:

application:
  list:
    - plain: good
      cipher: '{cipher}4ffef96df11b9e9ca7b33aa5ccd60b6ed8406ec5edb68618b2469208fceb2626'

---

application:
  list:
    - plain: updated
      cipher: 'updated'
spring:
  config:
    activate:
      on-profile: decrypt

When running 'decrypt' profile it will print on console plain='good' and cipher='bad' but, if we update the 'cipher' value on 'decrypt' profile to be also encrypted then we will get plain='updated' and cipher='updated'

The expected behaviour is that properties in the profile with higher priority must overwrite other profiles even if those properties values are not encrypted.

[kvmw]

This is because DecryptEnvironmentPostProcessor.java giving highest priority to decrypted values. I am not sure if this is intentional or not!

So for given properties like the following in application.yaml:

foo: 'a value'
bar: '{cypher}an encrypted value'

one can override the value of the normal property (foo) using environment variables like FOO="a new value" ./gradlew bootRun but that is not possible for the encrypted property (bar). bar always has the decrypted value.

@ryanjbaxter Is this expected behaviour?

[ryanjbaxter]

Not sure. Maybe @spencergibb knows?

[spencergibb]

I believe so. Decrypted priorities are put in another property source with highest priority so they would "override" the encrypted property. We don't replace values in a property source

[kvmw]

Currently, decrypted properties from all sources are collected into a single property source named "decrypted," which is added as the first entry in the list (index 0). A better(?) approach would be to extract the decrypted properties per property source and insert that decrypted subset immediately before its encrypted source, if it is not empty.

Example (current implementation):

- [0] "decrypted"
- [1] "property-source-1"
- [2] "property-source-2"
- [3] "property-source-3"

Example (proposed):

- [0] "decrypted-property-source-1"
- [1] "property-source-1"
- [2] "property-source-2" # Assuming this one has no encrypted property. So no "decrypted-property-source-2"
- [3] "decrypted-property-source-3"
- [4] "property-source-3"

Pros: Preserves the priorities of property sources. For example, a profile-specific source would have higher priority than the default one.

Cons: If encrypted properties are distributed across many sources, we may end up with a larger number of property sources.

[ryanjbaxter]

I don't think we would be against this, if you want to create a PR for it we would be happy to consider it.