Show SHA256 fingerprints

[strugee]

I changed the monkeypatched function name to improve code clarity (being unfamiliar with the codebase, it was unclear to me at the call sites what kind of fingerprint the function returned) and also to avoid clashing with future GLib APIs.

Ref #1091

[andyholmes]

Thanks for the patch!

Unfortunately this doesn't quite solve the problem. It probably wasn't clear in the issue I opened, because the method used here is a bit odd. What KDE Connect does now is to:

1. Take the DER format of each certificate
2. Compare them byte-by-byte to find the largest
3. Concatenate them into a single bytearray, largest first
4. generate a SHA256 hash of the combined bytearray

The Qt/C++ code is probably clearest here (comments are mine):

QByteArray Device::verificationKey() const
{
    // Get the DER binary format of the local and remote TLS certificates
    auto a = KdeConnectConfig::instance().certificate().publicKey().toDer();
    auto b = certificate().publicKey().toDer();

    // Figure out which is  "logically" larger and ensure it is first (most significant)
    if (a < b) {
        std::swap(a, b);
    }

    // Add them sequentially and produces the SHA256 hash
    QCryptographicHash hash(QCryptographicHash::Sha256);
    hash.addData(a);
    hash.addData(b);
    return hash.result().toHex();
}

The reason it does this is so that both devices show precisely the same verification key. I'm not sure there's an elegant way to do this in GJS, given the current restrictions we work with.

Probably it will require getting the PEM of each certificate, using openssl to dump the DER format somewhere, opening them with GFile, then using Uint8Array to compare the size and combine them, before finally passing them to GLib.Checksum. At least that's what occurs to me off the top of my head.

[strugee]

Ahhh, funky. Ok, makes sense.

What doesn't make sense though is my KDE Connect Android app still showing two distinct fingerprints. Maybe F-Droid is out of date? 1.17.0 is what I'm running. I'll look into this more in the morning 👍

[strugee]

I have terrible time management and looked into this instead of going to sleep because it didn't take very long. The SHA256 fingerprints I was seeing in the Android app were in the "Encryption Info" screen - I completely ignored the verification code which is what's computed using that algorithm 😅

IIUC this change still needs to be made anyway, so I amended the commit message so it doesn't close the linked issue. The verification code will have to be implemented separately.

[andyholmes]

Ah right, I had forgotten about that 😝. Okay I will merge this one, thanks for the PR!