The terminal blinked, waiting for the next command. You type gpg --version and see the same flags you’ve seen for years. GnuPG is powerful, but it moves slowly. The core works well, yet the pain points repeat. Longstanding issues remain open. New cryptographic needs appear, but the toolchain lags behind. This is where focused, public GPG feature requests matter.
Most users stick with defaults. But under the surface, engineers want better automation, smarter key management, and faster integration with CI/CD pipelines. Current GPG workflows require manual trust establishment, static configuration, and cumbersome scripting. A robust feature request backlog can push for:
- API-level access for key operations without shell parsing.
- Native JSON output across commands for easier parsing.
- Stronger defaults for key generation with modern algorithms like Ed25519 and Curve25519.
- Partial subkey refresh without re-importing full keyrings.
- First-class support for hardware-backed keys and YubiKey integration without complex agent hacks.
A public, searchable list of GPG feature requests helps developers align on priorities and avoid duplication. Instead of private mailing list threads, requests should live in an issue tracker with tags, milestones, and clear statuses. Grouping them into security, UX, and performance categories makes triage faster. When top-voted items reach consensus, maintainers see the demand and can act.