Silly question about `info` command

Support
#1

Am I right to conclude that the info command cannot be used with a repo init’d with a specified -repository path?

Here’s what I have:

  • .duplicacy folder located here: ~/dup_prefs/
  • repo located here: ~/
  • storage located here /Volumes/HD/storage
  • pwd stored in MacOS keychain

Working with the ~/dup_prefs folder, all of these commands work fine: backup, check, list, etc.

duplicacy info -h tells me

  1. I need to specify the storage url (odd, as that’s in prefs)
  2. And these flags that seem relevant:
-encrypt, -e 			The storage is encrypted with a password
-repository <repository directory> 	retrieve saved passwords from the specified repository

Side note: for me this is one of those occasions when the nomenclature “repo” is just not helpful: what does the CLI want from me, the location of the source files to back up (~/) or the location of the .duplicacy folder (~/dup_prefs/)??

If I run:
duplicacy info /Volumes/HD/storage

I get this info:

The storage is encrypted with a password
default
miniM4

So it’s working here, and giving my storage name (default) and my snapshot ID. But if I try to decrypt…
duplicacy info -e /Volumes/HD/storage

I get:
Failed to retrieve the config file: cipher: message authentication failed

But I don’t think the problem is accessing the keyring, because if I run the above with the -d flag, I get this:

Reading the environment variable DUPLICACY_PASSWORD

Reading password from keychain/keyring
Using 16384 iterations for key derivation
Failed to retrieve the config file: cipher: message authentication failed

As far as I can tell, it’s not failing to get my storage password, but failing at some next step.

For what it’s worth, I’ve also tried all of these:

duplicacy info -repository ~/ /Volumes/HD/storage
duplicacy info -repository ~/dup_prefs/ /Volumes/HD/storage
duplicacy info -e -repository ~/ /Volumes/HD/storage
duplicacy info -e -repository ~/dup_prefs/ /Volumes/HD/storage

They all fail with:
Failed to retrieve the config file: cipher: message authentication failed

#2

When I tried, it failed to find password in the first place. It seems it looks in the keychain regardless of whether the password is present in the preferences file. Add -d flag to see verbose logging.

Perhaps in your case it finds wrong password in keychain. Launch keychain access and search for “duplicacy”.

#3

See above for the results with -d flag (buried in the middle of my original post). It seems to me like it’s reading the password properly from keychain, but that’s not enough to make info work.

I can definitely confirm that all my credentials stored in keychain are working fine for all other duplicacy commands.

#4

It definitely got a password from somewhere, and it was a wrong one. “cipher authentication failure” == bad password.

Try explicitly setting the password in the environment variable, and see if that works, e.g.

DUPLICACY_PASSWORD='PA$$W0RD' duplicacy -d info ....

If that works – you’ll know that it does indeed pick wrong password from somewhere. My keychain, as an example, contains massive number of duplicacy keys, it could be using some other one.

massive number

image
image1484×1818 204 KB

So there are likely two issues: it does not look for password in the correct place; it looks and finds the wrong password in the wrong place.

#5

It seems to me it’s some sort of design intention (or a bug) that prevents duplicacy from retrieving the keychain/keyring password only with invocation of the list command.

I can confirm the following:
duplicacy info -e /path/to/storage
Fails to retrieve the password for the storage, stored in keychain

If I first:
export DUPLICACY_PASSWORD=MyPwd
Works.

But also, if use the security command to retrieve the password from keychain:
export DUPLICACY_PASSWORD=$(security find-generic-password -a local_password -s duplicacy -w)
Also works.

I can only guess that this has something to do with the way that the info command is written, such that it requires specification of the storage. For all the other main commands, the storage path is read in preferences. All those commands also work with the pwd stored in keychain. But info does not.

#6

Not that anyone cares, but looking at the source code, I observe the following.

First, info is defined by its own separate function, whereas all the primary duplicacy functions are defined in main (). Second, there’s a specific comment about setting this up so it avoids overwriting the current storage password with the password fed to it here.

Finally, I don’t know anything, but it looks to me from reading the code (line 1348 of duplicacy_main) that Duplicacy is meant to ask for the password. But for some reason I think it’s reading the blank password and failing before it can ask. Here’s the code:

password := ""
	if isEncrypted {
		password = duplicacy.GetPassword(preference, "password", "Enter the storage password:", false, resetPasswords)
	}

I’ve tried the info command a dozen different ways, and it’s never responded with “Enter the storage password.”

#7

I do ¯\_(ツ)_/¯

It would ask for a password if any other ways to get password would fail first:

In your case it successfully gets the password from keychain, evidently, the wrong one. Why does it get the wrong one – no idea, perhaps the password ID is incorrect.

To confirm, pass -d flag, and observe LOG_DEBUG("PASSWORD_KEYCHAIN", "Reading %s from keychain/keyring", passwordType).

#8

My guess is that it’s not actually trying to get the pwd from keychain, just reading a blank pwd. I say this because unlike your Mac’s keychain, this is a test setup on a laptop I don’t use much, and it has only ONE duplicacy pwd in the keychain. And that pwd works fine for all other duplicacy commands.

But in any case, once I’m back at that computer, I’ll test it out with the debug command you give above…

1 Like
#9

OK, hours later, I think I understand.

The problem is #10 and the solution is #11. See here:

1 Like