Calculate a verification key that matches KDE/Android

[daniellandau]

This is based on earlier work by @strugee in #1148.

When the other party initiates the request the verification key is shown as a notification as before, but it doesn't seem to be shown anywhere. The previous pull request could be maybe rebased on top of this, as I think it had some UI for that?

I think the GLib checksum should "just work" with Javascript, and when I took away the call to .free both errors "code should not be reached" and the segfault that (according to gdb) happened inside g_checksum_copy went away.

There's a bug on the KDE Connect Android side that has been fixed in master (https://invent.kde.org/network/kdeconnect-android/-/commit/8f49ff57ab43961bea65cddd35b250f7f5301567), but not yet released to F-Droid which leaves out the last two characters from the verification key on the Android side. I think we should still show the full thing as it has been fixed already even if not released yet.

I developed this against Gnome 42, so for testing can definitely be cherry picked against that.

[andyholmes]

LGTM!

[ferdnyc]

Hmm, I guess I may have closed #1148 prematurely, as I see now that there was a lot more there than is included here. Is this just a cherry-pick of one feature from #1148, then, @daniellandau, and should I re-open that PR for the rest of its changes? (In which case, I suspect working through the conflict-resolution necessary to get it caught up with the current HEAD will require a machete and a rosary.)

[ferdnyc]

Ah, I see you already addressed that:

The previous pull request could be maybe rebased on top of this, as I think it had some UI for that?

I'll reopen #1148, and as penance, whip out my best Indiana Jones impression as I attempt the conflict resolution.

[ferdnyc]

@daniellandau

I think the GLib checksum should "just work" with Javascript, and when I took away the call to .free both errors "code should not be reached" and the segfault that (according to gdb) happened inside g_checksum_copy went away.

I guess the question, now, is: With the free() removed, does it leak memory?

(Even if it does, it'll probably be hard to detect. Let's assume the worst case, which is that the entire checksum object is leaked. That'll be a matter of, what, a few tens of kilobytes, pessimistically -- perhaps as much as some tiny fraction of a megabyte -- once for each pairing request that's processed... do I have that right?

Forget normal use, I bet you'd have to be actively trying, and pretty damn hard, before you managed enough pair attempts to leak noticeable amounts of memory. ...Even if it leaks, which it probably/hopefully doesn't.)

[daniellandau]

$ ag g_checksum_free
[ ... ]
gobject/gboxed.c
175:G_DEFINE_BOXED_TYPE (GChecksum, g_checksum, g_checksum_copy, g_checksum_free)

I'm really not an expert on GLib/GObject etc, but to me that would seem like you are "supposed" to let the garbage collector handle it.

[andyholmes]

Yep, that's right. GBoxed types are pretty much just C struct's, defined with copy and free functions.

So the GJS can handle these, but a few of them show up in our API docs so sometimes people use them 🤷