dcaliste | Hello chriadam and rainemak, sorry for the late connection. | 07:06 |
---|---|---|
dcaliste | Moreover, I'll have to quit today at 9:30. | 07:06 |
chriadam | dcaliste: hi, no problem | 07:08 |
chriadam | I hope you had a good week | 07:09 |
rainemak | hi dcaliste & chriadam | 07:09 |
dcaliste | I'm fine thank you. As said last week, S/MIME signature verification is working out of the box with the current gpgme framework. | 07:09 |
chriadam | we're still fighting with release issues for 2.2.1, so I haven't made any progress regarding things you've raised last week etc :-( | 07:09 |
dcaliste | I've tested signing process this week. | 07:09 |
chriadam | but that's great news | 07:09 |
dcaliste | You may have notice some discussions with lbt and abranson on #mer. | 07:10 |
chriadam | I did not see those yet actually | 07:10 |
dcaliste | It requires a new package: dirmngr to handle certificates. | 07:10 |
chriadam | ah | 07:10 |
dcaliste | I've packaged it, see https://git.merproject.org/dcaliste/dirmngr | 07:11 |
chriadam | in the future, I think we want certificates to be stored in / managed by the secrets daemon itself, I believe, although we haven't started looking into certificate management in any detail yet | 07:11 |
dcaliste | lbt helped me yesterday to finilising the packaging. | 07:11 |
dcaliste | I'm waiting for it to enter Mer officially. | 07:11 |
dcaliste | I agree that secret should handle certificates, but anyway gnupg will have to speak to something that speaks its language to handle certificates. | 07:12 |
dcaliste | Currently it's simple to compile dirmngr. | 07:12 |
dcaliste | With this addition, CLI S/MIME signature is working. | 07:13 |
dcaliste | I nneed to check now that it's working from the email app also. | 07:13 |
chriadam | I'm a bit worried about adding yet another service to the base OS | 07:13 |
rainemak | depending how the dirmngr will be used... maybe we should try to build a facade to the secrets through which we could handle certs... aiming to start with an existing solution and wrapping it => just an idea | 07:14 |
chriadam | e.g. increased memory usage, potential duplication of functionality | 07:14 |
chriadam | but that might be an idea: secrets API for cert management could just use dirmngr plugin for actual provision etc | 07:14 |
dcaliste | Well it's not a daemon, it's called on demand by gnupg process. | 07:14 |
chriadam | ah, good | 07:14 |
rainemak | right... ah, so need to be there regardless | 07:15 |
rainemak | at the same time if it good for us... maybe worth adding it as a plugin to the secrets | 07:15 |
dcaliste | rainemak, I agree. But I need to better understand first what it is doing actually and how to see what kind of API we can propose in secret for this. | 07:16 |
rainemak | agree | 07:17 |
chriadam | yep | 07:17 |
dcaliste | So, all in all, signing and verification work more or less for PGP and S/MIME. | 07:17 |
chriadam | that's exceptionally good news, thank you for doing that investigation and work | 07:17 |
dcaliste | rainemak, did you have time to look to provide me access to account-settings to add the UI to activate these? | 07:18 |
chriadam | in August most people from Finland will be back at work, so I expect the ball will get "properly" rolling to get all these pieces more polished and merged+tagged then | 07:18 |
dcaliste | chriadam: ok fine with me. I'll be in and off during the two summer months, but I can follow. | 07:19 |
dcaliste | chriadam: about the signature process, at one moment, you'll have to test it with your customer, because it is working with my workflow, but one will have to test that it's working for some else also ;) | 07:20 |
chriadam | yes, of course | 07:20 |
chriadam | although it's worth noting that Certificate API (and features) has not been a priority (yet) from their POV as far as we have discussed recently | 07:21 |
chriadam | so not sure how much feedback / testing we will get in the near future in that regard | 07:21 |
chriadam | but will definitely raise the topic during our discussions | 07:21 |
dcaliste | Yes, certificates from my point of view is a one shot: you add the root certificate of your institution once and then you can forget about it up to the expiry date. | 07:22 |
chriadam | ah right | 07:22 |
chriadam | until/unless it's revoked? I guess that's what dirmngr handles? | 07:22 |
dcaliste | dirmangr connect to the net to know revocation list and invalidate certificate locally from my understanding. | 07:23 |
rainemak | dcaliste, sorry... forgot that. will do it after this meeting | 07:23 |
dcaliste | rainemak, no problem, I played with dirmngr anyway last week. | 07:24 |
rainemak | dcaliste, I have "yellow" note-it under my nose :) | 07:24 |
dcaliste | rainemak ;) | 07:24 |
chriadam | we have _some_ handling of certs in Sailfish OS, but not sure precisely what that means. It may just be "a bundle of certs live in some directory under /etc or something" not sure... | 07:24 |
chriadam | anyway, that will be interesting to follow up on in the future | 07:25 |
dcaliste | chriadam: that's my understanding and that these certificates are used by Mozilla chain of trust, but sadly GnuPG is using another implementation... | 07:25 |
chriadam | ah | 07:25 |
dcaliste | AFAIK in fact. | 07:25 |
dcaliste | I may be wrong, not yet up to date on this topic. | 07:25 |
dcaliste | I think I will investigate more how gnupg is handling certificates, listing them, importing them... | 07:26 |
chriadam | that would be very helpful! | 07:26 |
dcaliste | This will help designing an API when required. | 07:26 |
chriadam | very much so | 07:26 |
chriadam | I expect that activity to take off in earnest around November-ish, but that's a guess | 07:26 |
dcaliste | I will open an issue in Github where to write down my understanding of the matter. | 07:27 |
chriadam | tyvm | 07:27 |
dcaliste | About the discussion on Github with Venemo remark, I may agree that my separation UID <-> collection and subkeys <-> keys may not be that smart after all. | 07:28 |
chriadam | I didn't follow that discussion | 07:28 |
chriadam | I think the main issue is that we didn't allow for subkeys in our API | 07:28 |
dcaliste | I is dividing well the keys in the UI, but it makes the list quite long and difficult to read. | 07:29 |
dcaliste | About subkeys, it's fine with the current API, subkey in GnuPG is a key in an existing collection, which fits well in fact. | 07:29 |
chriadam | having separate collections is a required feature, but maybe the way that's exposed in the UI is a bit clunky because it's assumed that there are few collections but many keys in each collection | 07:29 |
dcaliste | So I'm wondering if it's a proper logical division (UID == collection) or a rendering issue... | 07:30 |
dcaliste | I'm wondering if in GnuPG I don't expose any collection and put all keys together with a filter on the UID... | 07:30 |
dcaliste | It's something that is easy to change anyway. | 07:31 |
dcaliste | And won't have much impact since the keys are actually stored by GnuPG anyway. | 07:31 |
dcaliste | I'm sorry I need to interrupt our discussion, it's time for me to bring my child to the doctor. | 07:31 |
chriadam | no problem at all | 07:31 |
chriadam | thank you for your time | 07:31 |
dcaliste | We can continue next week on this topic! | 07:32 |
chriadam | I hope your child is feeling better soon! | 07:32 |
chriadam | yes. have a great week! | 07:32 |
dcaliste | Is fine, it's a simple rendez-vous. | 07:32 |
chriadam | ah, good | 07:32 |
dcaliste | Have a nice week chriadam and rainemak. | 07:32 |
chriadam | thanks! | 07:32 |
rainemak | dcaliste, thanks! you too | 07:32 |
*** frinring_ is now known as frinring | 10:13 | |
*** Nokiu_ is now known as Nokius | 12:04 | |
*** feodoran is now known as Guest94788 | 18:41 | |
*** feodoran_ is now known as feodoran | 18:42 | |
*** feodoran is now known as Guest31715 | 23:58 | |
*** feodoran_ is now known as feodoran | 23:58 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!