[GH-ISSUE #960] [BUG] Secret with $ character gets replaced / treated as a placeholder #3681

New Issue

GiteaMirror · 2026-04-13T15:09:19-05:00

GiteaMirror commented

2026-04-13 15:09:19 -05:00

Originally created by @rsocko on GitHub (Nov 4, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/960

When a secret (or I assume a variable) has $ character within its value, it can get treated as if it is itself a placeholder to be replaced by the variable/secret replacement logic.

Details & Repro:

I try to maintain complex and unique passwords and secrets for each of my services and utilize a password generator to create unique secrets.
I had a secret with the $ in the value of the secret as a complex password with characters & symbols
During the deployment Komodo saw that value and tried to perform a replacement, but there was understandably not a variable or secret with that name (note in fact that the string had somewhere in the middle and Komodo treats everything after the (up until a space I believe) as a variable to replace.

It would appear that perhaps Komodo is making multiple passes at the variable replacement and also seems to perhaps use $ alone as part of the regex / pattern to match to identify a variable or secret to be replaced.

This feels similar in nature to: https://github.com/moghtech/komodo/issues/644#issuecomment-3483271570 whereby a secret value that matches the service name is being treated oddly.

Originally created by @rsocko on GitHub (Nov 4, 2025). Original GitHub issue: https://github.com/moghtech/komodo/issues/960 When a secret (or I assume a variable) has $ character within its value, it can get treated as if it is itself a placeholder to be replaced by the variable/secret replacement logic. Details & Repro: - I try to maintain complex and unique passwords and secrets for each of my services and utilize a password generator to create unique secrets. - I had a secret with the $ in the value of the secret as a complex password with characters & symbols - During the deployment Komodo saw that value and tried to perform a replacement, but there was understandably not a variable or secret with that name (note in fact that the string had $ somewhere in the middle and Komodo treats everything after the $ (up until a space I believe) as a variable to replace. It would appear that perhaps Komodo is making multiple passes at the variable replacement and also seems to perhaps use $ alone as part of the regex / pattern to match to identify a variable or secret to be replaced. This feels similar in nature to: https://github.com/moghtech/komodo/issues/644#issuecomment-3483271570 whereby a secret value that matches the service name is being treated oddly.

GiteaMirror commented

2026-04-13 15:09:20 -05:00

@mbecker20 commented on GitHub (Nov 4, 2025):

Komodo only does ${VAR} stype interpolation for its own config files core.config.toml and periphery.config.toml, otherwise it only does [[VAR]] style. Can you clarify the situation?

@mbecker20 commented on GitHub (Nov 4, 2025): Komodo only does `${VAR}` stype interpolation for its own config files `core.config.toml` and `periphery.config.toml`, otherwise it only does `[[VAR]]` style. Can you clarify the situation?

GiteaMirror commented

2026-04-13 15:09:20 -05:00

@rsocko commented on GitHub (Nov 4, 2025):

I will try a more detailed repro so that I can confirm what I'm seeing.

On quick review - the secret value was just a string with $ in the middle of it - no { } pr characters included.

I am going to recreate the stack with the secret included to pull the logs and be more specific of what I am seeing.

@rsocko commented on GitHub (Nov 4, 2025): I will try a more detailed repro so that I can confirm what I'm seeing. On quick review - the secret value was just a string with $ in the middle of it - no { } pr [[ ]] characters included. I am going to recreate the stack with the secret included to pull the logs and be more specific of what I am seeing.

GiteaMirror commented

2026-04-13 15:09:20 -05:00

@bastienlc commented on GitHub (Mar 22, 2026):

I had a similar issue but the root cause is docker compose interpolation.

I'm using Komodo to inject variables in my docker compose services, typically in the stack configuration I have:

MY_ENV_VAR=[[KOMODO_VAR]]

And in the docker-compose.yml file:

services:
  my_service:
    ...
    environment:
      MY_ENV_VAR: ${MY_ENV_VAR}

If KOMODO_VAR contains signs, things can get tricky. I see in the `.env` generated by Komodo that the value is rendered correctly there. The issue appears when docker compose does its interpolation. One solution is to escape signs by replacing them by $$ in KOMODO_VAR.

Having Komodo automatically escape these characters could be a nice feature!

@bastienlc commented on GitHub (Mar 22, 2026): I had a similar issue but the root cause is [docker compose interpolation](https://docs.docker.com/reference/compose-file/interpolation/). I'm using Komodo to inject variables in my docker compose services, typically in the stack configuration I have: ``` MY_ENV_VAR=[[KOMODO_VAR]] ``` And in the docker-compose.yml file: ``` services: my_service: ... environment: MY_ENV_VAR: ${MY_ENV_VAR} ``` If `KOMODO_VAR` contains $ signs, things can get tricky. I see in the `.env` generated by Komodo that the value is rendered correctly there. The issue appears when docker compose does its interpolation. One solution is to escape $ signs by replacing them by $$ in `KOMODO_VAR`. Having Komodo automatically escape these characters could be a nice feature!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#3681