We first verify whether the email provider implements WKS. If yes, we will publish the key on WKS, othewise we fall back to PKS publishing once the key is available. If the key is already available during the setup phase, it will be published as part of it. If the key is not ready by then (because key generation takes too long), it will be published once the generation finishes.
Details
Details
- Reviewers
aheinecke - Maniphest Tasks
- T3126: Add support for publishing keys in web key directories
- Commits
- R207:b1b2d13302f9: Implement key publishing with WKS and PKS
Tested PKS publishing with local SKS. We successfully send the email, but so far I did not get any reply from the test.gnupg.org server, I'm not sure if it's because of us or if there's a problem on the server, but the email looks OK to me.
Diff Detail
Diff Detail
- Repository
- R207 KMail Account Wizard
- Lint
Lint Skipped - Unit
Unit Tests Skipped
| src/cryptopage.cpp | ||
|---|---|---|
| 75 | is 0 really an invalid id? maybe -1 instead | |
| src/cryptopage.cpp | ||
|---|---|---|
| 75 | 0 triggers fallback code for default transport (see MailTransport::TransportManager::transportById()) | |
Comment Actions
Apart from the crash I posted in IRC this looks good to me.
I would like improve it some more to do the publishing check before the checkbox is shown so that we can show different messages or offer to publish the key on the normal keyservers but as a first version I think it would be fine to commit this.
I've had some trouble testing this though. Because my test server rejects invalid sender's even if I configure username and password differently from the identity I want to send I also have to configure a custom sender for the identity.
But if I do this after Account Setup (And I can send mails from testuserX@test.gnupg.org ) and then try to send the Key Submission Request KMail just prints out:
14:40:10.425 org.kde.pim.messagecomposer: MessageComposer::AkonadiSender::doSendQueued Sending queued message with custom transport: -1
The messages are not sent but I don't get an error indication either. But I guess this is an unrelated problem.
Exporting the Mails and manually sending them results in the server sending a confirmation request.
I've urgently requested the setup of a Web Key Service on our testkolab.intevation.de server so that we can better test / demo this.
Looking at the mails in the outbox made me realize that they are only encrypted to the WKS Server Key and not also to the users key. I've opened an issue for GnuPG for this: https://bugs.gnupg.org/gnupg/issue2825
Comment Actions
Do you mean something like automatically switching to publishing on PKS instead of WKD when it's not available?
| src/dialog.cpp | ||
|---|---|---|
| 65 | qCDebug(...) | |
| src/dialog.cpp | ||
|---|---|---|
| 65 | Eh, forgot to remove that one. I was debugging a problem with my gpg setup. Removed locally. | |
Comment Actions
Looks like a good first version. Have not tested it yet because I'm missing the required kmailtransport version (where I guess you added a feature for this).
We can still improve it after feedback from björn or testers at intevation.
Do you want to wait commiting this until D3140 is in?
Comment Actions
Ooops, pushed the KMailTransport change now, so you should be able to build this. You can also update kdepim-runtime, so that the mail dispatcher honors the settings (I added a flag that the wizard sets to the outgoing email to prevent the Dispatcher Agent from showing the "Email successfully sent" notification after sending the key in order to not confuse users by unsolicited "Email sent" popups).
I think we should wait for D3140, because without it there's no way how to confirm the publishing request (without piping the email manually to gpg on command line) - once the whole solution is tested I will land both patches to make sure we make it before the freeze on Nov 10th, then we can polish/clean up the wizard and the formatters as much as we want.
| src/key.cpp | ||
|---|---|---|
| 243 | Getting QOverload was not declared in this scope because I'm still on Qt 5.6 :-) | |
| src/key.cpp | ||
|---|---|---|
| 243 | Sorry, forgot it's 5.7+ API. | |
Comment Actions
I think you can commit this (with a fix for the error state) and we improve incrementally.
Some improvements I see:
- You can not open a second kmail-account-wizard while the key generation still runs.
- An existing key is not preselected.
- Generate Key immediately pops up the passphrase entry / starts keygen this is too early (should happen on next).
- The problem is that you can create multiple keys if you unselect generate key and select it again.
- I don't think the pop up for the passphrase is the best solution. I think dynamically adding the passphrase entry widget to the wizard page when generate-key is selected. Otherwise we could have used the existing pinentries. Or we have the widget there and only enable / disable this.
| src/cryptopage.cpp | ||
|---|---|---|
| 234 ↗ | (On Diff #7800) | I encountered this error because gpg-wks-client --create crashes in current gpg master ( https://bugs.gnupg.org/gnupg/issue2828 ). The condition caused kmail-account-wizard not to terminate. The error probably needs to be connected to some finished / delete later slot? |
| src/cryptopage.cpp | ||
|---|---|---|
| 91 ↗ | (On Diff #7800) | Ah, It's DefaultKeyGenerationJob::start(const QString &email, const QString &name); This is likely the reason why we don't get responses for these keys because they are dropped on the server. Because they don't contain a valid user ID. gpg-wks-client should have errored out instead of sending a public key without userids. I'll open a gnupg issue for that. Didn't notice it on the commandline either but you can see that keys created by them have email <Name> when listing them on the command line, |