| rinigus | @hnj: it is impossible to keep API keys secret on OBS, to my knowledge. | 05:21 |
|---|---|---|
| Thaodan | hnj, rinigus: You can hide certain areas depending on the way obs is set up like e.g. prjconf. Defining API keys in the macros section is a good way to do it but its public in the prjconf | 06:34 |
| Thaodan | https://en.opensuse.org/openSUSE:Build_Service_prjconf#Macros | 06:35 |
| rinigus | Thaodan: it is not very clear from your reply - to my understanding, prjconf is publicly readable. so, in this respect, it is not really hidden. or can we make it private somehow? | 06:36 |
| Thaodan | rinigus: It's the only area to define macros in obs, using ACLs you could restrict access I think. | 07:05 |
| rinigus | Thaodan: can those ACLs be set by us at OBS? I am not aware of any ACL settings for project... | 07:39 |
| dcaliste | Hello chriadam, sorry to be late today. | 08:13 |
| chriadam | hi dcaliste, no problem of course | 08:13 |
| chriadam | I hope that you had a nice vacation last week | 08:13 |
| dcaliste | Yes, it was really great. The weather was still gentle for the Autumn and sailing along the Italian riviera was marvelous. | 08:15 |
| dcaliste | Thank you for the two merges in CalDAV repo. | 08:15 |
| chriadam | sounds great | 08:15 |
| chriadam | no worries, I finally got around to testing and reviewing those | 08:15 |
| chriadam | and Pekka has been busy merging various other PRs we discussed last meeting, also, I believe | 08:16 |
| dcaliste | Yes, I thank him also. All recent MRs have been merged now. | 08:17 |
| dcaliste | Before my vacations, I looked at allowing GnuPG integration with jailed applications. | 08:17 |
| dcaliste | The result is scattered among comments in various MRs, but here is the essence: | 08:17 |
| dcaliste | we have three possibilities actually: | 08:17 |
| dcaliste | - currently, a gpg-agent is run in pipe mode at each time an application wants to access GnuPG data. This gpg-agent may have to run the pinentry provided by sailfish secrets. To do so, sailfish-secrets socket should be visible from the jail and the jailed application should be granted DBus talk to the daemon. | 08:19 |
| dcaliste | This is PR https://github.com/sailfishos/sailfish-secrets/pull/178 and https://github.com/sailfishos/sailjail-permissions/pull/108 | 08:20 |
| dcaliste | thaodan commented on those (and I agree with hiw view) that the gpg-agent should be run in daemon mode instead and outside the jail. | 08:21 |
| chriadam | I wonder if inz or tomi have any comments ^ they know about sailjail stuff more than I do. or abr maybe ^ | 08:22 |
| dcaliste | - second possibility: run the gpg-agent in daemon mode. I've tried to use systemd socket listening to run the gpg-agent on demand, but our GnuPG stack is too old for this, I believe, and we always miss the first acess. If the gpg-agent is run unconditionnaly at user session startup it's alright. | 08:22 |
| dcaliste | These are PRs https://github.com/sailfishos/gnupg2/pull/1 and https://github.com/sailfishos/pth/pull/1 | 08:23 |
| dcaliste | (the pth stuff is a dirty fix for running gpg-agent in daemon mode, they have moved away from pth upstream since a long time) | 08:24 |
| dcaliste | - third possibility: upgrade the GnuPG stack to latest. This is gplv3, so it should not be installed by default. | 08:24 |
| dcaliste | this possibility is the nicest in my opinion. | 08:24 |
| dcaliste | It requires to create some new repositories to support both gnupg-legacy and gnupg-latest. (the same for libassuan and gpgme) | 08:25 |
| dcaliste | I've begun to propose MR to upgrade the stack where possible: https://github.com/sailfishos/libgpg-error/pull/2 and https://github.com/sailfishos/libgcrypt/pull/2 | 08:26 |
| dcaliste | But some dependencies may raise an issue : GnuTLS must be moved to version 3… I don't know what GnuTLS is a dependency of at the moment, but moving from version 2 to 3 may break them. | 08:27 |
| chriadam | lbt: do you know how this could be checked ^ (dependencies of GnuTLS I mean) | 08:27 |
| dcaliste | (plus the build system of version 3 is strange and I don't fully understand at the moment how to build it from git without it pulling openssl in the autogen.sh stage for instance, but that's another story). | 08:28 |
| dcaliste | To summarize, choosing among these three possibilities requires some decision from Jolla side than just bug fixing. I can provide as many technical detail as required to help taking the decision. | 08:30 |
| chriadam | how does upgrading the stack to the latest help us solve this problem, out of interest? | 08:31 |
| chriadam | is it that we could then run the gpg-agent on demand via systemd dbus-activated unit? or? | 08:31 |
| dcaliste | latest gpg-agent is supporting systemd integration. So we can have a smooth experience like on desktop, where systemd is responsible of a socket under /run/user and launch the gpg-agent in daemon mode on demand. | 08:32 |
| chriadam | ok. but what would be required in terms of permissions between gpg-agent and sailfish-secretsd? | 08:32 |
| chriadam | from sailjail perspective, I mean | 08:33 |
| dcaliste | Then the daemon is outisde the jail and the already existing GnuPG.permission are enough for a jailed application to access GnuPG functionalities including password demands... | 08:33 |
| dcaliste | Currently the gpg-agent in pipe mode (i.e. launched by the jailed app) is inside the jail and cannot talk to the secret daemon. | 08:33 |
| dcaliste | There are two possible modes: | 08:35 |
| chriadam | Ah! I see. the issue is that currently it's run with same sandbox permissions as the app. In future, we will run it as a separate daemon and can specify its own specific sandbox (e.g. allowing dbus access to sailfish-secretsd) | 08:35 |
| dcaliste | - jailed:(app->gpg-agent-pipe)->secret-daemon (thjis is propositin one) | 08:35 |
| dcaliste | - jailed:(app)->gpg-agent-daemon->secret-daemon (this is proposition 2 with current stack, or propistion 3 with latest stack) | 08:36 |
| chriadam | indeed. | 08:36 |
| chriadam | option (3) is clearly best, but it might not be possible. need lbt's feedback I guess. maybe pvuorela knows how to check what might depend on GnuTLS also? | 08:37 |
| Renaud[m] | <chriadam> "lbt: do you know how this..." <- Hi, I have added an updated gnutls on chum but on official sfos it is only needed for cups | 08:37 |
| dcaliste | Proposition one is simple and work out of the box but is different from desktop choices. | 08:37 |
| Renaud[m] | I wanted to do a pull request for sfos but didn't have time yet | 08:38 |
| dcaliste | Renaud[m], wouh, that's great.. | 08:38 |
| chriadam | if option (3) is not possible, I am still leaning toward (2) just because I would prefer completely separate sailjail for the daemon, and it is conceptually separate from any specific application which may wish to make use of it, IMO. | 08:38 |
| dcaliste | I can help if you agree to create the PR from your work in chum. | 08:38 |
| chriadam | Renaud[m]: how do you check what the dependencies are? is some rpm reversedepends thing enough? or? | 08:38 |
| Renaud[m] | zypper search --requires gnutls | 08:39 |
| chriadam | and ... I didn't know we had cups on the device. do we connect to printers? etc | 08:39 |
| chriadam | Renaud[m]: ah, that might only find things in certain public repositories, though, I guess. | 08:39 |
| Renaud[m] | Yes, I guess | 08:40 |
| chriadam | well, it is still a good indicator that we don't depend on it for other things | 08:40 |
| Renaud[m] | dcaliste: Yes, I'll do it eventually. I'll try to find time this week | 08:40 |
| chriadam | but will lbt to check | 08:40 |
| * lbt has a glance through the backlog but it'll take a while to context-switch & absorb... and I have a meeting coming up that I need to prep for... so I'll look at it later today | 08:40 | |
| chriadam | lbt: thanks very much, no rush | 08:40 |
| lbt | the dependency thing... that's not so tough | 08:41 |
| chriadam | if you have an answer before the same time next week, that would be appreciated! | 08:41 |
| lbt | rpm gives install time dependencies and has a whatdependson option iirc | 08:41 |
| Renaud[m] | For context on why and how I submitted it to chum, see https://github.com/sailfishos-chum/main/issues/26 | 08:42 |
| lbt | OBS provides build time info like that | 08:42 |
| lbt | rpm -q --whatrequires <packagename> | 08:42 |
| dcaliste | (sorry I'm busy for 5 minutes) | 08:42 |
| chriadam | Renaud[m]: thanks for that. also, thanks for mentioning in this chat, I hope it helps dcaliste with his exploration of that possibility | 08:42 |
| lbt | https://build.sailfishos.org/package/binary/sailfishos:chum/gnutls?arch=armv8el&filename=gnutls37-3.7.2-1.1.1.jolla.src.rpm&repository=4.2.0.21_armv7hl | 08:45 |
| lbt | and | 08:46 |
| lbt | https://build.sailfishos.org/package/binary/sailfishos:chum/gnutls?arch=armv8el&filename=gnutls37-3.7.2-1.1.1.jolla.src.rpm&repository=4.2.0.21_armv7hl | 08:46 |
| lbt | to get those pages navigate to https://build.sailfishos.org/package/show/sailfishos:chum/gnutls | 08:47 |
| lbt | Then in the box on the right pick a build repo - eg 4.2.0.21_armv7hl (left column 2nd from bottom) | 08:47 |
| chriadam | ty | 08:48 |
| lbt | you see a list of rpms - eg the src rpm shows the BR... the gnutls37-3.7.2-1.1.1.jolla.armv7hl.rpm shows the runtime deps and reverse deps for apps in this repo | 08:48 |
| chriadam | pvuorela: aside from possible dependencies to GnuTLS, do you see any other reason why option (3) wouldn't be possible? | 08:48 |
| * lbt idly wonders if we're sidestepping a security barrier by using dbus ... is there an ACL mechanism to limit access so only certain apps can use the secrets? (I may have misunderstood) | 08:50 | |
| chriadam | there is a socket path which must be allowed for the specific app to access | 08:53 |
| chriadam | and then the daemon enforces its own ACL on a per-application basis, to ensure that an app cannot access secrets it shouldn't | 08:53 |
| lbt | ack | 08:53 |
| chriadam | but note: we should get rid of that "sailfish secrets daemon does ACL" nonsense, and move that work into the plugins | 08:54 |
| dcaliste | Talking about the secret socket, at the moment, this socket is under /run/user directly, so not visible to any jailed application. | 08:54 |
| chriadam | enabling us to remove the bookkeeping db from the daemon altogether. but that's "future work" once there's stronger use cases for it at all... | 08:54 |
| dcaliste | So disregarding the GnuPG case, if any jailed application would like to access the secret daemon, one need first to accept PR https://github.com/sailfishos/sailfish-secrets/pull/178 and create a dedicated secrets.permission file. | 08:56 |
| pvuorela | chriadam: need to check all this more closely. but i'm a bit afraid how the dependencies all go. | 08:56 |
| dcaliste | About the path to proposition 3 (assuming GnuTLS upgrade is not an issue) one new to create new repo for libassuan, gpgme and gnupg. | 08:56 |
| chriadam | dcaliste: unfortunately I have to go to another meeting in a couple of minutes, so we might need to wrap up for today | 08:58 |
| dcaliste | pvuorela, yes I agree, even besides direct dependencies, like GnuTLS, gpg-error, gcrypt and friends, it is creating an additional burden to check that code depending on GnuPG (or gpgme) will work for both stack, legacy and latest. | 08:58 |
| chriadam | hopefully I will be able to discuss with lbt and pvuorela during this week about whether option (3) is possible | 08:59 |
| dcaliste | chriadam, sure, no problem. We can continue the discussion next week. | 08:59 |
| chriadam | thank you very much | 08:59 |
| chriadam | have a great week! | 08:59 |
| * chriadam -> away, gnight | 08:59 | |
| dcaliste | Enjoy your week, too. | 08:59 |
| *** ggabriel is now known as Guest4697 | 09:04 | |
| rinigus | lbt: would you mind to check out why sailtrix build is blocked (which dod packages are missing) at https://build.sailfishos.org/package/show/sailfishos:chum/harbour-sailtrix ? | 12:44 |
| Thaodan | dcaliste: | 14:29 |
| lbt | there's a problem with a server - raised a support request | 14:29 |
| Thaodan | dcaliste: About legacy and latest compabilty is indirectly already taken care of since we fix legacy vs. upstream only test against latest gnupg. | 14:30 |
| Thaodan | Only of the sailfish secrets side there will be more testing however I don't think users that want to use gnupg with sailfish secrets want to use legacy gnupg | 14:32 |
| lal883[m] | rinigus: if you have open camera in waydroid and enabled Camera2 API in there, Tama flash works properly when shooting in manual exposure mode. | 15:40 |
| lal883[m] | rinigus: and if you further enabled alternative flash mode in photo settings, flash works properly in all modes. Now that is some what profit. | 15:41 |
| rinigus | lal883: does it get "exported" to SFOS or is limited to opencamera? | 16:26 |
| lal883[m] | rinigus I wish it did. But doesn't look like that. Flash isn't in sync still in SFOS apps. | 16:35 |
| rinigus | lal883: would have been too lucky :) | 16:37 |
| hnj | Thaodan, rinigus: thanks for your feedback so far | 16:40 |
| hnj | Thaodan: can you answer rinigus’ question? »rinigus | Thaodan: can those ACLs be set by us at OBS? I am not aware of any ACL settings for project...« | 16:40 |
| rinigus | lbt: that "problem" response was regarding OBS and related to the issue with sailtrix, right? or is it a wishful thinking... | 18:01 |
| HengYeDev[m] | Is it a known issue that the search in OBS is broken? | 18:30 |
| rinigus | HengYeDev: I am not sure whether it was working after OBS update, but it was broken before. you could use `osc` command client for search | 19:19 |
| piggz | hnj: i imagine it would be hard to keep such things secret | 19:27 |
| hnj | piggz: yeah, probably is … but I guess I also understand why it’s being needed and should be kept secret /-: | 20:40 |
| piggz | hnj: one option is to scramble it ... far from ideal, but better than nothing ... probably someone who is determined could get it either way | 21:20 |
| hnj | piggz: hm, scramble it? but the routine to unscramble it would sit in the same code, right? | 21:23 |
| piggz | hnj: sure | 21:25 |
| piggz | its what i do for my strava api keys | 21:25 |
| hnj | piggz: ah ok, any chance I can get you to answering on https://github.com/walokra/sailimgur/issues/26? (: | 21:32 |
| poetaster | hnj: walokra responded pretty promptly when I asked him about submitting to chum. And it looks like he's going to update the store. So I'd say just be patient. Or practice reading binary ;) | 21:46 |
| poetaster | hnj: I just read the issue, but I sadly can't help at the moment. | 21:47 |
| hnj | poetaster: hehe, no worries, thanks for looking into it (: | 21:59 |
| poetaster | hnj: I'm sort of on a bender. It's a few too many sticks in different fires, but, hey! I hope your having some fun :) | 22:01 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!