| *** frinring_ is now known as frinring | 01:56 | |
| dcaliste | Hello chriadam, how are you? | 07:01 |
|---|---|---|
| chriadam | dcaliste: hi! | 07:02 |
| chriadam | I'm well thanks | 07:02 |
| chriadam | how are you? | 07:02 |
| dcaliste | Fine, thank you. I've some questions ;) | 07:03 |
| chriadam | sure :-) | 07:03 |
| dcaliste | I would like to store key passphrases in a secret collection. I create the collection with DeviceLock and DeviceLockKeepUnlocked. | 07:05 |
| dcaliste | Then, I can store a secret inside, I've checked with the setting page that my secret exists. | 07:05 |
| dcaliste | As long as the daemon is running, it's fine, then, passphrase is retrieved from storage. | 07:06 |
| dcaliste | But when I stop the daemon, and restart it, my collection is locked (there is a lock icon in the setting page). | 07:06 |
| dcaliste | And I don't know how to unlock it. | 07:07 |
| chriadam | very strange... let me do a quick test on my device | 07:08 |
| dcaliste | There is no dialog poping up saying that the collection is locked and should be unlocked for access. | 07:08 |
| chriadam | we don't pop up such a dialog automatically | 07:08 |
| dcaliste | Maybe I miss some parameter on collection creation… | 07:08 |
| chriadam | you have to tap on the (locked) collection in the settings page to trigger the unlock fow | 07:08 |
| chriadam | flow* | 07:08 |
| dcaliste | Could the unlock flow be triggered by a request in an app? | 07:08 |
| chriadam | the "automatically trigger unlock flow when an operation is attempted" work is TODO | 07:09 |
| dcaliste | Not just in the setting? | 07:09 |
| chriadam | dcaliste: yes | 07:09 |
| chriadam | yes | 07:09 |
| chriadam | LockCodeRequest | 07:09 |
| dcaliste | Ok, so currently I'll put the code in pinentry to unlock if locked. | 07:09 |
| dcaliste | Good, good. | 07:09 |
| chriadam | uh | 07:09 |
| chriadam | wait | 07:09 |
| chriadam | I'm wrong | 07:09 |
| chriadam | LockCodeRequest allows lock/unlock of plugin or metadatadb, not collection... | 07:10 |
| chriadam | collection WILL be automatically unlocked if you attempt to access it | 07:10 |
| chriadam | I mean the unlock flow will be triggered automatically | 07:10 |
| chriadam | so if that's failing... that is bad, it means that the devicelock key was unable to be regenerated upon daemon restart | 07:10 |
| chriadam | let me test on device, one sec | 07:10 |
| dcaliste | Ah, so the message in daemon, was "unable to ensure the authenticity of caller" or something like that (from memory). | 07:11 |
| chriadam | Password Agent was unable to verify the authenticity of the user | 07:16 |
| chriadam | this can occur if the security UI is running in a different session for some reason, although I don't fully understand why that's the case. | 07:17 |
| chriadam | I can reproduce the issue. I will investigate tomorrow - thankyou very much for reporting that | 07:17 |
| dcaliste | Great, sorry for the additional work! | 07:17 |
| chriadam | dcaliste: no problem. so, if you tap on the collection from the Settings/Keys page, it does trigger the unlock flow for that collection | 07:19 |
| chriadam | but I don't understand why that doesn't work for an application (e.g. shell script) run from nemo terminal | 07:19 |
| dcaliste | Well, in fact no, and I have no message in daemon as far as I remember. I'm reproducing… But yes, my testing work flow is to run 'gpg2 -s toto' in terminal as nemo through ssh. | 07:21 |
| chriadam | quick investigation shows a crash | 07:23 |
| chriadam | (gdb) bt | 07:23 |
| chriadam | #0 0xb6c6a2f4 in QVariant::QVariant(QVariant const&) () from /usr/lib/libQt5Core.so.5 | 07:23 |
| chriadam | #1 0x2a04250e in QList<QVariant>::takeFirst (this=this@entry=0xbeffef4c) at /usr/include/qt5/QtCore/qlist.h:552 | 07:23 |
| chriadam | #2 0x2a061d44 in Sailfish::Secrets::Daemon::ApiImpl::RequestProcessor::authenticationCompleted (this=0x2a113908, callerPid=<optimized out>, requestId=8, | 07:23 |
| chriadam | result=...) at SecretsImpl/secretsrequestprocessor.cpp:6201 | 07:23 |
| chriadam | unguarded takeFirst() | 07:23 |
| chriadam | I will continue investigation tomorrow, thanks! | 07:23 |
| chriadam | dcaliste: any other questions? | 07:23 |
| chriadam | by the way, we branched 2.2.1 yesterday | 07:23 |
| chriadam | so I will hopefully merge gpg plugin this week | 07:23 |
| dcaliste | Another (simpler) question: I've put a setting in /desktop/sailfish/secrets/storeGnuPGPassphrases (boolean), is it the right place? | 07:23 |
| chriadam | dcaliste: dconf? heh. this is an ongoing question for us internally... | 07:24 |
| chriadam | short answer is: dconf is fine | 07:24 |
| dcaliste | And related question, if I want to make a UI for this, where should I put it? | 07:24 |
| chriadam | long answer is: long term, we think we need to unify how we store settings, currently different apps use different things (.conf files in /etc which is very bad if we want readonly root partition, dconf which has issues with access control enforcement, .ini files in /home/nemo/.local/share/system/privileged/Contacts etc which ...) | 07:25 |
| dcaliste | Because, caching passphrase is comfortable but some people will want to disable this. | 07:25 |
| chriadam | dcaliste: install a subpage to Settings application is the usual way. | 07:25 |
| chriadam | the email app may have an example of that | 07:26 |
| dcaliste | Yeh, but that's for application, here I don't have an application… It may go to somewhere in the key setting page, but I don't see where. | 07:27 |
| chriadam | dcaliste: I see | 07:29 |
| chriadam | that Keys settings page is super rough, IMO | 07:29 |
| chriadam | it was rushed big time, and Martin Schuele will no doubt want to make many many changes to it in the nearish future | 07:29 |
| dcaliste | Yes, so maybe keep in mind a little setting to store passphrases ;) | 07:30 |
| chriadam | so I suspect that such settings can go in there (per-plugin settings, perhaps programmatically generated toggles from plugin .json or something?) | 07:30 |
| chriadam | yes, and something like that also might be possible (e.g. reduced security but more convenient) | 07:30 |
| dcaliste | Last question: I've added account settings in QMF to add for an email account if we desire digital signature, the key id to be used and the protocol. | 07:33 |
| dcaliste | I would like to add a UI to set these beside the checkbox "append a signature" in the account setting page for instance. May I request to have access to jolla-settings-accounts-extensions-email repo for this? | 07:33 |
| chriadam | it's probably just part of jolla-settings-accounts. yes, although all of the accounts framework stuff is extremely horrible at the moment, mostly because I had no idea what I was doing when I originally started work on the accounts stuff. | 07:34 |
| dcaliste | I've added an issue in bitbucket to discuss these design choices: https://bitbucket.org/jolla/ui-jolla-email/issues/2/design-discussion-on-signature-process-and | 07:34 |
| chriadam | dcaliste: however I cannot give access to such things, and this week rainemak + pvuorela + jpetrell are on vacation | 07:34 |
| chriadam | rainemak should be back next week, if you poke him about that then, he can ask about getting you access | 07:34 |
| dcaliste | No problem, it's not in a hurry and you can discuss internally when they are back if that's reasonable or not. | 07:35 |
| chriadam | great, will do. poke me so I don't forget, next week :-) | 07:35 |
| dcaliste | Nice, thank you. | 07:37 |
| chriadam | ok, if nothing else, I need to head off for the night - have a great week :-) | 07:38 |
| dcaliste | Sure, have a good night. See you next week. | 07:38 |
| *** cvp is now known as sailfishmods | 08:18 | |
| *** feodoran is now known as Guest70251 | 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/!