Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add secrets support #1480

Open
pokey opened this issue Jul 6, 2024 · 4 comments
Open

Add secrets support #1480

pokey opened this issue Jul 6, 2024 · 4 comments

Comments

@pokey
Copy link
Collaborator

pokey commented Jul 6, 2024

It would be useful to have a standard mechanism for secrets storage. Something like the following

@mod.action_class
class Actions:
    def secrets_get(name: str) -> str:
        """Get secret by name"""
        ...

    def secrets_set(name: str, value: str) -> None:
        """Get secret by name"""
        ...

I guess they could have type other than str for the value but might be easiest to just use strings as we wouldn't actually know the type statically anyway

There are different ways we could actually register / define the secrets. I personally keep my secrets in a directory called ~/envs, with read/write access only for my user, and where each subdirectory corresponds to the secrets for one service. Eg

/Users/pokey/envs
├── airtable
│  ├── AIRTABLE_API_KEY
│  └── AIRTABLE_BASE_ID
├── openai
│  └── OPENAI_API_KEY
├── openvsx
│  └── OPEN_VSX_TOKEN
├── pypi
│  └── POETRY_PYPI_TOKEN_PYPI
└── toggl
   └── TOGGL_API_TOKEN

So if we wanted to support this kind of setup, we could allow user to have a setting eg

settings():
    user.secrets_dirs = ~/envs/toggl,~/envs/openai

Basically just a comma-separated list of directories, and any files in there will be read, and result in a secret whose name is the name of the file and whose value is the contents of the file, stripped of leading and trailing whitespace

But we could support multiple ways of actually defining the secrets, and they could all probably just register the secrets via the same user.secrets_set(...) api on Talon startup

This would be useful for:

@nriley
Copy link
Collaborator

nriley commented Jul 6, 2024

Do we have support for talon.keychain on multiple platforms? That's what I use…

@pokey
Copy link
Collaborator Author

pokey commented Jul 7, 2024

Ah interesting. 1Password api might be interesting to consider as well

@nriley
Copy link
Collaborator

nriley commented Jul 7, 2024

Agreed, seems like we would be best off with something pluggable, where talon.keychain is one possible backend. I've tried to script the 1Password GUI (https://github.com/nriley/talon_community/blob/20e0fff55c9999785e6d026f4cbded68d55d9003/apps/1password/1password_mac.py#L35) but since it's Electron it's a total pain and very brittle.

I tested and there does not seem to be a talon.keychain implementation for Windows so we'd need something else there.

@auscompgeek
Copy link
Collaborator

auscompgeek commented Jul 7, 2024

There's the 1Password CLI, but first use has a permission prompt, so would be annoying if you don't have biometric auth (since we don't have async Talon actions).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants