pass command instead of password in zuliprc?

[dkwo]

My zuliprc contains a [key] entry, which I guess is derived from the password.
Would it be possible (or maybe already is? I did not find documentation) to have a pass comand instead, like e.g. in mbsync or similar, so the key entry would look more like "PassCmd "/usr/bin/pass name@domain"?

[neiljp]

Thanks for the inquiry! Is this a blocker to you being able to use Zulip or Zulip-terminal?

I wasn't familiar with mbsync, and it took me a while to figure out what you meant by a 'pass command', since I wasn't familiar with that tool either :)

My understanding of your query is that you're wanting to store the password-like detail centrally in a pass password store, and extract it on-demand upon starting the application?

Currently zuliprc (-style) files generated by the Zulip web app have the form of:

[api]
email=...  # login (email or username)
key=...    # key
site=...   # server

Zulip-terminal uses the python zulip wrapper library, and further details on the structure of this kind of zuliprc file is at:
https://github.com/zulip/python-zulip-api/tree/main/zulip (README.md)

As a client we could implement this feature individually, since we could support arbitrary features/extensions in a zuliprc file, a little like we do right now for our current options. However, if we added such an option, we may want to coordinate with the larger community to coordinate on this.

The Zulip server supports other login methods that we have yet to incorporate, which are typically browser-based, and mostly about connecting to a central authority (see eg. https://zulip.com/help/configure-authentication-methods). My understanding is that your request is specifically for a local authentication feature; the reason I mention this is I'm wondering if the deferral of the authentication to a command might be a common factor to both if we implemented these.

[dkwo]

Thanks for looking at this, and sorry for being cryptic. You got me right.
I'm mostly concerned with local auth, but indeed a pass cmd could also deal with tokens.
My concern is that I don't want to store key material in the config (zuliprc), so that it can be checked in git with other dotfiles.

To keep the analogy with mbsync, the token case (for oauth) has PassCmd "~/bin/mutt_oauth2.py ${XDG_DATA_HOME}/oauth-tokens/gmail.tokens".

[dkwo]

To be unambiguous: the pass cmd option shuold let us use pass, gopass or whatever else we can use from the terminal.

[neiljp]

@dkwo To confirm the original intent here:

• the zuliprc could be in a standard location (enabling eg. .config in git, as per Improve zuliprc location/specifying (eg. dot-file or .config/) #678)
• the private password/token could be stored in a separate encrypted location
• the zuliprc would have some way to point to a command that starts the extraction of the appropriate password/token (presumably prompted), rather than embedding it in the zuliprc file (ie. a PassCmd or equivalent)

Based on how we currently include zulip-terminal configuration as extra data in the zuliprc, the above would seem the approach to take.

However, we're hoping to look at #678 this Summer, and there are benefits from separating the client config from the bare zuliprc (with only the [api] section). For example, if one resets the API key then the file could be easily updated separately from config, and central config could be distinct from per-server config. If this separation was achieved, could the 'private' location you use also store the details in the [api] section in such a way that it would be easily integrated with an application?

If so, the bare zuliprc downloadable from Zulip (or via the API, or zulip-terminal) could be placed in the more secure location, with a redirection like PassCmd for the entirety of the login. Is that an established approach with these tools?

[neiljp]

@dkwo Thanks for your feedback so far, and it's absolutely fine to continue clarifying the requirements here, but just to let you know: I started a discussion on chat.zulip.org regarding this here, since this could be relevant for other code generating and consuming zuliprc files.

[dkwo]

Thanks for the update.
I agree that xdg_config_home would be a good place for the dotfiles.
Usually, the command is able to invoke whatever external tool one uses, a common use being pass. So the idea would be to have a line in the config that looks like PassCmd /usr/bin/pass entry.name@email. Makes sense?

[neiljp]

Re my last paragraph/question in this comment, I saw that pass can handle some extra data, but I wasn't sure how transparently it could handle eg. an entire normal zuliprc (without zulip-terminal data) - or other similar tools.

[Gopinath-Mahendiran]

I would like to resolve this , but I need some more additional information about the issue. could anyone help me to understand the problem in a better way?

[dkwo]

@Gopinath-Mahendiran Sure. What is unclear from the above discussion?

[Gopinath-Mahendiran]

explain in detail that how the flow should be once we run the application?
It would help me to work with the problem clearly.

[dkwo]

The flow is: config file contains a line that specifies an external command that when invoked prints to stdout whatever password/token/secret, and zulip-term reads such output when a password is needed. This should be agnostic about which encryption or program is used, just use its output as it would use a password typed by the user.

[Gopinath-Mahendiran]

@dkwo is it ok to store the encrypted api key in separate file like ~/.zulip_api_key

when the application runs, command in the zuliprc file will retrieve the encrypted key and decrypt it and it can be used for login

or else ,want to create an password manger like system utility for securely storing the api key