Only the latest tagged release is supported. Patches land on main and ship with the next tag.

If you believe you've found a security issue, do not open a public GitHub issue. Instead:

1. Email the maintainer at the address on the @SNGWN GitHub profile, or
2. Use GitHub's private vulnerability reporting on this repository.

Include:

• A description of the issue and the impact (what an attacker could do)
• Steps to reproduce, or a proof of concept
• The version (commit hash or release tag) you tested against
• Whether you'd like credit in the fix announcement

You should expect:

• An acknowledgement within 72 hours
• A triage assessment within 7 days
• Coordinated disclosure once a fix lands

In scope:

• Anything that lets a non-privileged process read decrypted clipboard history
• Anything that lets an attacker bypass the AES-GCM seal of the on-disk file
• Any path that causes Clip-Board to write to disk in plaintext
• Any path that causes Clip-Board to make a network request
• Build or release artifacts that don't match the source

Out of scope:

• An attacker with the same user privileges reading process memory while the app is running (this is fundamental to clipboard managers — see the threat model in the README)
• The user losing their Keychain entry (history is intentionally unrecoverable in that case)
• Issues that require the user to install a malicious app or grant another process Accessibility or Full Disk Access

• Symmetric AES-GCM (256-bit) via Apple's CryptoKit
• Random nonce per seal (generated by CryptoKit, included in sealedBox.combined)
• Key stored in Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and kSecAttrSynchronizable = false
• File mode 0600, directory mode 0700
• Atomic writes (no partial-file exposure on crash)

When you select an item, Clip-Board writes it to NSPasteboard.general (the system clipboard) and synthesizes ⌘V into the previously focused app. That data lives in plaintext on the system pasteboard until you copy something else — any concurrent process polling the clipboard (including other clipboard managers, password managers, or apps with paste-monitor entitlements) can see it during that window. This is intrinsic to "paste anything into any app" and is not specific to Clip-Board; if you need to scrub sensitive items proactively, copy a neutral value (e.g., a single space) afterwards.

Clip-Board is not sandboxed, and this is intentional. The macOS App Sandbox blocks NSRunningApplication.activate() on a foreign app, which makes "bring your last-focused app back to front, then synthesize ⌘V into it" silently fail. Every shipping clipboard manager that does cross-app paste injection (Maccy, Paste, Alfred, Raycast) runs unsandboxed for the same reason. Releases prior to 1.2.3 shipped with app-sandbox = true set in the project; that was a packaging carry-over from the Xcode template, not a security decision, and it broke auto-paste. As of 1.2.3 the entitlements file explicitly sets it to false with an in-file comment explaining why.

What we still do for hardening, in lieu of the sandbox:

• Hardened runtime ON (ENABLE_HARDENED_RUNTIME = YES) — Library Validation is enforced.
• No network entitlements requested or used. The binary does not link Network.framework, CFNetwork (except via system Foundation, which is unavoidable but unused for outbound), or third-party HTTP libraries. Verify yourself:

  otool -L "Clip Board.app/Contents/MacOS/Clip Board"

  Only Apple system frameworks should be listed.
• Network client/server entitlements explicitly false in the checked-in entitlements file at Clip Board/Clip Board.entitlements. These are defaults, but stating them explicitly means a reviewer can diff source vs. signed binary and confirm intent. Verify the signed binary's entitlements with:

  codesign -d --entitlements - "Clip Board.app"

• History encrypted at rest with AES-GCM-256, key in Keychain (WhenUnlockedThisDeviceOnly, non-syncable). See the Cryptographic details section above.
• History file mode 0600, directory mode 0700, atomic writes (no partial-file exposure on crash).
• History storage lives under ~/Library/Application Support/ClipboardManager/ (the conventional unsandboxed path; previously inside the sandbox container, now plain Application Support).

If you have suggestions for hardening any of the above — particularly key rotation, in-memory protection, or schema integrity — open an issue (for design discussions) or follow the reporting process (for vulnerabilities).