Repository navigation
Remote lock, device filters, comment policy pass - #54
Merged
Merged
Conversation
… locally `kcd lock <id>` promised a remote lock and ran a local one: Lock(dev) ignored dev entirely and executed loginctl lock-session, so the operator's workstation locked while the phone stayed awake. Lock/Unlock now send kdeconnect.lock.request with setLocked true/false over dev.Send; the phone-to-us direction in Handle (local loginctl) is unchanged and still correct. SetLocked lost its omitempty so unlock carries an explicit false rather than an absent field a strict peer could read as malformed. feat(cli): split device listing into --connected and --paired --connected now means paired and currently connected. --paired keeps the previous listing (all paired, offline included) under an honest name, so nothing scripted against the old output disappears. The waybar snippet moves to --connected and guards the empty list instead of pinging null. docs(agents): incoming mousepad specialKey is handled per spec, not unhandled; kcd never sends mousepad packets.
A peer's bare state report (kdeconnect.lock with isLocked) fell into the unlock branch, so a status update from another device unlocked the local session. Only an explicit kdeconnect.lock.request may now act; state packets return without touching anything. Tests use a fake loginctl on PATH (record-and-exit) so Handle's exec path is observable without locking the operator's session; async execution means asserting the call set, not the order. Docs: the Android app ships no lock plugin, so it ignores the request. Plasma and kcd peers honour it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No release — merge only.
Remote lock (was: locked the wrong machine)
kcd lock <id>promised a remote lock and ran localloginctl:Lock(dev)ignoreddeventirely.Lock/Unlocknow sendkdeconnect.lock.requestwith explicitsetLockedoverdev.Send; the phone-to-us direction inHandle(localloginctl) is unchanged. A follow-up gatesHandleon the request type so a peer's bare state report can't unlock us. Verified: unit tests with a fakeloginctl(packet type, explicit false, no action on state packets). Live phone check: Android ships no lock plugin and ignores the request (documented in CLI.md); Plasma and kcd peers honour it.Device filters
--connectednow means paired and online; new--pairedpreserves the old listing (all paired, offline included) under an honest name. Waybar snippet moves to--connectedwith an empty-list guard.Comment pass
AGENTS.md policy tightened to the 2-line rule (security/protocol rationale may run long but leads with the reason). 342 blocks over the limit compressed to 16 across 118 files, reasons kept, narration cut. No behavior change.
All gates green locally: vet, golangci-lint 0 issues, go test -race ./..., integration, static build, hk, goreleaser check.