signing arbitrary keys in GUI

[anarcat]

since I'm having trouble with the commandline (#76, #77), i'm trying out the GUI, but I'm not getting much better results. I already have the key material and the fingerprint of the key: it's signed by a previous key from the same user and I want to update my certification. So I don't need to securely exchange fingerprints, and certainly not interactively.

There should be an option to just input a fingerprint in the GUI, at which point the normal process would be followed.

Thanks! :)

[muelli]

the app hasn't been built for that usecase, but if you are really determined you can simulate the other peer by spawning a compatible server with something like python -m keysign.avahioffer $yourid. You can then use the GUI with the fingerprint as you describe.

Do you think we should make this mechanism more discoverable? How much value does this add over the standalone sign-key tool?

[anarcat]

documenting the avahi discovery mechanism would certainly be important, but I'm not sure it brings much to the table here.

the GUI will certainly be more accessible to users than the commandline sign-key tool. besides, the sign-key tool doesn't support specifying user IDs or fingerprints either, so it's not a great user experience there.

i understand if it's not part of your use case, feel free to close this issue, in that case. but I still think it would be a useful feature, and it's certainly one that has been asked in monkeyscan (the monkeysign GUI) in the past, so other users might certainly find it useful here as well... :)

the point is that our shiny qrcode, avahi, wormhole tools are great, but "legacy" methods still exist and are very useful when the other mechanisms fail...

[muelli]

Yeah, dealing with legacy is a bit more inconvenient and involves one more command to be run. In the GUI case through that custom server which one has to be spawned through that command I've mentioned and in the CLI case through exporting the key to be signed into a separate file, i.e. gpg --export $yourid > /tmp/foo, before running the sign-key tool on it. We could extend that tool relatively easily to accept any identifier that GnuPG does. I'm having a mild aversion, though. The app's primary focus is people who have never met and quickly want to exchange their keys. A problem I'd argue is common enough to warrant a dedicated tool. I'd even say that if you've managed to get an OpenPGP certificate into your keyring then you've made it quite far already. If you know how to do that, then you're probably not afraid of using something like caff. Although making this type of arguments is tricky and quickly leads to false conclusions.

But regardless, do you think a --uid switch could make things a bit easier? Then you could call the sign-tool with --uid fingerprint or so to sign a key living in your GnuPG keyring.

[anarcat]

On 2019-01-21 23:20:05, muelli wrote: I'd even say that if you've managed to get an OpenPGP certificate into your keyring then you've made it quite far already. If you know how to do that, then you're probably not afraid of using something like caff.

Well, the whole point of monkeysign was to stop using caff because it's too hard to use, even for me. So I was hoping gnome-keysign would also address those use cases...

But regardless, do you think a `--uid` switch could make things a bit easier? Then you could call the sign-tool with `--uid fingerprint` or so to sign a key living in your GnuPG keyring.

Sure, such an option would be very welcome. If it takes a fingerprint, I would use `--fingerprint`, however. :) And yes, it's better to use a full fingerprint than allow "whatever GnuPG can accept" because that is way too wide...

[muelli]

And yes, it's better to use a full fingerprint than allow "whatever GnuPG can accept" because that is way too wide...

yeah, I don't really want to get into that territory.
I'm leaning towards making the user provide the key that they want to have signed into a file and run the sign-tool on that file rather than us dealing with GnuPG key identifiers, because we are actually thinking of loosing ties to GnuPG rather than tightening them.
I'm open for taking a small and unintrusive patch, though.