Dbus "authentication failed"

Hoping to get duplicacy working with dbus secrets on my Fedora 34 system.

When running duplicacy with -d in a zsh gnome-terminal session, I see the following:
Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: authentication failed

First chasing a SecretService issue:

Looking at journalctl, I have a corresponding error to duplicacy attempts to access the keyring:
gnome-keyring-daemon[1887]: couldn't write to client: Error sending data: Broken pipe

Using lssecrets, as mentioned by @gchen in Problems configuring Duplicacy with keyring (Linux), the first time failed with
Error: Couldn't get secret service for unkown reason No such secret item at path: /org/freedesktop/secrets/collection/login/7

Running seahorse did not list a “login” keyring and attempts to create an additional keyring did not appear to have any affect (but it did actually create them).

Running gnome-keyring-daemon --components=ssh,secrets --replace appears to have resolved some bad state of the SecretService. After rebooting the system, keyring was present as well, so it seems like it was in some bad state.

Sill receiving same error:

Now, that the keyring access appears to be in a good state (lssecrets is returning values and seahorse has keyring listed), I still receive the same error from duplicacy:

Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: authentication failed

This appears to be the same as https://github.com/gilbertchen/duplicacy/issues/565 from 2019. Would be good to close the loop on that issue with any solution from this thread.

The error is generated here:

The best way to debug this is to add a few Printf statements to that file and then compile your own executable. For instance, you can print out what s contains before entering that loop.

Currently running into this same issue. Pretty sure this had worked fine when I initially set stuff up at the end of last year. Not sure the best way to debug - journalctl doesn’t show anything related.

I’ve been having this problem on Arch Linux for months now. I’m happy to try and debug the go.dbus loop but I can’t get duplicacy to build for the life of me–it’s complaining about GOROOTs and GOPATHs etc and I can’t figure out the correct directory structure/envvars/etc to satisfy it. I’d appreciate any pointers so I can get my backups working again

GO111MODULE=off go get -u github.com/gilbertchen/duplicacy/...

Thanks, but that’s for downloading and installing upstream as I understand it…in this case I want to check it out for local development and point it to a local folder for go.dbus, which as far as I can tell, dep and go get aren’t able to do. Any suggestions on how to do that?

It will download and compile everything including :d:, you can make changes to downloaded code and re-run the command again, just skip -u the next time so it goes faster.

Thanks, this seems to work, but GoLand’s debugger isn’t letting me see or set breakpoints outside of the main module with this setup. It would be better to get a proper debugger working than to debug with print statements…any ideas?

In the meantime, stepping through with printf debugging (yuck), we are getting this far:

The result in s at that point is REJECTED, so obviously the AUTH attempt is failing. Inspecting the arguments to authWriteLine(), we’ve got:

name: EXTERNAL v: EXTERNAL status: 0 data: <algebro in hex>

This is as far as I’ve gotten, I’ll probably have to go read the dbus spec to figure out what could be wrong with those variables.

Is your keyring password different from your login password? I’d remove/re-create login keyring to see if this fixes the problem.

It is not, and the issue is occurring on all of my Arch computers where it worked fine before (without any changes to my keyring or login passwords) so I don’t think it’s a local keyring problem. Usually when this happens there is some change or bug in the package that hasn’t hit the major distros yet

So maybe I’m confused…based on the spec, my understanding is we are supposed to first send AUTH EXTERNAL, to which the server responds with DATA (I’ve confirmed this in my testing), and then we send the cred data. What duplicacy is doing right now is sending AUTH EXTERNAL <creds> in the same message without using DATA at all, and the server is responding with REJECTED. Relevant excerpt from spec:

AUTH command

The AUTH command is sent by the client to the server. The server replies with DATA, OK or REJECTED.

If an AUTH command specifies a mechanism, and the server supports said mechanism, the server should begin exchanging SASL challenge-response data with the client using DATA commands.

If the server does not support the mechanism given in the AUTH command, it must send either a REJECTED command listing the mechanisms it does support, or an error.

If the [initial-response] argument is provided, it is intended for use with mechanisms that have no initial challenge (or an empty initial challenge), as if it were the argument to an initial DATA command. If the selected mechanism has an initial challenge and [initial-response] was provided, the server should reject authentication by sending REJECTED.

If authentication succeeds after exchanging DATA commands, an OK command must be sent to the client.

edit: well, I’m kind of stumped now. Manually trying to follow the other flow listed in the spec didn’t work either:

  1. Client: AUTH EXTERNAL
  2. Server: DATA
  3. Client: DATA [username in hex]
  4. Server: REJECTED

Just to make sure, I’ve also deleted and recreated the login keyring and it’s still not saving the passwords, so no idea why it’s failing

Is this commit relevant: do not send data with DBUS auth mechanisms · godbus/dbus@31b5df7 · GitHub

@gchen that patch fixed it! Can you merge it into your fork for duplicacy?