New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signing arbitrary keys in GUI #79

Open
anarcat opened this Issue Jan 21, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@anarcat
Copy link

anarcat commented Jan 21, 2019

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

This comment has been minimized.

Copy link
Member

muelli commented Jan 21, 2019

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

This comment has been minimized.

Copy link
Author

anarcat commented Jan 21, 2019

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

This comment has been minimized.

Copy link
Member

muelli commented Jan 21, 2019

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

This comment has been minimized.

Copy link
Author

anarcat commented Jan 21, 2019

@muelli

This comment has been minimized.

Copy link
Member

muelli commented Feb 14, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment