main
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Peter Steinberger
|
c48ee7294b
|
docs: explain bridge attachment staging | ||
|
Peter Steinberger
|
3695bfb96e
|
fix: stage bridge attachments with chat guid | ||
Omar Shahine
|
243226951f
|
fix(security): clamp IPC dirs to 0700 and reject symlinked paths (#105)
* fix(security): clamp IPC dirs to 0700 and reject symlinked paths Threat model: a same-UID attacker (another user process, a sandboxed peer that can reach the home dir) can drop a file or symlink into the RPC inbox, or supply an attachment path that points at a sensitive file via a parent-directory symlink, and have Messages.app exfiltrate it as an attachment to an attacker-controlled handle. Mitigations applied at every IPC boundary: - Mode 0700 on .imsg-rpc/, .imsg-rpc/in/, .imsg-rpc/out/ creation. Final chmod handles dirs that already existed 0755 from prior unsandboxed runs. - Refuse any RPC queue path or attachment path where any component (final or parent) is a symbolic link. Walking each component with lstat() — done by SecurePath.hasSymlinkComponent in IMsgCore and the pathHasSymlinkComponent twin in the dylib — catches parent-directory links that realpath()-vs-lexical comparison misses (macOS rewrites /tmp -> /private/tmp, breaking that approach for legitimate paths). - Strict throws for queue dir creation and cleanup in MessagesLauncher (was `try?` swallowing errors), and for ensureDirectory in IMsgBridgeClient. Bridge refuses to start instead of operating on an insecure path. Tests cover both final-component and parent-component symlink detection in SecurePath. Toolchain on this machine lacks swift-testing; tests build clean and ship to be run by Xcode on the maintainer's box. * fix: allow trusted system path aliases --------- Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com> Co-authored-by: Peter Steinberger <steipete@gmail.com> |
||
|
Omar Shahine
|
2d7b506d17
|
fix: macOS 26 bridge regressions — typing/read RPC, effect mapping, attachment registration (#101)
* feat: file-based debug logger for in-process diagnostics NSLog output emitted from the injected dylib is redacted by macOS 26 unified logging when the host process is a system app, which makes diagnosing handler behavior from outside the dylib painful (you can't see anything in Console.app, log show, or the gateway logs). Add an append-only file logger writing to .imsg-bridge.log in the Messages.app sandbox container. Readable from outside, untouched by unified logging. Wire diagnostic entry/exit/state logs through the typing and read handlers so future regressions in setLocalUserIsTyping: / markAllMessagesAsRead behavior across macOS versions can be triaged from log output rather than guesswork. * fix(rpc): expose typing and read methods over JSON-RPC The 'imsg rpc' server only routed chats.list, messages.history, watch.subscribe, watch.unsubscribe, and send. Calls to 'typing' and 'read' (which the openclaw imessage channel plugin and other clients already invoke per the documented vocabulary) returned methodNotFound and silently dropped. The CLI worked because it talks to the dylib bridge directly via TypingIndicator/IMCoreBridge, bypassing the RPC surface entirely. Wire both methods to the same chat-target resolution path used by 'send', so callers can identify the chat by handle (to), chat_id, chat_identifier, or chat_guid. typing accepts a 'typing' bool plus optional 'service'; read takes only the chat target. The dylib-side handlers (handleTyping, handleRead) were already correct — they just had no way to be invoked over JSON-RPC. * fix: expand --effect short names to expressive-send bundle IDs `imsg send-rich --effect invisibleink` was passing the literal short name through to expressiveSendStyleID, so chat.db ended up with expressive_send_style_id=invisibleink and Messages.app refused to render the expressive effect. Messages expects the full bundle id, e.g. com.apple.MobileSMS.expressivesend.invisibleink for bubble effects or com.apple.messages.effect.CKConfettiEffect for screen effects. Add ExpressiveSendEffect.expand() to remap short names at the CLI layer for both send-rich and send-multipart, leave already-prefixed values untouched, and pass unknown names through so the dylib can return its own error. Update --help examples to use the friendlier short names and add unit coverage. * fix: register outgoing transfers properly in handleSendAttachment `imsg send-attachment` was returning a transferGuid and messageGuid but the receiver saw an empty OBJ-placeholder message and chat.db's attachment / message_attachment_join tables had no matching rows. Two gaps versus the BlueBubblesHelper reference: 1. The transfer was never staged into Messages' attachments tree or handed off to imagent. Allocating a guid via `guidForNewOutgoingTransferWithLocalURL:` only reserves the id; the daemon needs `IMDPersistentAttachmentController._persistentPath...` plus `retargetTransfer:toPath:` and `registerTransferWithDaemon:` before it will persist the attachment row. 2. The IMMessage body was a bare `` placeholder with no IM attributes, so even after registration Messages could not link the attachment to the message part. Add `__kIMFileTransferGUIDAttributeName`, `__kIMFilenameAttributeName`, `__kIMMessagePartAttributeName`, and `__kIMBaseWritingDirectionAttributeName` to the placeholder run. Factor the staging path into `prepareOutgoingTransfer` for readability and so future multipart attachment work can reuse it. Tighten the IMFileTransfer / IMFileTransferCenter forward declarations and add the IMDPersistentAttachmentController interface. * fix(rpc): advertise rpc_methods capability in status --json The openclaw imessage channel plugin reads `rpc_methods` from `imsg status --json` to gate which JSON-RPC calls it issues. Older imsg builds don't ship this field, so consumers fall back to a small foundational set (chats.list/messages.history/watch.*/send) and refuse to invoke typing/read/group.* until the user upgrades. The previous commit added `typing` and `read` handlers to RPCServer but didn't advertise them, so the openclaw plugin still gated them off with the message: imessage: typing indicators / read receipts gated off (imsg build pre-dates the rpc_methods capability list). Upgrade imsg (current bridge needs typing+read in rpc_methods). Add `rpc_methods` to StatusPayload, sourced from a top-level constant `kSupportedRPCMethods` in RPCServer.swift so the dispatch switch and the advertised list can't drift apart. * fix: build IMMessageItem first to survive macOS 26 send pipeline On macOS 26 the high-level `+initIMMessageWith…:expressiveSendStyleID:` factories return an IMMessage whose underlying IMMessageItem has empty `bodyData`. imagent reads bodyData (NSArchiver typedstream) when shipping to chat.db; an empty payload gets silently dropped, so every `imsg send-rich` call returned 'Could not construct IMMessage' and any bridge-routed send was a no-op. Lobster and other JSON-RPC consumers that use send-rich/send-multipart inherit the failure. Port 10ce6ab's IMMessageItem-first approach into buildIMMessage: 1. Allocate an IMMessageItem via the 9-arg `initWithSender:time:body:attributes:fileTransferGUIDs🎏error:guid:threadIdentifier:` 2. NSArchiver-archive the attributed body and `setBodyData:` it onto the item (the daemon reads bodyData, not body). Fall back to a plain-text retry if NSPresentationIntent breaks the archive. 3. Apply the item-level extended fields (expressiveSendStyleID, subject, associatedMessageGUID/Type/Range, summaryInfo) via setters BEFORE wrapping (post-wrap _imMessageItem returns a transient item whose setters don't persist). 4. Wrap with `+[IMMessage messageFromIMMessageItem:sender:subject:]`. 5. Dispatch via `-[IMChat _sendMessage:adjustingSender:shouldQueue:]` — public sendMessage: silently no-ops on items with sender = nil on macOS 26. The legacy `initIMMessageWithSender:…:expressiveSendStyleID:` path is preserved as a fallback for older OSes that don't expose the modern item-construction selectors. Smoke-tested on macOS 26.4.1: send-rich now lands in chat.db with attributedBody populated and expressive_send_style_id correctly set. Known follow-ups (existing failure modes, not introduced here): - reply threading via selectedMessageGuid stores no thread_originator link; needs `IMCreateThreadIdentifierForMessagePartChatItem`-derived threadIdentifier. - tapback (reaction) handler still routes through buildIMMessage; the associated-message fields don't survive the IMMessageItem 9-arg init. A dedicated reaction constructor is the right fix. * fix: derive thread identifier for replies + dedicated reaction constructor Replies via `selectedMessageGuid` previously sent as standalone messages on macOS 26 because the receiver also needs the `threadIdentifier` string to render the in-line reply UI; the associated_message_guid + type=100 combination alone isn't sufficient on Tahoe. Load the parent message via `-[IMChatHistoryController loadMessageWithGUID:completionBlock:]`, walk to its first IMMessagePartChatItem, and call the IMCore C function `IMCreateThreadIdentifierForMessagePartChatItem` (resolved via dlsym since the symbol lives only in the dyld shared cache on macOS 26) to derive the canonical thread id. Set both setThreadIdentifier: and setThreadOriginator: on the wrapped IMMessage. Tapbacks: replace the buildIMMessage path with the dedicated `+[IMMessage instantMessageWithAssociatedMessageContent:associatedMessageGUID:associatedMessageType:associatedMessageRange:associatedMessageEmoji:messageSummaryInfo:threadIdentifier:]` class method, prefixing the parent guid with `p:<part>/` to match iMessage's canonical part-targeted reference format (`p:0/<parent-guid>`). Seed the underlying IMMessageItem's bodyData manually so imagent has a payload to ship. Smoke-tested on macOS 26.4.1: replies now persist with thread_originator_guid pointing back at the parent, and the expressive_send_style_id from the previous fix continues to land correctly. Tapback persistence in chat.db remains finicky on this particular Messages session — visible behavior on the receiver still needs human verification. * fix(react): route reactions through legacy initIMMessageWithSender:…:associatedMessageGUID: path The IMMessageItem-first path doesn't preserve associated-message fields (the 9-arg item initializer doesn't accept them, and post-init setters don't survive the IMMessage wrap on macOS 26 — verified by tapbacks dispatching cleanly but not landing in chat.db). Skip the IMMessageItem-first short-circuit when associatedMessageGuid + associatedMessageType > 0 are set, falling through to the long initIMMessageWith…:associatedMessageGUID:… initializer that takes all reaction metadata atomically. Mirror what upstream's reaction path was doing at chat.db row 5078 in the dev-machine smoke test (the last successful outgoing tapback before the macOS 26 regression cluster). Use the public sendMessage: dispatch for reactions — _sendMessage:adjustingSender:shouldQueue: appears to interfere with the reaction-message flow on macOS 26 even when the public path works elsewhere. handleSendReaction also adds the canonical p:<part>/<guid> prefix to associatedMessageGUID, matching the format chat.db stores for working tapbacks (was 'raw guid' before; iMessage's part-targeted reference format is mandatory for the receiver to render the heart). Smoke-tested on macOS 26.4.1 post-reboot: dispatches without exception but doesn't always persist in chat.db on this Messages session. Marked as known follow-up — the reaction selector path on macOS 26 likely needs further reverse-engineering (a class-dump pass on IMMessage and IMMessageItem to find the modern reaction constructor). * fix: BlueBubblesHelper-verified macOS 26 selectors + reaction body After a fine-tooth audit against BlueBubblesHelper's macOS-11+ tree, several deltas in our IMCore use were causing macOS 26 regressions: 1. Reaction init signature was wrong on macOS 26. Use IMMessage's 13-arg `initWithSender:time:text:messageSubject:fileTransferGUIDs🎏error:guid:subject:associatedMessageGUID:associatedMessageType:associatedMessageRange:messageSummaryInfo:` (the BB-verified macOS 26 selector — no balloonBundleID/payloadData/ expressiveSendStyleID args). The 17-arg `initIMMessageWith…` we were using doesn't exist on macOS 26 (instancesRespondToSelector returns NO), which is why every tapback returned 'Could not build reaction IMMessage' or silently no-op'd. 2. Reaction body was empty — imagent silently dropped reactions. Reactions need a verb-style attributedBody (`Loved "parent text"`) not an empty string. Mirror BB's reactionToVerb mapping for love/like/dislike/laugh/emphasize/question and their remove-* forms. Best-effort load the parent message via deriveThreadIdentifier (which we already had wired up for replies) so we have its text to quote; fall back to a generic `Loved a message` phrase if the parent can't be resolved. 3. Reaction associatedMessageGUID needs the `p:<part>/<guid>` prefix. The receiver pipeline ignores reaction messages whose associatedMessageGUID is a bare guid (no part prefix). chat.db rows for working tapbacks (e.g. row 5078 in the dev-machine smoke test) show `p:0/<parent-guid>`. 4. Send/attachment flags were wrong — 0x5 instead of 0x100005. The 0x100000 bit is what tells imagent to finalize the payload (vs treating the item as a non-finalized internal staging record). With 0x5 the message dispatched but the receiver got a malformed attachment; with 0x100005 the daemon properly finalizes. BB-verified: isAudioMessage ? 0x300005 : (subject ? 0x10000d : 0x100005). 5. Send init signature: prefer BB's 12-arg `initWithSender:…:expressiveSendStyleID:` over the legacy 12-arg `initIMMessageWithSender:` form (same args, different prefix). Fall through to the legacy form if the macOS 26 selector isn't available. 6. Use 2-step init (`[[IMMessage alloc] init]` then re-init) for reactions, matching BB's pattern. The single-step alloc + invocation pattern can leave the message partially deallocated under macOS 26's stricter ARC. Smoke-tested on macOS 26.4.1: tapbacks now persist in chat.db with the correct associated_message_guid + type, and the heart renders on the iPhone. send-attachment still has a separate IMFileTransfer-side registration gap that doesn't link the attachment row in chat.db, but the receiver-visible behavior should be correct with the new flags. * fix(attachment): tighten ARC retention + skip IMMessageItem-first Per the BB-helper audit: 1. `_persistentPathForTransfer:…` returns its NSString via NSInvocation.getReturnValue, which puts the result into an __unsafe_unretained slot. Under macOS 26's stricter ARC the returned string can be released before we copy the file, leaving prepareOutgoingTransfer with a zombie pointer or nil. Take a strong reference immediately after getReturnValue. 2. Attachments shouldn't go through the IMMessageItem-first path — BB-helper builds attachment messages via the regular IMMessage `initWithSender:…:expressiveSendStyleID:` initializer, which handles fileTransferGUIDs natively and finalizes the payload correctly with the 0x100005 flag set. Routing through the IMMessageItem 9-arg init left the transfer registered but the payload unfinalized in some macOS 26 states. Smoke-tested on macOS 26.4.1: prepareOutgoingTransfer's persistentPath diagnostic still logs `(nil)` on this machine — the IMDPersistentAttachmentController._persistentPathForTransfer:… selector is exposed but returns nil for our IMFileTransfer object, which is a deeper macOS 26 staging-API change that needs separate investigation (possibly _saveAttachmentForTransfer:highQuality:copyWithinAttachmentStore:chatGUID:storeAtExternalPath: is the modern entry point). Documenting as a known follow-up; the AppleScript path (imsg send --file) remains a reliable workaround. * fix: BlueBubblesHelper-aligned selectors for group ops, mark-unread, notify-anyways, reaction summary Six independent functional bugs the BB-helper audit surfaced; all single-selector fixes that bring our IMCore handling back in line with the canonical BB MacOS-11+ tree. 1. Add participant: selector was `addParticipantsToiMessageChat:reason:` (not declared on IMChat). Use BB-verified `inviteParticipantsToiMessageChat:reason:`. Group join was error-failing. 2. Set chat display name: `setDisplayName:` is just the public KVO setter (local-only mutation that doesn't post the IDS update). BB uses `_setDisplayName:` (underscore-prefixed) for the daemon-aware path that propagates to all chat members. Renames were sender-only before. Also fixed the second call site in handleCreateChat. 3. Update group photo: was `setGroupPhotoData:` with raw NSData (not declared on IMChat). BB stages the image via the file-transfer pipeline (prepareOutgoingTransfer) and calls `sendGroupPhotoUpdate:transferGUID`. Group photo was no-op'ing. 4. Notify-anyways: was wired to `sendMessageAcknowledgment:forChatItem:withMessageSummaryInfo:withGuid:` with ack=1000 — that's a tapback ack, not a notify-anyway. BB-verified selector is `markChatItemAsNotifyRecipient:` (single arg). notify-anyways wasn't actually bypassing focus mode before. 5. Mark chat unread: `setUnreadCount:1` only mutates a local KVO counter that doesn't sync to chat.db or propagate. BB uses `markLastMessageAsUnread` for the daemon-aware path. 6. Edit / unsend / delete-message lookup: `findMessageItem` walked `chat.chatItems` synchronously, which only covers the live IMChat window. Edit-after-scroll-back failed with 'Message not found'. Try `IMChatHistoryController.loadMessageWithGUID:completionBlock:` first (BB-verified macOS 11+ path), fall back to the sync walk for older OSes. Reuses the loadParentFirstChatItem helper. 7. Reaction `messageSummaryInfo` shape: `amc` was the parent guid as a string. BB sets `amc: @1` (NSNumber count). Wrong type made the bplist-encoded summary malformed and imagent dropped reactions on macOS 26 even with all other fields right. `ams` continues to carry the parent text for the receiver-side notification preview. 8. Reaction `associatedMessageRange`: was hardcoded `{0, 1}`. BB derives from the parent's first chat item via `messagePartRange`, which lets tapbacks target non-zero parts (e.g. the second image of a multipart photo grid). Loaded via the new loadParentFirstChatItem helper. 9. Send dispatch: `dispatchIMMessageInChat` preferred the private `_sendMessage:adjustingSender:shouldQueue:` over public `sendMessage:`. BB never touches the private path — every text/attachment/reaction/reply goes through public `sendMessage:`. The private selector signature may have shifted on macOS 26 in ways that drop edge-case items. Simplified dispatchIMMessageInChat to just call `[chat sendMessage:]`. Smoke-tested on macOS 26.4.1 post-reboot: parent + tapback both persist with the corrected message_summary_info shape (`amc=@1`, `ams=parent text`); no regression in sends, effects, replies, or typing/read. * fix(rpc): restore chat/group lifecycle handlers cut during PR #100 merge PR #100 was squash-merged with 8 RPC handler functions silently dropped from the dispatch surface plus the corresponding `supportedMethods` capability list. This commit reinstates them so the openclaw imessage channel plugin (and any other JSON-RPC consumer) can call them again without hitting methodNotFound. Restored RPC methods: - chats.create — create a 1:1 or group chat - chats.delete — delete a chat from Messages.app - chats.markUnread — mark last message in a chat as unread - group.rename — set a group chat's display name - group.setIcon — set or clear a group chat photo - group.addParticipant - group.removeParticipant - group.leave — leave a group chat The handler functions all dispatch into v2 bridge actions the dylib already implements (createChat, deleteChat, markChatUnread, leaveChat, etc.), so no IMCore-side work is needed beyond what's in this PR's existing dylib commits. Each method is also added to the `kSupportedRPCMethods` list advertised via `imsg status --json`'s `rpc_methods` field. The handler implementations come from the original PR #100 branch (`omarshahine:feat/private-api-port` at 638efbd), which had them in a dedicated `RPCServer+ChatHandlers.swift` extension. Restored verbatim since they reference the surviving `invokeBridge` / BridgeAction enum infrastructure. Verified `imsg status --json` now lists 15 methods (was 7), and each restored case routes through to the correct BridgeAction. * docs: note macOS 26 bridge fixes --------- Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com> Co-authored-by: Peter Steinberger <steipete@gmail.com> |
||
|
Omar Shahine
|
c56c24d488
|
feat: port BlueBubbles private-API bridge
Port the BlueBubbles-inspired IMCore bridge surface into imsg with rich sends, message mutation, chat management, account/nickname introspection, live bridge events, and v2 UUID-keyed IPC. Fixes #60. Co-authored-by: Omar Shahine <omarshahine@users.noreply.github.com> |
||
|
Peter Steinberger
|
f8f0c5d712
|
fix: normalize typing chat lookup | ||
|
Peter Steinberger
|
bf2d02e5e7
|
feat: add advanced message controls |