[kdeconnect] [Bug 520110] KDE Connect Android rejects explicit tailnet peers delivered as loopback by userspace VPNs

2026-05-13 Thread Mice
https://bugs.kde.org/show_bug.cgi?id=520110

--- Comment #5 from Mice  ---
I submitted the proper KDE Invent merge request here:

https://invent.kde.org/network/kdeconnect-android/-/merge_requests/650

The earlier GitHub PR was only against the mirror and was auto-closed, so the
Invent MR above is the canonical review link.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 520110] KDE Connect Android rejects explicit tailnet peers delivered as loopback by userspace VPNs

2026-05-13 Thread Bug Janitor Service
https://bugs.kde.org/show_bug.cgi?id=520110

Bug Janitor Service  changed:

   What|Removed |Added

 Status|REPORTED|ASSIGNED
 Ever confirmed|0   |1

--- Comment #4 from Bug Janitor Service  ---
A possibly relevant merge request was started @
https://invent.kde.org/network/kdeconnect-android/-/merge_requests/650

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 520110] KDE Connect Android rejects explicit tailnet peers delivered as loopback by userspace VPNs

2026-05-13 Thread Mice
https://bugs.kde.org/show_bug.cgi?id=520110

--- Comment #3 from Mice  ---
I also tried opening this as a GitHub pull request because the mirror allowed
PR creation:

https://github.com/KDE/kdeconnect-android/pull/34

It was automatically closed because KDE's GitHub repository is only a mirror
and does not accept pull requests there. The cleaned-up patch is still
available on my fork for review/reference:

https://github.com/cagedbird043/kdeconnect-android/commit/7cf96f7c8a99dd1794d0a8d4d0b101316212615f

I'll submit it through KDE Invent if/when I have the required Invent
fork/merge-request setup.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 520110] KDE Connect Android rejects explicit tailnet peers delivered as loopback by userspace VPNs

2026-05-13 Thread Mice
https://bugs.kde.org/show_bug.cgi?id=520110

--- Comment #2 from Mice  ---
I prepared a minimal upstream-style patch and opened a GitHub pull request
here:

https://github.com/KDE/kdeconnect-android/pull/34

The patch intentionally keeps the trust expansion narrow: loopback is accepted
as a custom-device proxy path only when the user has configured custom devices.
It does not make KDE Connect trust loopback globally.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 520110] KDE Connect Android rejects explicit tailnet peers delivered as loopback by userspace VPNs

2026-05-13 Thread Mice
https://bugs.kde.org/show_bug.cgi?id=520110

--- Comment #1 from Mice  ---
Additional local validation details:

I confirmed the failure was not caused by missing tailnet reachability. From
the desktop side, packets reached the Android device's tailnet IP and port
1716. From the Android side, the same connection was visible to the app process
as loopback. Once I changed the LAN backend to treat loopback as an
explicit-proxy path only when custom devices are configured, pairing completed
successfully and the desktop reported the Android device as paired and
reachable via the tailnet IP.

The reason I think this belongs in KDE Connect rather than only in the
VPN/tailnet implementation is that KDE Connect already has an explicit peer
concept ("Add devices by IP"). In userspace VPN/tailnet environments, the
transport may erase the original peer address before the Java socket layer can
compare it with the configured address. So the trust decision may need to
preserve the user's explicit opt-in even when the app-visible source is
loopback.

A possible safer design than simply accepting loopback would be:

- keep rejecting loopback by default;
- allow it only if the custom device list is non-empty, or behind a more
explicit setting;
- still require normal KDE Connect identity/TLS handling after the initial
address gate;
- optionally log that the connection was accepted as a userspace VPN/proxy
loopback path.

I have a local fork with this behavior and can turn it into a merge request if
this approach is acceptable.

-- 
You are receiving this mail because:
You are watching all bug changes.