GSConnect device ID format needs to be updated

[ferdnyc]

Yesterday Albert also updated the protocol docs to make it required that devices have UUID-format device IDs, the definition is now:

• deviceId: String 🔒

  pattern: /^[a-zA-Z0-9_]{32,38}$/

  A unique ID for the device. Must be between 32 and 38 characters and made of only alphanumerical characters and underscores. A valid device ID can be generated from a random UUIDv4 string by removing the hyphens (-) or replacing them with underscores (_), such as 740bd4b9_b418_4ee4_97d6_caf1da8151be.

GSConnect IDs are currently real UUIDs (with hyphens instead of underscores).

Looks like we need code to generate new-format IDs, then trigger that code for all devices not using the correct format, regenerate their certificates, and tell the user they'll need to re-pair all of their devices.

Originally posted by @ferdnyc in #1905 (comment)

[daniellandau]

Could we ask Albert to allow real UUIDs too? Sounds from the quote on the comment in #1905 that maybe he isn't aware that we use real UUIDs?

[ferdnyc]

Suppose it can't hurt to ask. I've opened https://bugs.kde.org/show_bug.cgi?id=498778

[andyholmes]

Sounds from the quote on the comment in #1905 that maybe he isn't aware that we use real UUIDs?

Should be aware, I think. This was discussed in kdeconnect-meta!9, I think some other discussion might have happened on Matrix, but I don't recall :/

[ferdnyc]

Hmm. Having looked at that kdeconnect-meta issue, now I'm thinking we might want to withdraw our request.

One of the reasons Albert gives there for preferring the underscored form of UUIDs for device IDs is that they're "D-Bus Safe" — the D-Bus spec says, regarding valid object paths, that:

The following rules define a valid object path. Implementations must not send or accept messages with invalid object paths.

• The path may be of any length.
• The path must begin with an ASCII '/' (integer 47) character, and must consist of elements separated by slash characters.
• Each element must only contain the ASCII characters "[A-Z][a-z][0-9]_"
• No element may be the empty string.
• Multiple '/' characters cannot occur in sequence.
• A trailing '/' character is not allowed unless the path is the root path (a single '/' character).

So, where GSConnect creates the /org/gnome/Shell/Extensions/GSConnect/Device/<device_id> object path for each paired device, if that device ID is one of ours, then that's an invalid object path. I wonder if that's the root cause of at least some of the various GSConnect-to-GSConnect pairing/communication issues people have reported over the years?

[daniellandau]

I'm still a little out if the loop. Will this mean that any non-updated gsconnect versions will stop working with kdeconnect android in the future? Meaning we would probably want to backport releases for old shell versions.

[ferdnyc]

@daniellandau

I'm still a little out if the loop. Will this mean that any non-updated gsconnect versions will stop working with kdeconnect android in the future? Meaning we would probably want to backport releases for old shell versions.

As things currently stand, that's not clear... but at some point, my assumption is that the answer would be "yes". The reason Albert gave for wanting to tighten up the device ID definition is so that they "can" start validating IDs, and he explicitly removed this sentence from the definition:

Note that older clients may report a device ID in a different format, and a compliant implementation must accept and respond with the device's reported ID.

So, if not today or tomorrow, then at some point in the future, it's safe to assume that device IDs that don't match the defined format may not be accepted by all other implementations. (Tho I would imagine their desktop client, rather than the Android app, would be the first to start rejecting non-compliant device IDs.)

[ferdnyc]

I'mma close that KDE bug report, because I think the conclusion is that it would be a bad idea for us to stick with our current device IDs regardless (due to the D-Bus object path issue).