__FILE env vars appear to add a trailing newline character to the value

[geekifier]

Running the latest release of WUD (6.3.0), configuring the MQTT watcher by referencing a file secret from a mounted volume does not work.

Working Scenario

services:
  whatsupdocker:
    image: fmartinou/whats-up-docker:6.3.0
    environment:
      - "WUD_TRIGGER_MQTT_MOSQUITTO_PASSWORD=foo"

INFO whats-up-docker/trigger.mqtt.mosquitto: Register with configuration {"tls":{"rejectunauthorized":false},"password":"H******************************k","user":"wud","url":"mqtt://[XXX]:1883","hass":{"enabled":true,"prefix":"homeassistant"},"topic":"wud/container","clientid":"wud_886acf48","threshold":"all","mode":"simple","once":true,"simpletitle":"New ${kind} found for container ${name}","simplebody":"Container ${name} running with ${kind} ${local} can be updated to ${kind} ${remote}\n${link}","batchtitle":"${count} updates available"}

Broken scenario

services:
  whatsupdocker:
    image: fmartinou/whats-up-docker:6.3.0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - wud_secrets:/secrets
    environment:
      - "WUD_TRIGGER_MQTT_MOSQUITTO_PASSWORD__FILE=/secrets/WUD_TRIGGER_MQTT_MOSQUITTO_PASSWORD"
volumes:
  wud_secrets:

WARN whats-up-docker/registry: Some triggers failed to register (Error when registering component mqtt (Connection refused: Not authorized))

I verified multiple times that the context of the file matches the password value defined in the ENV var. I have also verified that I am able to cat the /secrets/WUD_TRIGGER_MQTT_MOSQUITTO_PASSWORD file from the running container, and I get the correct value.

The password is base64 encoded and has no special characters, so I am not sure what is triggering this other than the __FILE variable simply being ignored by the MQTT watcher's code.

I also have the WUD_REGISTRY_LSCR_TOKEN__FILE var defined, and that one works fine (mounted from the same volume).

Here are relevant parts of my compose file for wud.

version: '2'
services:
  whatsupdocker:
    image: fmartinou/whats-up-docker:6.3.0
    container_name: wud
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - wud_secrets:/secrets
    environment:
      - "WUD_REGISTRY_LSCR_TOKEN__FILE=/secrets/WUD_REGISTRY_LSCR_TOKEN"
      - "WUD_TRIGGER_MQTT_MOSQUITTO_URL=mqtt://XXX:1883"
      - "WUD_TRIGGER_MQTT_MOSQUITTO_USER=wud"
      - "WUD_TRIGGER_MQTT_MOSQUITTO_PASSWORD__FILE=/secrets/WUD_TRIGGER_MQTT_MOSQUITTO_PASSWORD"
      - "WUD_TRIGGER_MQTT_MOSQUITTO_HASS_ENABLED=true"
      - "WUD_TRIGGER_MQTT_MOSQUITTO_TLS_REJECTUNAUTHORIZED=false"
      - "WUD_WATCHER_RPI2_HOST=XXX"
      - "WUD_WATCHER_RPI2_CAFILE=/secrets/cacert.pem"
      - "WUD_WATCHER_RPI2_CERTFILE=/secrets/wud_XXX.pem"
      - "WUD_WATCHER_RPI2_KEYFILE=/secrets/wud.key"
      - "WUD_WATCHER_RPI2_PORT=2376"
      - "WUD_WATCHER_LOCAL_SOCKET=/var/run/docker.sock"
volumes:
  wud_secrets:

[geekifier]

I enabled debug logs, and it looks like for some reason the password stored in a file adds an \n at the end (logs formatted for readability):

ENV var password

INFO whats-up-docker/trigger.mqtt.mosquitto: Register with configuration 
{
    "tls": {
        "rejectunauthorized": false
    },
    "password": "H******************************k",
    "user": "wud",
    "url": "mqtt://XXX:1883",
    "hass": {
        "enabled": true,
        "prefix": "homeassistant"
    },
    "topic": "wud/container",
    "clientid": "wud_25e24496",
    "threshold": "all",
    "mode": "simple",
    "once": true,
    "simpletitle": "New ${kind} found for container ${name}",
    "simplebody": "Container ${name} running with ${kind} ${local} can be updated to ${kind} ${remote}\n${link}",
    "batchtitle": "${count} updates available"
}

Password loaded with __FILE

INFO whats-up-docker/trigger.mqtt.mosquitto: Register with configuration
{
    "tls": {
        "rejectunauthorized": false
    },
    "user": "wud",
    "url": "mqtt://XXX:1883",
    "hass": {
        "enabled": true,
        "prefix": "homeassistant"
    },
    "password": "H*******************************\n",
    "topic": "wud/container",
    "clientid": "wud_fc893eac",
    "threshold": "all",
    "mode": "simple",
    "once": true,
    "simpletitle": "New ${kind} found for container ${name}",
    "simplebody": "Container ${name} running with ${kind} ${local} can be updated to ${kind} ${remote}\n${link}",
    "batchtitle": "${count} updates available"
}

The file containing the password has no \n at the end.

Upon further investigation, the same issue occurs with WUD_REGISTRY_LSCR_TOKEN__FILE (at least in the log), but it does not seem to result in an auth failure, unlike MQTT.

[geekifier]

After I saw that you have a test for this here I did some more digging, and sure enough there was an eol character at the end of the file, I was able to confirm this by using od. I regenerated the files piping the secrets via echo -n and all is well now. It's still interesting it did not affect the LSCR token at all!