Coredence

Security

How the build is signed, and how to check

The app is distributed outside the App Store, which means the signature is the only thing standing between you and a tampered copy. Here is exactly what is on it and how to verify it without trusting us.

What every release carries

  • Developer ID signature

    Signed with an Apple-issued Developer ID certificate and a secure timestamp, so the signature stays valid after the certificate expires.

  • Hardened runtime

    Code injection, unsigned libraries and debugger attachment are all refused by the system.

  • Notarised and stapled

    Apple has scanned the build and the approval ticket is attached to the disk image, so Gatekeeper can check it without a network connection.

Verify a copy before opening it

These are the same checks the release script runs. They answer two different questions: whether the signature is intact, and whether Gatekeeper would let the build open on a machine that has never seen it.

$xcrun stapler validate Coredence.dmg
$codesign --verify --deep --strict --verbose=2 /Applications/Coredence.app
$spctl -a -vvv -t install /Applications/Coredence.app

The last one should say source=Notarised Developer ID. If it does not, do not open the file.

Why it is not sandboxed

A sandboxed build could not read ~/.karaca/brain.db or run the engine, which is the entire function of the app. The trade is deliberate and it is why the App Store is not an option. What the app actually does with that access is narrow: it opens one database read-only, and it invokes one command-line tool you installed yourself.

Reporting something

Anything that is not sensitive belongs in an issue on the public repository. For something that should not be public, open a private security advisory there instead — it stays between you and the maintainer until there is a fix.