Report privately through GitHub Security Advisories. Never open a public issue, discussion, or pull request for a suspected vulnerability.

If the advisory form is unavailable to you, email bakirgdev@gmail.com with SECURITY in the subject. The same two channels are listed at https://crocapp.dev/.well-known/security.txt.

Useful in a report:

• What an attacker gains, and what access they need to start.
• Steps to reproduce, ideally with the exact code phrase flow, relay, and platform.
• Version or commit, plus OS version and device.
• Whether the same behavior reproduces with the upstream croc CLI.

CrocApp has a single maintainer, so there is no guaranteed response time and no bug bounty. Reports are read and answered as soon as reasonably possible. You will be told whether the issue is accepted, and credited in the advisory when it is fixed, unless you ask not to be.

Fixes are announced in the GitHub Security Advisories for this repository, and the release that carries the fix names it in CHANGELOG.md and in its release notes.

Please hold public disclosure for 90 days from the report, or until a fix ships, whichever comes first. If the 90 days pass with no fix and no agreed extension, publish. Ask for an earlier date if a bug is being exploited and waiting is worse than telling people. Findings on your own devices and your own relay are welcome. Do not test against other people's transfers, and do not attack the public relay infrastructure.

In scope, meaning report it here:

Examples of what belongs here: a code phrase or transfer leaking into logs, a pasteboard, or a screenshot; sandbox or entitlement misuse; App Group data readable where it should not be; incorrect handling of a declined or cancelled transfer that still writes files; path traversal in received file names; a relay address or password persisted where it should not be.

Out of scope, meaning it belongs upstream in croc:

• The transfer protocol itself, PAKE, the session key derivation, and the relay design.
• Anything that reproduces identically with the croc CLI and no CrocApp involvement.

If you are unsure which side a bug lives on, report it here and it will be routed.

Also out of scope: reports generated by a scanner with no demonstrated impact, missing hardening that changes no attacker capability, and anything requiring a physically unlocked device that the attacker already controls.

Releases are built in GitHub Actions, and the .dmg and .zip assets carry a build provenance attestation. Verify a download before you run it:

gh attestation verify <file> --repo bakirgdev/CrocApp

SHA256SUMS.txt ships alongside them and covers the same three files. An asset that fails either check, or one that appears anywhere other than this repository's releases page, is worth reporting.

Not worth reporting: the macOS builds are ad-hoc signed, not signed with a Developer ID and not notarized, because no certificate exists yet. Gatekeeper refusing the first launch is that, working as expected, and it is tracked in docs/known-issues.md.

Transfers are end-to-end encrypted, the code phrase authenticates both sides, and the relay only ever sees ciphertext. That is the whole claim.

Supporting facts, not claims: no telemetry, no analytics, no accounts, transfer history stays on the device, and you can point the app at your own relay. Dependencies in crocmobile/ are scanned by govulncheck on every CI run and again on a weekly schedule.