Feature Request: Password command instead of storing the Bunny API key in a .local folder #1

Open
opened 2026-09-18 20:23:30 +00:00 by prosumer · 3 comments

Not a fan of the Bunny API key being stored in a .local folder.

A password command like Halloy has would be nice…

I’d use that with 1Password (CLI) like this:

password_command = "/opt/homebrew/bin/op read 'op://Private/Bunny/API/key'"
Not a fan of the Bunny API key being stored in a `.local` folder. A [password command](https://halloy.chat/configuration/servers#password-command) like Halloy has would be nice… I’d use that with 1Password (CLI) like this: ``` password_command = "/opt/homebrew/bin/op read 'op://Private/Bunny/API/key'" ```
Owner

Replied in IRC but also here.

.local is already used for temp backups during updates to preserve rules so it made sense. The file itself is acting like a stand alone .env. I can look into better options but the goal is making it so people don't have to keep typing the key, not have to download something else, and in general just not have to do anything special outside of run the command and load the key once and it just remembers it

Replied in IRC but also here. .local is already used for temp backups during updates to preserve rules so it made sense. The file itself is acting like a stand alone .env. I can look into better options but the goal is making it so people don't have to keep typing the key, not have to download something else, and in general just not have to do anything special outside of run the command and load the key once and it just remembers it
brindly self-assigned this 2026-09-18 23:49:47 +00:00
Author

I understand.

Would you consider storing the key in a “real” .env file?

Then I can probably use 1Password Environments to persist the key without storing it on disk.

I understand. Would you consider storing the key in a “real” `.env` file? Then I can probably use [1Password Environments](https://www.1password.dev/environments) to persist the key without storing it on disk.
Author

Oh, even that's too complicated. If you can add an extra check for an environment variable I'm good.

Suggestion:

  if [[ -f "$BUNNY_KEY" ]]; then
    key="$(<"$BUNNY_KEY")"
  elif [[ -n "${BUNNY_API_KEY:-}" ]]; then
    key="$BUNNY_API_KEY"
  else
    bunny_ask_key
  fi

I can then use this to supply the Bunny API key and prevent storing it on disk:

BUNNY_API_KEY="op://Private/Bunny/API/key" op run barrier ...
Oh, even that's too complicated. If you can add an extra check for an environment variable I'm good. Suggestion: ``` if [[ -f "$BUNNY_KEY" ]]; then key="$(<"$BUNNY_KEY")" elif [[ -n "${BUNNY_API_KEY:-}" ]]; then key="$BUNNY_API_KEY" else bunny_ask_key fi ``` I can then use this to supply the Bunny API key and prevent storing it on disk: ``` BUNNY_API_KEY="op://Private/Bunny/API/key" op run barrier ... ```
Sign in to join this conversation.
No milestone
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
brindly/barrier#1
No description provided.