Keyring does not persist across container recreation

[RG9400]

I noticed an issue whenever I had to recreate my Duplicacy container (updates, changes to compose, etc.). My backups stopped working until I went to the web UI and initially plugged in my encryption password. Checking the logs, I noticed the below

2021/01/29 00:15:01 Skipping schedule Stormlight Backup at time 2021-0129 00:15 as no encryption password has been provided

2021/01/29 00:15:01 Please open the web browser at 0.0.0.0:3875 to enter the encryption password

This basically means that backups would not run until I typed in the encryption password, which can be dangerous if you don’t notice it. I noticed the below errors on container start as well as after typing in my encryption password, which might indicate why these do not persist across container recreation

On container start:

2021/01/28 18:37:00 The license may have been issued to a different computer

2021/01/28 18:37:00 Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set

2021/01/28 18:37:00 Failed to decrypt the value from the keyring file: cipher: message authentication failed

2021/01/28 18:37:00 Failed to decrypt the testing data using the password from KeyChain/Keyring: crypto/aes: invalid key size 0

On typing in the encryption password after the recreation:

2021/01/29 10:40:07 Failed to store the value to the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set

Is there a way to fix this issue? While recreation isn’t common, it is completely possible to forget to go to the web UI to “initialize” the encryption, causing missed backups. For posterity, the below is the compose I am using

  duplicacy:
    image: saspus/duplicacy-web:mini
    container_name: duplicacy
    hostname: ${HOSTNAME}
    environment:
      - USR_ID=${PUID}
      - GRP_ID=${PGID}
      - UMASK=${UMASK_SET}
      - TZ=${TZ}
      - DUPLICACY_WEB_VERSION=latest
    volumes:
      - ${CONFDIR}/duplicacy:/config
      - ${LOGDIR}/duplicacy:/logs
      - ${CACHEDIR}/duplicacy:/cache
      - ${CONFDIR}:/backuproot
      - ${USERDIR}/.wslconfig:/backuproot/wslconfig/.wslconfig:ro
      - ${USERDIR}/.docker:/backuproot/docker:ro
      - backups:/mnt/backups
      - drivepool:/mnt/media
    ports:
      - 3875:3875
    restart: unless-stopped

‌

[saspus]

Since version 1.4.1 duplicacy_web stores master password encrypted by the UUID. If UUID changes then of course it cannot be decrypted and you need to login again once.

The first message from your log probably hints that UUID has in fact changed (unless it complains about hostname):

The license may have been issued to a different computer

So, if you cannot ensure that the UUID stays the same – you can workaround this by providing the master password in the DWE_PASSWORD environment variable. This does not lower security in any way because UUID is not secret, it’s just unique

I don’t know where does that magic UUID is coming from. Perhaps its worth asking on the forum and then see if it can be persisted in the config directly the same way we now persist machine-id there.

And BTW – keyring will not help there – someone would need to unlock the keyring on each container start which just moves the problem elsewhere.

Edit: I’ve started this topic to clarify the UUID story: https://forum.duplicacy.com/t/where-does-uuid-that-duplicacy-uses-to-encrypt-master-password-come-from/4800

[saspus]

It seems the UUID is derived from machine-id (which should be in your config folder) and hostname (which is name of the container). If these two do not change – it shall “just work”

[Mattias Rundqvist]

Thanks for the DWE_PASSWORD clarification. You should put this in the readme file.

Also, thank you for the container. Great work

[saspus]

DWE_PASSWORD used to be mentioned in the readme until version 1.4.1 was released which instead requires to login once and avoids exposing the password in the plaintext somewhere – somewhat defeating the purpose of encrypting the thing in the first place .

I guess it’s a good idea to put it back just to support use case like yours.

Thank you for the suggestion!

[Floris van Lint]

Hello @saspus I also ran into this, but I was unable to get DWE_PASSWORD to work.

My config is using your cool container in a compose setup. I have a environment section as follows:

        environment:
            - DWE_PASSWORD="mypassword"
            - HOSTNAME=my.hostname.url
            - TZ="Europe/Amsterdam"

But sadly, upon restart of the machine or the container, duplicacy still asks me to decrypt the config using the web-ui, like @runqvist was experiencing.

This is despite setting the DWE_PASSWORD environment variable.

Docker logs shows me the following (I removed machine-id).

launch.sh runing as user root:root(0:0)
Using machine-id = 
duplicacy_web runing as user root:root(0:0)
Logging tail of the log from this moment on
Starting duplicacy
Log directory set to /logs
Duplicacy Web Edition 1.5.0 (BAFF49)
Starting the web server at http://[::]:3875
2021/06/15 11:19:54 The license may have been issued to a different computer
2021/06/15 11:19:54 Failed to decrypt the testing data using the password from the environment variable: cipher: message authentication failed
2021/06/15 11:19:54 Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set
2021/06/15 11:19:54 Failed to decrypt the value from the keyring file: cipher: message authentication failed
2021/06/15 11:19:54 Failed to decrypt the testing data using the password from KeyChain/Keyring: crypto/aes: invalid key size 0
2021/06/15 11:19:54 Temporary directory set to /cache

Am I perhaps using the DWE_PASSWORD variable incorrectly?

[saspus]

ThisFailed to decrypt the testing data using the password from the environment variable: cipher: message authentication failed sounds like Duplicacy saw the variable, extracted the password, but failed to decrypt data using it. Perhaps the password is invalid? Maybe duplicacy does not strip quotes, or maybe there is some weird symbol in your password e.g. \ which is interpreted as an escape by compose or anything else in the stack?

‌

As a test, change the password to … well, test and specify it like so DWE_PASSWORD=test (without quotes, just to be sure). If that works – you have now regression range to find the culprit :)

[Floris van Lint]

Hello @saspus, thanks for your reply! Removing the quotes around DWE_PASSWORD="mypassword" to DWE_PASSWORD=mypassword totally solved it, but only after I also removed some special characters like @ and ! which it apparently does not like. Thanks a lot for your help!

[saspus]

Awesome!. The real question though is who is mangling the string. Is that docker compose infrastructure, any of the shells they may or may not use, or duplicacy.. I’d expect using single quotes shoudl help avoid various shells from messing with content, but not sure if duplicacy-web would strip single quotes..

I myself switched to using diceware passwords everywhere long time ago – due to the issues like these; letters and dashes are unlikely to confuse any system… well, at least less likely than other special characters that need to be escaped or are escapes themselves…. escaping characters in the password though is ridiculous :)