It seems like by default, any application can access secrets of any other application. I assume xdg-desktop-portal will isolate apps that access the wallet through it, but any app can use the command line tool to retrieve passwords.
Is there some reason this is fine that I can’t see? Does it just assume you are always running either trusted code or flatpaks? Have I enabled bad settings? What is the recommended setup?
I am not a developer but it seems like it should be technically possible to always isolate apps secrets from each other even within the same wallet (like MacOS I believe). Even the command line tool could be limited to only secrets added by that shell.
Secrets and the collections they reside in can be locked, secrets could be encrypted by the client which added them.
Generally most applications will fall into either of those two categories: trusted (installed through the system repository) or sandboxed (Flatpak, Snap).
AppImage based installs are a bit of an outlier though.
Without sandboxing that is not so easy since the best you could do is get the path of the caller. Which means you either have a trusted application (installed in a system wide location) or can’t really rely on it.
The service would only be able to identify the tool not who called it or determine whether that was a shell script.
Thank you that is very informative and basically answers my questions!
Just for a little more context on where I was coming from,
Yes, I was thinking for system applications, I think that would still be valuable even if they are trusted.
That is probably better than nothing, and I mentioned it because it is similar to what MacOS does. You can assign keychain entries to be accessible by the app “Terminal” (although I’m not 100% sure what “Terminal” refers to, whether it is the specific terminal emulator you use, the shell, the CLI of the Apple keychain, etc.).
I haven’t read the specification in any sufficient level of detail but I would be surprised if a provider wasn’t allowed to do that.
Current implementations probably prioritize safe and reliable storage and retrieval, including locking, over this type of process identification.
Also keep in mind that this could potentially break update paths, e.g. application getting renamed.
That might be different to confining the CLI tool.
E.g. the terminal might have some heuristic to “detect” password prompts and then act as a mediator between the credential API and the shell prompt.
Some console applications, e.g. ssh/gpg, have such a delegation mechanism built in and can be configured to ask a helper process for credentials. This can then be a tool that accesses the session’s credential store.
On the other hand, quite some cases of CLI interfaces for a service are considered to be more of a Shell API or Shell Binding than a tool, so restricting it to just act as a client could break already established use cases.
It might have to be something that is off by default and need to be enabled by users who know they don’t need this level of access.