gilbertchen / duplicacy

A new generation cloud backup tool
https://duplicacy.com
Other
5.14k stars 335 forks source link

Multiple local repositories with different default storage locations cannot use keyring. #194

Open cbop-dev opened 7 years ago

cbop-dev commented 7 years ago

If I setup two separate local encrypted repositories, using keyrings, each with their own default (but different) storage locations and different passwords, whichever one is backed up last will overwrite the password (in the keyring) of the early one. Thus:

$ cd ~/repo1/
$ duplicacy init -e repo1 ~/backup1
$ duplicacy backup
$ cd ~/repo2
$ duplicacy init -e repo2 ~/backup2
$ duplicacy backup

...will cause any subsequent call on repo1 to result in an error: Failed to download the configuration file from the storage: Failed to retrieve the config file: cipher: message authentication failed

This is because the current way of storing/retrieving credentials from keyrings (at least in Linux) uses the same attribute/value set for any default storage location: username:password service:duplicacy. Whereas, for any repository's non-default storage, it is username:<storage_name>_password service:duplicacy.

One way for the user to avoid this problem is always to give a storage name to the default storage (which requires manually editing the preferences file). I'm not sure if this creates other problems. Another solution might be for the init command to force the user to name the default storage, and have the "default" storage identified by another attribute in the preferences file (e.g., "default": true). Then each storage location, even default ones, will have their own keyring entry.

gilbertchen commented 7 years ago

You're right, this is an issue. Manually editing the preferences file currently is the only workaround. At the least this should be in the doc.

TheBestPessimist commented 6 years ago

Title: cannot init a new repsitory (init, storage name is either "default", or another storage name which already exists), in a different folder -> to the same gcd storage path

C:\duplicacy repo>z init -e tbp-pc gcd://du
Enter the path of the Google Drive token file (downloadable from https://duplicacy.com/gcd_start):C:\duplicacy repo\.duplicacy\gcd-token.json
Enter storage password for gcd://du:*********************
Failed to download the configuration file from the storage: Failed to retrieve the config file: cipher: message authentication failed

Now trying the same init with a different storage name (which also exists):

C:\duplicacy repo>z init -e -storage-name gcd tbp-pc gcd://du
Enter the path of the Google Drive token file (downloadable from https://duplicacy.com/gcd_start):C:\duplicacy repo\.duplicacy\gcd-token.json
Enter storage password for gcd://du:*********************
Failed to download the configuration file from the storage: Failed to retrieve the config file: cipher: message authentication failed

This is the other duplicacy repo which is for testing and works okay:

[
    {
        "name": "default",
        "id": "duplicacy-test-repo-id",
        "storage": "gcd://du",
        "encrypted": true,
        "no_backup": false,
        "no_restore": false,
        "no_save_password": false,
        "keys": null
    },
    {
        "name": "gcd",
        "id": "gcdSnapshotId",
        "storage": "gcd://du",
        "encrypted": true,
        "no_backup": false,
        "no_restore": false,
        "no_save_password": false,
        "keys": null
    }
]

I have the same storage folder (destination), just trying to init in a different folder. Is my problem related to this bug, or should i create a new issue?

gilbertchen commented 6 years ago

@TheBestPessimist cipher: message authentication failed is caused by a wrong storage password -- you didn't enter the correct storage password that was used to initialize the storage gcd://du

TheBestPessimist commented 6 years ago

Ah, I'm just dumb! I always had the feeling that storage password was actually set "by repository" instead of "by storage".

Thanks for the info!

In this case, if you desire, you can delete these 3 comments, since they are unrelated to the original issue and are just user error.