Security and verification

Report a vulnerability

Use GitHub Security Advisories. Include the affected version or commit, impact and safe reproduction steps. Do not publish unpatched vulnerabilities or include secrets and unrelated personal information.

Check a downloaded app

After copying the published release to Applications, these read-only commands inspect its signature and Gatekeeper assessment:

codesign --verify --deep --strict --verbose=2 /Applications/Shaar.app
codesign -dv --verbose=4 /Applications/Shaar.app
spctl --assess --type execute --verbose=4 /Applications/Shaar.app

Expected release identity: bundle identifier com.arcusis.browser, Developer ID Application for Arcusis LTD, team F9Z784RA6D. A successful local check applies to that installed artifact; it does not audit every browser feature or upstream engine source.

What release tooling verifies

Release tooling signs nested components, verifies signatures, notarizes and staples the app and DMG, and signs the Sparkle update archive. The release workflow cross-checks public download metadata, bundle identity, versions, feed URL and Ed25519 signature before publishing the appcast. See release verification.

What development checks establish

Source tests, engine probes and hosted UI captures provide different evidence. A green source check does not prove physical-device behavior, real account sign-in, every extension, permission prompt or website compatibility. A matching engine archive hash proves payload integrity against the pin, not upstream source provenance or signer identity.

Read source and native verification, test coverage and the workflow results.