Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Allow silencing the keyring-unavailable warning on headless machines

未关闭
#522 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
go
领域
cli, security

调研方向

Start by locating the code that emits the “system keyring unavailable” warning, then trace how credential-store selection and the --json and --quiet paths handle warnings. Before changing behavior, resolve which requested option is intended; done should cover deliberate file-store selection, appropriate warning behavior for interactive and structured-output runs, and regression coverage.

由索引模型根据 Issue 内容生成。

描述

Context

On a headless Linux server with no Secret Service or keyring, every hey invocation prints:

warning: system keyring unavailable, credentials stored in plaintext at ~/.config/hey-cli/credentials.json

It prints on every call, including --json and --quiet runs. Scripts that capture stdout and stderr together, or that treat any stderr output as a problem, have to filter it out each time, and the line gets into logs and error messages. In our case the real error in a failure report was hidden behind this warning.

The plaintext file fallback is fine for this kind of machine, which runs as a dedicated user with 0600 permissions. The problem is only that the warning can't be turned off.

No account-specific details below.

Ask

  • A way to choose the file store deliberately and silence the warning: hey config set credential_store file, or an env var such as HEY_CREDENTIAL_STORE=file.
  • With --json, put the warning in the JSON (for example a warnings array) instead of writing it to stderr, or print it at most once per machine.
  • Keep showing it by default for interactive first-time setups, where it's useful.

Related (closed): #352, #453 (keyring behaviour on Linux).

主要语言
Go
星标
414
派生
53
平均合并
1 天 5 小时
30 天内合并 PR
78

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

basecamp/hey-cli 的其他 Issue

查看 basecamp/hey-cli 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。