zyga | good morning | 06:20 |
---|---|---|
zyga | good morning mborzecki | 06:34 |
mborzecki | zyga: hey | 06:34 |
mborzecki | school run, brb | 07:29 |
mborzecki | re | 07:51 |
mborzecki | mvo: hey | 07:51 |
mvo | good morning mborzecki | 07:55 |
mvo | mborzecki: anything I should review right away? | 07:55 |
mvo | (or do?) | 07:55 |
mup | PR snapd#9597 closed: gadget: correct sfdisk arguments <Created by xnox> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9597> | 07:59 |
mborzecki | mvo: there are some smaller PRs, split out from the degraded mode one that Ian opened | 08:03 |
mvo | mborzecki: yeah, saw them | 08:07 |
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:44 |
mvo | mborzecki: \o/ thank you | 08:47 |
mborzecki | mvo: ok, let's land 9598 and 9599, then update 9560 | 09:04 |
mvo | mborzecki: +1 | 09:05 |
mvo | mborzecki: does it require force merges? I am in a meeting right now | 09:05 |
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:10 |
zyga | good morning mvo | 09:17 |
mvo | good morning zyga - nice to see you | 09:18 |
zyga | :-) | 09:18 |
zyga | good luck with the release | 09:20 |
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> | 09:44 |
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:04 |
mvo | mborzecki: in a meeting still | 10:11 |
mborzecki | mvo: ok, i've restarted the job, i'll merge it if the required tasks are successful | 10:12 |
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:44 |
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:45 |
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:47 |
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:48 |
zyga | so just post /v2/assertion | 10:49 |
zyga | so just post /v2/assertions | 10:49 |
zyga | (sorry, plural) | 10:49 |
ogra | yup .... thanks a lot | 10:53 |
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:02 |
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:24 |
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. | 11:29 |
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:07 |
mup | PR snapcraft#3354 closed: cli: import sort with isort <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3354> | 12:17 |
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:23 |
mborzecki | pedronis: yes, i see your point | 12:37 |
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:39 |
pedronis | but as is it seems we would get stuck asking the recovery key before anything else | 12:40 |
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:42 |
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:45 |
pedronis | yes | 12:46 |
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:47 |
pedronis | zyga: hi :) | 12:48 |
pstolowski | hey | 12:50 |
zyga | hey pawel | 12:50 |
abeato | tobias_, it is unmaintained, that's why it is unlisted | 12:53 |
ogra | and on a sidenote people should really not install it on desktops ... for which the unlisting helps too | 12:54 |
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:56 |
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:57 |
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:58 |
ogra | and the existing one was heavily broken before alfonso fixed it in his heroic effort | 12:59 |
tobias_ | abeato, ogra: Sounds reasonable, thanks for the explanation! | 13:00 |
pedronis | mborzecki: the multi key unlock would do all the top 3 boxes on the right, in one go | 13:02 |
=== mborzeck1 is now known as mborzecki | ||
mborzecki | heh, there's no switch in secboot options to not try the recovery key | 13:13 |
mborzecki | hm but recovery tries can be set to 0 | 13:14 |
mborzecki | ha | 13:14 |
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:24 |
pedronis | ijohnson: fwiw there's also a default timeout of 90s in systemd-ask-password I think | 13:26 |
pedronis | not that I think it makes sense to rely on it for this stage | 13:27 |
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:30 |
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:33 |
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:34 |
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:37 | |
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:40 |
pedronis | mborzecki: ? | 13:41 |
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 :) | 13:43 |
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:03 |
ijohnson | tobias_: ah sorry yeah I didn't see that you had responded, let me take a look at your message now | 14:38 |
* cachio lunch | 14:55 | |
mborzecki | afk for a bit, need to drive the kids around | 15:34 |
mup | PR snapcraft#3356 opened: extensions: correctly spell the GTK_USE_PORTAL variable <Created by seb128> <https://github.com/snapcore/snapcraft/pull/3356> | 16:18 |
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:35 |
pedronis | ijohnson: I think that's fine | 16:36 |
ijohnson | pedronis: ok just wanted to make sure before I go much further | 16:36 |
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:14 |
ijohnson | hmm we don't seem to have a spread test that checks for the model file on ubuntu-boot ? | 17:49 |
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:54 |
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 | 17:55 |
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:12 |
=== ijohnson is now known as ijohnson|lunch | ||
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> | 18:17 |
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:02 |
=== ijohnson|lunch is now known as ijohnson | ||
ijohnson | merge conflict de-conflicted | 19:08 |
=== the-mentor3 is now known as the-mentor | ||
zyga-mbp | mvo how's the release? | 19:33 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:06 |
zyga-mbp | indeed, good luck! | 20:07 |
ijohnson | thanks | 20:07 |
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:11 |
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:40 |
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:41 |
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 | 20:52 |
mup | PR snapcraft#3357 opened: project schema tests: ensure json format checkers are loaded <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3357> | 21:13 |
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:43 |
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:44 |
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> | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!