Tool attempts to delete latest ESV version when same valueBase64 is posted twice to create secret version endpoint

[swensone]

A recent change in the ESV API changes the create secret version behavior to not create a new version if the posted data matches the latest version. In these cases, the API returns a 200 along with a response indicating that the latest secret version is still the same.

However, fr-config-manager is assuming that a new version was created, and it then attempts to delete what was the current version before the POST. Since there a new version was not created, this is the latest version. Deleting the latest version is not allowed, and a 403 is returned.

It seems that the following code needs to be wrapped in a check so it only executes if currentVersion.version != versionResponse.version.

https://github.com/ForgeRock/fr-config-manager/blob/2461e299001ca2521394f3dae9138a2819fb8027/packages/fr-config-push/src/scripts/update-secrets.js#L182-L191

[christian-brindley]

This is indeed caused by a change of behaviour in the ESV API. The destruction of old versions of secrets was implemented in order to keep secret versions to a minimum - i.e. only create exactly the number of versions of the secret in the config repo.

This is somewhat complicated by the fact that the config tool pushes local versions in ascending order, so that the last version is active, while maintaining older versions for key rollover. Unfortunately, the ESV API does not check whether the supplied version is present as an old - i.e. not loaded - version.

The simplest approach would be to stop removing existing versions of secrets - i.e. leave the pruning of secrets to a manual process. Also, only update secrets as single version - as per the push command with the --active-only flag.

[ryanzwe]

Hi @christian-brindley

I can see this one is assigned, does this mean this is currently being worked on 😃

Thanks!