Skip to main content
← Back to list
01Issue
FeatureClosedSwamp CLITeam
AssigneesNone

Relationships

#964 Support confidential visibility for non-security issues

Opened by evrardjp · 7/4/2026

Summary

Users should be able to file an issue as confidential even when it is not strictly a security vulnerability.

Current behavior

The CLI has a dedicated swamp issue security path for vulnerability reports, but ordinary bug and feature reports do not expose a documented way to mark the issue as confidential at creation time.

Expected behavior

Provide an option to create bug or feature issues with confidential visibility, for example swamp issue bug --confidential or swamp issue feature --confidential. Security issues should remain confidential by default, but non-security issues should be able to opt in to confidential handling when they contain private data (they mostly should not, but it can happen)

Why this matters

Some reports require private data to be useful, such as internal identifiers, private repository names, customer-specific details, logs, paths, or reproduction context. Users may avoid including enough information to diagnose the problem because they do not want to leak private information publicly. A confidential option would let them provide actionable details safely without mislabeling the report as a security vulnerability.

Suggested behavior

  • swamp issue security remains confidential by default.
  • swamp issue bug and swamp issue feature remain public/non-confidential by default.
  • Bug and feature reports can opt in to confidential visibility.
  • The CLI should make the visibility clear before submission and in JSON output.
02Bog Flow
OPENTRIAGEDIN PROGRESSCLOSED

Closed

7/8/2026, 11:40:42 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

stack72 commented 7/8/2026, 11:40:42 PM

@evrardjp Thanks for raising this — it's a real concern and we've taken a different approach to solve the underlying problem.

Rather than adding --confidential visibility, we've implemented automatic client-side redaction of identifying information before issue content ever leaves the machine. This means sensitive data never reaches the server in the first place, which is a stronger guarantee than access controls.

When you run swamp issue bug (or feature/security/ripple/edit), the CLI now automatically scrubs:

  • Credentials, tokens, API keys, passwords
  • Email addresses, phone numbers, SSNs, credit cards
  • IP addresses → stable placeholders like [IP-1], [IP-2]
  • Hostnames/FQDNs → stable placeholders like [HOST-1], [HOST-2] (public hosts like github.com are preserved)
  • Home directory usernames → /Users/[REDACTED]/...
  • Connection string passwords (scheme and port preserved)

The placeholders are stable within a single issue — the same IP always maps to the same [IP-N] — so diagnostic structure is preserved. You can still tell "it was two different hosts" without revealing which ones.

We chose this over --confidential because in practice, an opt-in flag either goes unused (people forget) or gets applied to everything (agents/automation default to "safe" and mark every issue confidential). Automatic redaction handles the common case without any user action, and the data never exists server-side to be leaked.

See #1803 for the implementation.

Sign in to post a ripple.