SettleBell is intentionally small and one-way. Its security model is based on fixed notification content, minimal local signals, private CloudKit storage when enabled, and guarded installation paths.
We welcome responsible security reports. When Report a vulnerability is available on this repository's Security tab, use it to open a private report visible only to you and the maintainers.
If that button is not available, please do not post sensitive details in a public issue, discussion, pull request, or social post. Private vulnerability reporting must be enabled and verified before any public tag or release proceeds.
A useful report includes:
- the affected commit or version;
- relevant macOS, iOS, Xcode, and Pi versions;
- clear reproduction steps;
- expected and observed behavior; and
- the potential impact.
Use synthetic data. Never include credentials, real prompts or model output, unrelated source code, personal paths, signing or CloudKit identifiers, provisioning data, or device identifiers. If those details seem necessary, describe the situation in prose instead of pasting the data.
Security reports are taken seriously and will be reviewed as soon as reasonably possible. SettleBell is maintained by one independent developer, so no fixed response time can be promised; investigation and fix timing will depend on severity and maintainer availability.
SettleBell is currently distributed as source. Security fixes land on main and in
later source releases. Rebuild from a reviewed current revision rather than
patching an installed app bundle in place.
- SettleBell is one-way and notification-only.
- Only
startandsettledcross the Pi-to-native boundary. - Notification text is fixed in source and uses a normal system sound.
- The minimum eligible duration defaults to 30 seconds.
- CloudKit uses the private database and allowlisted fields only.
- No control, reply, approval, terminal, file, log, prompt, or model-output data crosses any boundary.
- Local IPC is same-user, bounded, non-networked, and rejects non-FIFO objects, insecure permissions, and symlinks.
- Initial CloudKit subscription setup and notification permission request require explicit user action. Opening an already-configured iPhone app may check iCloud and the existing subscription and re-register for remote notifications when CloudKit is enabled and notification permission is already allowed. This refresh does not request permission or change the subscription.
- No secrets or personal identifiers belong in the repository or Git history.
- Source-local installation requires trusted pinned or checksummed source,
explicit approval, exact public-development validation, no
sudo, and bounded compressed recovery. Ad-hoc signing is not publisher authentication. - Install and uninstall must refuse private, foreign, and future official apps; establish rollback and commit state before destructive boundaries; route normal termination signals through cleanup; and never edit Apple's private notification databases.
- PiPing-to-SettleBell migration is side by side: preserve PiPing
v0.1.0, request fresh identity-keyed permissions, retain the deployed CloudKit v1 wire/storage identifiers initially, and never copy preferences, unread state, approval state, or private configuration. Legacy retirement requires its own exact validation, user confirmation, rollback, and approval gate.
These boundaries are part of SettleBell's design and acceptance criteria. They do not replace the warranty terms in the MIT License.
Changes that affect trust boundaries, local IPC, lifecycle data, CloudKit, notifications, installation, or signing receive repository-wide security review before real-device acceptance. Unresolved high-confidence findings block that acceptance.
Before any tag, release, or release-asset upload, maintainers also complete the release audit against the exact revision and archive payload. Approval for one publication action never authorizes another. See Releasing for the complete process.