Some applications do not work with this service

[mbainter]

I was hoping maybe this would work where pass_secret_service and others have failed, but I am starting to think that gnome-keyring has functionality that other apps are depending on that isn't actually part of the FreeDesktop API. None of the alternatives I've tried work with everything, not even KeyPassXC.

In case it's helpful for you, two consistent examples are aws-sso-cli and 1Password.

With aws-sso-cli it works if I configure it to use pass directly, but if I set it to use the secret-service backend, then aws-sso gets the secret from it when the login succeeds and puts it in the store but follow-up attempts to use it always fail with:
WARN unable to load keyring data error="The specified item could not be found in the keyring" and an error that I have to log in before using it. Every login creates a new credential in the store:

❯ gopass list secret-service/
secret-service/
└── awsssocli_XXXX/
    └── YYYYYYYY

It even appears to find it when aws-sso-cli tries to retrieve it:

method call time=1752113828.755153 sender=:1.149 -> destination=org.freedesktop.secrets serial=4 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=OpenSession
   string "plain"
   variant       string ""
method return time=1752113828.755299 sender=:1.40 -> destination=:1.149 serial=104 reply_serial=4
   variant       string ""
   object path "/org/freedesktop/secrets/session/ZZZZZZZZ"
method call time=1752113828.755441 sender=:1.149 -> destination=org.freedesktop.secrets serial=5 path=/org/freedesktop/secrets; interface=org.freedesktop.DBus.Properties; member=Get
   string "org.freedesktop.Secret.Service"
   string "Collections"
method return time=1752113828.755595 sender=:1.40 -> destination=:1.149 serial=105 reply_serial=5
   variant       array [
         object path "/org/freedesktop/secrets/collection/awsssocli_XXXX"
         object path "/org/freedesktop/secrets/collection/default_AAAA"
      ]
signal time=1752113828.758187 sender=org.freedesktop.DBus -> destination=:1.149 serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost

1password by contrast doesn't work with any backend I've tried so far except gnome-keyring. I would bet it works with kwallet as well, as it seems to try that by default if no secret service exists. When it attempts to write its token to the store this is the output in dbus:

method call time=1752113124.634310 sender=:1.135 -> destination=org.freedesktop.secrets serial=2 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=OpenSession
   string "dh-ietf1024-sha256-aes128-cbc-pkcs7"
   variant       array of bytes [
         40 d8 93 <snip> 1d 2c 2c
      ]
error time=1752113124.634736 sender=:1.40 -> destination=:1.135 error_name=org.freedesktop.DBus.Error.NotSupported reply_serial=2
   string "Algorithm is not supported"

I don't know what all your plans are for this service, but if you're looking for it to be a fully compatible replacement hopefully this helps. If these aren't problems you aren't looking to solve please feel free to close this. If there is any other data I can gather that you'd find helpful let me know and I'll try to test it further.

[grimsteel]

Not sure what's going on with aws-sso-cli at first glance. It looks like the error is coming from 99designs/keyring. I'll see if I can debug this to find out what exactly is causing the error.

It may have something to do with the whole concept of locking/unlocking specific items and collections. This implementation isn't technically spec-compliant as nothing every actually gets locked/unlocked - I just proxy everything to pass/gpg.

It looks like 1password doesn't work because it's requesting to use an encryption algorithm when communicating with the service (rather than just plaintext DBus communication). This is definitely something I want to support!

[grimsteel]

I implemented the dh session encryption algorithm in v0.4.0. Could you try that out and see if it 1password works with that?

[grimsteel]

I think I found out why aws-sso-cli isn't working. The keyring library they're using expects the collection path to be exactly equal to the label they provided. Unfortunately, I add some unique characters on the end of the label they supply (in this case, awsssocli) to reduce the chance of any conflicts.

Their behavior isn't actually spec-compliant - the spec for paths does say that the collection path segment can be an encoded or truncated form of the label supplied. Instead, they should be using aliases to consistently reference their collection.

It looks like they internally use gnome-keyring's encoding function to make sure that they can ensure that the actual collection path created is always the same as the one they provide, but this naturally only works for gnome-keyring.

---

I can alter the collection create function to only add the random ID on the end when the label they provide would otherwise create a conflict in the collection path.

[grimsteel]

I've released v0.4.1 with that change - could you see if that works, @mbainter?