[06:20] <zyga> good morning
[06:34] <zyga> good morning mborzecki
[06:34] <mborzecki> zyga: hey
[07:29] <mborzecki> school run, brb
[07:51] <mborzecki> re
[07:51] <mborzecki> mvo: hey
[07:55] <mvo> good morning mborzecki
[07:55] <mvo> mborzecki: anything I should review right away?
[07:55] <mvo> (or do?)
[07:59] <mup> PR snapd#9597 closed: gadget: correct sfdisk arguments <Created by xnox> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9597>
[08:03] <mborzecki> mvo: there are some smaller PRs, split out from the degraded mode one that Ian opened
[08:07] <mvo> mborzecki: yeah, saw them
[08:44] <mborzecki> mvo: applied your suggestion in https://github.com/snapcore/snapd/pull/9598
[08:44] <mup> PR #9598: secboot: add LockTPMSealedKeys() to lock access to keys independently <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9598>
[08:47] <mvo> mborzecki: \o/ thank you
[09:04] <mborzecki> mvo: ok, let's land 9598 and 9599, then update 9560
[09:05] <mvo> mborzecki: +1
[09:05] <mvo> mborzecki: does it require force merges? I am in a meeting right now
[09:10] <mborzecki> mvo: i pushed a commit to each so we need to wait for runs to complete and maybe force merge after that
[09:10] <mvo> mborzecki: ta!
[09:17] <zyga> good morning mvo
[09:18] <mvo> good morning zyga - nice to see you
[09:18] <zyga> :-)
[09:20] <zyga> good luck with the release
[09:44] <mborzecki> mvo: can you merge https://github.com/snapcore/snapd/pull/9599 ?
[09:44] <mup> PR #9599: secboot: refactor Unlock...IfEncrypted to take keyfile + check disks first <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9599>
[10:04] <mup> PR snapd#9598 closed: secboot: add LockTPMSealedKeys() to lock access to keys independently <Simple 😃> <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9598>
[10:11] <mvo> mborzecki: in a meeting still
[10:12] <mborzecki> mvo: ok, i've restarted the job, i'll merge it if the required tasks are successful
[10:44] <mup> PR snapd#9599 closed: secboot: refactor Unlock...IfEncrypted to take keyfile + check disks first <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9599>
[10:45] <ogra> is the API equivalent of a "snap ack" to POST the downloaded assertion and then "snap install" for the snap package will just work ?
[10:47] <zyga> ogra, yes
[10:47] <ogra> thx !
[10:47] <zyga> ogra, both are just API calls
[10:47] <zyga> one is the assertion
[10:47] <zyga> and the other local file post for install
[10:48] <ogra> yeah, i thought so ... a customer was asking because he couldnt find an actual "snap ack" in the API docs
[10:48] <zyga> I think it's this endpoint ...
[10:48] <zyga> https://github.com/snapcore/snapd/blob/master/daemon/api_asserts.go#L40
[10:49] <zyga> so just post /v2/assertion
[10:49] <zyga> so just post /v2/assertions
[10:49] <zyga> (sorry, plural)
[10:53] <ogra> yup .... thanks a lot
[11:02] <mborzecki> mvo: #9600 is updated, it's still 1k+ lines added though
[11:02] <mup> PR #9600: cmd/s-b/initramfs-mounts: refactor recover mode to implement degraded mode <Complex> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9600>
[11:24] <xnox> let me try uc22 image again with new snapd from edge
[11:24] <xnox> cause then, i think i might be able to start building those regularly; and/or like remodel from uc20 to uc22
[11:29] <tobias_> abeato: Is there a reason the pulseaudio snap is not listed on the global store, or am I just overlooking something? I was a bit confused that I can `snap install pulseaudio`, but `snap search pulseaudio` does not include it.
[12:07] <mup> PR snapcraft#3351 closed: storeapi: import sort with isort <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3351>
[12:07] <mup> PR snapcraft#3353 closed: tools: import sort with isort <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3353>
[12:17] <mup> PR snapcraft#3354 closed: cli: import sort with isort <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3354>
[12:23] <pedronis> mvo: mborzecki: somethings looks wrong in 9600, what am I missing, I don't understand the code here: https://github.com/snapcore/snapd/pull/9600#discussion_r518010580 ?
[12:23] <mup> PR #9600: cmd/s-b/initramfs-mounts: refactor recover mode to implement degraded mode <Complex> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9600>
[12:37] <mborzecki> pedronis: yes, i see your point
[12:39] <pedronis> mborzecki: there's probably a way to do this this way by stopping asking for the recovery key and then doing it ourselves I suppose
[12:39] <mborzecki> pedronis: so in this case, should recovery key be tried after fallback data key fails?
[12:39] <pedronis> that's the default secboot behavior
[12:39] <pedronis> we have options I suppose
[12:40] <pedronis> but as is it seems we would get stuck asking the recovery key before anything else
[12:42] <mborzecki> pedronis: hm there's just the recovery key for data, so the sequence would be sealed run key -> fallback sealed data key -> recovery key (asking for it) right?
[12:42] <pedronis> no, there's also a recovery key for save only
[12:42] <pedronis> (called the reinstall.key)
[12:45] <mborzecki> pedronis: but that we'd ask for when attempts unlockin save are exhausted, data key didn't work, or was not accessible, and then the fallback failed too?
[12:46] <pedronis> yes
[12:47] <pedronis> it might also be the only recovery key we ask if/when we had a clear re-install mode
[12:47] <zyga> hey pedronis
[12:47] <zyga> welcome back
[12:48] <pedronis> zyga: hi :)
[12:50] <pstolowski> hey
[12:50] <zyga> hey pawel
[12:53] <abeato> tobias_, it is unmaintained, that's why it is unlisted
[12:54] <ogra> and on a sidenote people should really not install it on desktops ... for which the unlisting helps too
[12:56] <pedronis> mborzecki: or we could use the multi key unseal, and it does everything for us in one go, but then we need more work to understand the errors it returns
[12:57] <pedronis> (which I think is something I mentioned last week)
[12:57] <mborzecki> pedronis: https://imgur.com/a/5xLrYCP does this make sense?
[12:57] <tobias_> abeato: oh ok, I assumed that the renewed activity in the repo + the interfaces update meant that it's maintained again. Sorry then 😊 ogra: Guess so; I wanted to test it on a PC Core device though to test if there's additional work to do for WPE webkit kiosk to provide proper sound output. Distraction from the segfault problem on armhf 😄
[12:58] <ogra> heh
[12:58] <pedronis> mborzecki: yes, it looks reasonable
[12:58] <abeato> tobias_, I did some update to it, but it does not mean it is really mainteined :) The idea why have is that you can use the existing snap to publish your own snap with the modifications you need
[12:58] <abeato> s/why/we/
[12:59] <ogra> and the existing one was heavily broken before alfonso fixed it in his heroic effort
[13:00] <tobias_> abeato, ogra: Sounds reasonable, thanks for the explanation!
[13:02] <pedronis> mborzecki: the multi key unlock would do all the top 3 boxes on the right, in one go
[13:13] <mborzecki> heh, there's no switch in secboot options to not try the recovery key
[13:14] <mborzecki> hm but recovery tries can be set to 0
[13:14] <mborzecki> ha
[13:24] <ijohnson> in retrospect I did think it weird that in order for the fallback key to be used, I needed to hit enter or otherwise provide garbage to the recovery key prompt in the initramfs
[13:26] <pedronis> ijohnson: fwiw there's also a default timeout of 90s in systemd-ask-password I think
[13:27] <pedronis> not that I think it makes sense to rely on it for this stage
[13:30] <ijohnson> yes we were talking about the timeout there but couldn't remember what it was
[13:30] <ijohnson> welcome back btw
[13:30] <pedronis> thx
[13:33] <ijohnson> is mborzecki working on updates to the pr? do we need to have a meeting about next steps today on the pr? /me is having breakfast, but could talk after SU
[13:34] <mborzecki> ijohnson: i'm adding a switcht to eanble/disable recovery key in unlocking the volumes
[13:34] <ijohnson> ok, but with that we will still need to add additional states to the state machine for actually trying to use the recovery key, no ?
[13:34] <mborzecki> yes
[13:37] <ijohnson> I sent an invite, maybe we don't need the meeting and can just talk during SU
[13:37]  * ijohnson gets back to eating
[13:40] <mborzecki> pedronis: ijohnson: https://github.com/snapcore/snapd/pull/9602
[13:40] <mup> PR #9602: secboot, cmd/snap-bootstrap: enable or disable activation with recovery key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9602>
[13:40] <mup> PR snapd#9602 opened: secboot, cmd/snap-bootstrap: enable or disable activation with recovery key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9602>
[13:40] <mborzecki> and then 9600 should disable recovery key completely (?)
[13:41] <pedronis> mborzecki: ?
[13:43] <mborzecki> pedronis: i mean in the code path that calls UnlockVolumeUsingSealedKeyIfEncrypted for recovery and do it in an explicit step
[13:43] <pedronis> mborzecki: ah, yes, explicit step
[13:43] <pedronis> your sentence sounded something else :)
[14:03] <tobias_> ijohnson: Sorry to nag you, but did you see my forum message re: cloud.conf? My gadget's cloud.conf is copied to /etc/cloud/cloud.cfg.d/80… properly, so I guess it's not applied because of format changes you mentioned?
[14:38] <ijohnson> tobias_: ah sorry yeah I didn't see that you had responded, let me take a look at your message now
[14:55]  * cachio lunch
[15:34] <mborzecki> afk for a bit, need to drive the kids around
[16:18] <mup> PR snapcraft#3356 opened: extensions: correctly spell the GTK_USE_PORTAL variable <Created by seb128> <https://github.com/snapcore/snapcraft/pull/3356>
[16:35] <ijohnson> pedronis: do you have an opinion on what sub dir on ubuntu-boot should be used for the run object keys? I was just naively doing /run/mnt/ubuntu-boot/device/fde/... but it occurred to me that we don't put the kernel assets on ubuntu-boot directly, we put them under /run/mnt/ubuntu-boot/EFI/ubuntu/
[16:35] <ijohnson> pedronis: there's also the model file, which we just put at /run/mnt/ubuntu-boot/model so perhaps device/fde is fine directly on ubuntu-boot
[16:36] <pedronis> ijohnson: I think that's fine
[16:36] <ijohnson> pedronis: ok just wanted to make sure before I go much further
[17:14] <pedronis> ijohnson: if we are moving things though maybe we should model -> device/model as well
[17:14] <ijohnson> pedronis: sure that shouldn't be too hard to move
[17:14] <ijohnson> pedronis: this is taking a bit longer to move the keys to ubuntu-boot, because now we need to mount ubuntu-boot in recover mode too
[17:14] <ijohnson> pedronis: and as such I have to update like 13 tests in cmd_initramfs_mounts_test.go for that too :-/
[17:49] <ijohnson> hmm we don't seem to have a spread test that checks for the model file on ubuntu-boot ?
[17:54] <pedronis> ijohnson: it's possible, it was added fairly late toward the first beta
[17:54] <ijohnson> yeah I don't see one, so I am going to add something to basic20 for it
[17:55] <ijohnson> if there is already a check, it's well hidden :-)
[17:55] <ijohnson> and it will fail in spread anyways so I can fix it then
[18:12] <ijohnson> pedronis: I opened https://github.com/snapcore/snapd/pull/9603
[18:12] <mup> PR #9603: many: mv keys to ubuntu-boot, move model file, rename keyring prefix for secboot <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9603>
[18:12] <ijohnson> pedronis: I need to break for lunch now but will check back in when I am back
[18:17] <mup> PR snapd#9603 opened: many: mv keys to ubuntu-boot, move model file, rename keyring prefix for secboot <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9603>
[19:02] <mup> PR snapd#9602 closed: secboot, cmd/snap-bootstrap: enable or disable activation with recovery key <Run nested> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9602>
[19:08] <ijohnson> merge conflict de-conflicted
[19:33] <zyga-mbp> mvo how's the release?
[20:00] <ijohnson> hey zyga-mbp (or zyga ?) the 2.48 release is now very close, which means that uc20 1.0 is very close
[20:00] <zyga-mbp> woot
[20:01] <ijohnson> actually my immediate tasks before EOD are to finish up the last PR's for 2.48
[20:01] <zyga-mbp> I didn't contribute to uc20 much
[20:01] <zyga-mbp> but core20 is a monumental achievement that I'm happy I at least participated in a little
[20:02] <ijohnson> I'm very excited to be able to transition to something new after uc20 is done, who knows perhaps I will pick up some of your work afterwards :-)
[20:03] <zyga-mbp> ijohnson I'm sure you will do a great job, that area needed a fresh pair of eyes
[20:03] <ijohnson> :-)
[20:03]  * ijohnson hugs zyga-mbp 
[20:03] <zyga-mbp> ijohnson speaking of eyes, me checks cnn.com
[20:04] <zyga-mbp> no news yet
[20:04] <ijohnson> yep but we could have a final result by midnight (my TZ) tonight
[20:04] <zyga-mbp> I should get to sleep and check back in the morning
[20:04] <ijohnson> yeah I've stayed up too late the fast few nights to have nothing of large relevance happen for it :-/
[20:06] <zyga-mbp> ijohnson at least we are not drinking ourselves to death
[20:06] <zyga-mbp> I think this will be a good weekend
[20:06]  * ijohnson hopes so too
[20:06] <ijohnson> anyways I should get back to finish these PR's
[20:06] <ijohnson> nice talking to you zyga-mbp !
[20:07] <zyga-mbp> indeed, good luck!
[20:07] <ijohnson> thanks
[20:11] <mvo> zyga-mbp: churning along!
[20:11] <mvo> pedronis: I just applied your feedback for 9539 but no good idea yet about RecoveryKey.String() :/
[20:40] <ijohnson> pedronis: I guess before I go down too far this route, does changing the secboot.Unlock* function(s) to return a UnlockResult{} with info like the method of unlocking, the device path, whether it's a decrypted dev, etc. stuffed in there make sense?
[20:40] <ijohnson> I have this:
[20:40] <ijohnson> https://www.irccloud.com/pastebin/BU4J2FTs/
[20:41] <ijohnson> I was able to finagle the errors returned from snapcore/secboot functions to get the info we need to know the UnlockMethod to set on returning
[20:52] <ijohnson> well I guess I'm almost done I think it's the right thing to do so hopefully I'm not too far off track
[21:13] <mup> PR snapcraft#3357 opened: project schema tests: ensure json format checkers are loaded <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3357>
[22:43] <pedronis> ijohnson: we can look at the details in the PR but it sounds reasonable
[22:43] <ijohnson> pedronis: ack I will propose it then
[22:44] <ijohnson> pedronis: https://github.com/snapcore/snapd/pull/9604
[22:44] <mup> PR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9604>
[22:44] <ijohnson> don't need to review it tonight, it can certainly wait til tomorrow morning too
[22:48] <mup> PR snapd#9604 opened: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9604>