| *** radish_ is now known as radish | 02:19 | |
| *** bugzy_ is now known as bugzy | 04:09 | |
| *** jvd__ is now known as jvd_ | 05:13 | |
| *** mal__ is now known as mal | 05:31 | |
| dcaliste | Hello chriadam and rainemak. How are you? | 07:02 |
|---|---|---|
| rainemak | dcaliste, hi | 07:02 |
| rainemak | dcaliste, just got back from vacation and hands are full :) | 07:03 |
| dcaliste | I hope you had pleasant time. Last week, we discuss a bit with Chris about the settings for PGP signatures. | 07:04 |
| chriadam | hi | 07:05 |
| dcaliste | I've added account setting in QMF to add automatic signature for a given account, and specify the key and the type (PGP or S/MIME) for this account. | 07:05 |
| dcaliste | I would like to add UI for these settings, if you guys agree. | 07:06 |
| dcaliste | Hello Chris. | 07:06 |
| chriadam | seems reasonable. the UI for that would be in jolla-settings-accounts -> rainemak is dcaliste able to get access to that? | 07:06 |
| rainemak | will add access rights later this afternoon | 07:07 |
| dcaliste | I you want to comment or give look to where it is now : https://bitbucket.org/jolla/ui-jolla-email/issues/2/design-discussion-on-signature-process-and | 07:07 |
| dcaliste | Thank you rainemak. | 07:08 |
| chriadam | will need MartinS to take a look at that also, when he has time | 07:09 |
| chriadam | certainly looks like great progress to me! | 07:09 |
| chriadam | is that "Request read receipt" new also or just the "Use electronic signature" toggle? | 07:09 |
| chriadam | I assume just the signature one is new | 07:10 |
| chriadam | in which case, it definitely "fits in" with the existing design | 07:10 |
| dcaliste | The request read receipt is coming from 2.2.1 from OMP I guess. | 07:10 |
| dcaliste | I've added a signature toggle following the same spirit indeed. | 07:10 |
| chriadam | nice | 07:11 |
| dcaliste | About what we discuss on signature checking, you can see some advancing at https://bitbucket.org/jolla/ui-jolla-email/issues/1/design-discussion-on-pgp-public-key | 07:12 |
| dcaliste | I've added your suggestion to download missing on tap directly | 07:12 |
| dcaliste | Polling key servers from a list in a dconf setting. | 07:12 |
| dcaliste | About UI, there would be a need of a page with the following: | 07:13 |
| dcaliste | - a checkbox to save passphrase or not; | 07:13 |
| dcaliste | - a list to add or remove key servers; | 07:14 |
| dcaliste | - the list of current key for which we have a cached passphrase, so one can remove if needed. | 07:14 |
| dcaliste | All these settings are reachable via dconf and secret-tool cli for the ;o;ent. | 07:14 |
| dcaliste | moment. | 07:15 |
| dcaliste | I don't know if it's relevant to make all of these in a UI though. You can keep it in mind when the secret key setting page will be redesigned or modified. | 07:16 |
| chriadam | I guess we need a UI for all such settings eventually | 07:16 |
| chriadam | does jolla-email currently store config settings in dconf? | 07:16 |
| dcaliste | I guess some cond in dconf, yes; but the main part is stored per account with libaccount-qt5 | 07:17 |
| dcaliste | s/some conf/ | 07:17 |
| chriadam | right | 07:17 |
| dcaliste | chriadam, do you want to discuss some S/MIME aspects ? | 07:18 |
| chriadam | dcaliste: unfortunately I didn't get a chance to look into that yet, and won't until our 2.2.1 is out the door I guess | 07:18 |
| chriadam | but if you have any questions / comments / discussion points I'd be very interested to hear those | 07:19 |
| dcaliste | Not necessary. As said, checking signature is working as far as I've tested. For signing process, I need to investigate. | 07:19 |
| dcaliste | And transfer my current certificate on my phone to actually try. | 07:20 |
| dcaliste | I guess some question about certificates may come in the coming weeks. | 07:20 |
| chriadam | certificates are a big topic :-( | 07:23 |
| dcaliste | chriadaam, I have an API question: I've mapped secret collection on PGP UID and then keys and subkeys for this UID as keys for this collection. | 07:23 |
| dcaliste | I seems to work well, except for the import logic. | 07:24 |
| chriadam | it's great that checking signatures is working, that's a huge step in the right direction. and from the UI you showed, it seems quite "natural" so hopefully shouldn't be issues getting that integrated after MartinS takes a look | 07:24 |
| chriadam | dcaliste: import logic, as in ImportKeyRequest? | 07:24 |
| dcaliste | About UI, great. About import yes, I'm explaining. | 07:24 |
| dcaliste | In secret, importStoredKeyRequest, need to put the imported key in an existing collection | 07:25 |
| dcaliste | But in PGP, when importing a key, maybe the collection (i.e. the UID) may not exist yet. | 07:25 |
| dcaliste | For example I'm importing the public key of someone I currently have no key. | 07:26 |
| chriadam | I see the problem | 07:26 |
| dcaliste | What would be the best solution: | 07:26 |
| dcaliste | - add a importStoredKeyWithCollection() that create the collection when importing also. | 07:27 |
| chriadam | ImportCollectionRequest | 07:27 |
| chriadam | perhaps | 07:27 |
| dcaliste | - add a fake collection name that would be a magic keyword. When this collection name is used the collection existence check is not done. | 07:28 |
| chriadam | interesting idea | 07:28 |
| dcaliste | - ImportCollectionRequest() looks great. | 07:28 |
| dcaliste | - or last, ImportKeyRequest(), then CreateCollectionRequest() and StoreKeyRequest(). | 07:28 |
| dcaliste | I mean, let the user do these three requests. | 07:29 |
| chriadam | hrm. does that work? i.e. can you get the "expected collection name" from the ImportKeyRequest output? I guess the gpg plugin could pass the data back as CustomParameters in the returned Key.. | 07:29 |
| dcaliste | The problem with ImportCollectionRequest() is that doing so in GnuPG will also create a key for this collection, which doesn't match with the name and will confuse the metadata database. | 07:30 |
| chriadam | right :-( | 07:30 |
| dcaliste | About the ImportKeyRequest(), yes the collectionName() ((i.e. the UID) is always set in the key identifier. | 07:30 |
| chriadam | we really need signals between plugin + daemon to allow updating metadata db appropriately. | 07:30 |
| chriadam | the problem is that there are issues with Q_SIGNALS in Plugin types, which really raises its ugly head when trying to use multiple inheritance from common (QObject) base (e.g. in CryptoStorage plugin case) | 07:32 |
| dcaliste | Currently, to circumvent the problem, I'm always returning a fake "import" collection when listing collections in secret for GnuPG in addition to the real ones. | 07:32 |
| dcaliste | Then, I can do a ImportStoredKeyRequest() within the "import" collection. | 07:32 |
| dcaliste | It has the drawback that this fake collection is listed in the setting page... | 07:33 |
| chriadam | right :-( | 07:33 |
| dcaliste | And an additional drawback that I cannot import the same key twice (to update it for instance) because the key already exists in the metadata database and the import fails before reaching the plugin code. | 07:34 |
| chriadam | right. the API currently assumes that keys are immutable, which may not have been a valid assumption at all. | 07:35 |
| dcaliste | The "import" trick works well enough for the moment. We can keep this issue of importation in non existing collection in mind up to the moment we arrive at a pleasant solution. | 07:37 |
| chriadam | for version 2.0, once we have a "proper" access control daemon (which the plugins themselves can query, in order to apply the required access control) we can remove the metadata db's altogether, and then the secrets daemon won't "get in the way" between client+plugin | 07:38 |
| chriadam | until then, I think we just need to live with such workarounds like the "import" collection etc :-( | 07:38 |
| dcaliste | That's fine with me, we have work around in the mean time that sort of work. | 07:39 |
| chriadam | yep. thanks for pointing that out - any chance you could raise an issue in github which describes this problem, so we don't forget? | 07:39 |
| dcaliste | By the way, thanks a lot for the authentication correction. It works great now. | 07:39 |
| dcaliste | Ok, for a Github issue as todo for today ;) | 07:40 |
| chriadam | thanks for poking me about that devicelock issue, would have been quite bad to ship with that bug! | 07:40 |
| chriadam | I had nothing else, did you have anything else to discuss? again, sorry we haven't had time to look at your jolla-email patch in detail yet, or to merge the gpg plugin yet | 07:41 |
| chriadam | we definitely will do so as soon as 2.2.1 is out. | 07:41 |
| dcaliste | Well, I've address a keyboard issue in jolla-email that pvuorela kindly makes it in for 2.2.1, but I've found a bad issue with later, send a patch but he is on vacations I guess. | 07:42 |
| chriadam | rainemak: ^ | 07:42 |
| chriadam | yes he just left to vacation, maybe rainemak can take that patch up? | 07:42 |
| dcaliste | Hopefully he will be back before 2.2.1 is out otherwise I will feel the same about bad bug shipped in a stable version... | 07:42 |
| dcaliste | About the time to look at PGP stuff to go in. No problem to wait for 2.2.1 stabilizing sure. | 07:43 |
| *** Nokius_ is now known as Nokius | 07:44 | |
| chriadam | I will follow up internally about the keyboard issue. did you describe it in a PR comment or? | 07:46 |
| dcaliste | Yes, thank you : https://bitbucket.org/jolla/ui-jolla-email/pull-requests/419 | 07:47 |
| chriadam | no problem :-) | 07:48 |
| chriadam | thank you | 07:48 |
| dcaliste | Great, so good luck with 2.2.1 stabilization. I'll add the github issue we discussed and work on the account setting UI. | 07:49 |
| dcaliste | Have a nice week. | 07:49 |
| chriadam | thanks, you too! | 07:52 |
| *** alexxy[home] is now known as alexxy | 08:51 | |
| *** ahjo is now known as ahjolinna | 09:47 | |
| sledges | little more l10n please :) https://together.jolla.com/question/187177/official-announcement-l10n-strings-for-221-round-2/ | 11:38 |
| kimmoli | otg ftw. rpi sd card superblock corrupted, onyx and sailfish to rescue | 16:08 |
| kimmoli | fsck fixed it | 16:09 |
| *** feodoran is now known as Guest21561 | 23:49 | |
| *** feodoran_ is now known as feodoran | 23:49 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!