/srv/irclogs.ubuntu.com/2020/11/05/#snappy.txt

zygagood morning06:20
zygagood morning mborzecki06:34
mborzeckizyga: hey06:34
mborzeckischool run, brb07:29
mborzeckire07:51
mborzeckimvo: hey07:51
mvogood morning mborzecki07:55
mvomborzecki: anything I should review right away?07:55
mvo(or do?)07:55
mupPR snapd#9597 closed: gadget: correct sfdisk arguments <Created by xnox> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9597>07:59
mborzeckimvo: there are some smaller PRs, split out from the degraded mode one that Ian opened08:03
mvomborzecki: yeah, saw them08:07
mborzeckimvo: applied your suggestion in https://github.com/snapcore/snapd/pull/959808:44
mupPR #9598: secboot: add LockTPMSealedKeys() to lock access to keys independently <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9598>08:44
mvomborzecki: \o/ thank you08:47
mborzeckimvo: ok, let's land 9598 and 9599, then update 956009:04
mvomborzecki: +109:05
mvomborzecki: does it require force merges? I am in a meeting right now09:05
mborzeckimvo: i pushed a commit to each so we need to wait for runs to complete and maybe force merge after that09:10
mvomborzecki: ta!09:10
zygagood morning mvo09:17
mvogood morning zyga - nice to see you09:18
zyga:-)09:18
zygagood luck with the release09:20
mborzeckimvo: can you merge https://github.com/snapcore/snapd/pull/9599 ?09:44
mupPR #9599: secboot: refactor Unlock...IfEncrypted to take keyfile + check disks first <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9599>09:44
mupPR 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
mvomborzecki: in a meeting still10:11
mborzeckimvo: ok, i've restarted the job, i'll merge it if the required tasks are successful10:12
mupPR 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
ograis 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
zygaogra, yes10:47
ograthx !10:47
zygaogra, both are just API calls10:47
zygaone is the assertion10:47
zygaand the other local file post for install10:47
ograyeah, i thought so ... a customer was asking because he couldnt find an actual "snap ack" in the API docs10:48
zygaI think it's this endpoint ...10:48
zygahttps://github.com/snapcore/snapd/blob/master/daemon/api_asserts.go#L4010:48
zygaso just post /v2/assertion10:49
zygaso just post /v2/assertions10:49
zyga(sorry, plural)10:49
ograyup .... thanks a lot10:53
mborzeckimvo: #9600 is updated, it's still 1k+ lines added though11:02
mupPR #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
xnoxlet me try uc22 image again with new snapd from edge11:24
xnoxcause then, i think i might be able to start building those regularly; and/or like remodel from uc20 to uc2211: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
mupPR snapcraft#3351 closed: storeapi: import sort with isort <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3351>12:07
mupPR snapcraft#3353 closed: tools: import sort with isort <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3353>12:07
mupPR snapcraft#3354 closed: cli: import sort with isort <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3354>12:17
pedronismvo: 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
mupPR #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
mborzeckipedronis: yes, i see your point12:37
pedronismborzecki: there's probably a way to do this this way by stopping asking for the recovery key and then doing it ourselves I suppose12:39
mborzeckipedronis: so in this case, should recovery key be tried after fallback data key fails?12:39
pedronisthat's the default secboot behavior12:39
pedroniswe have options I suppose12:39
pedronisbut as is it seems we would get stuck asking the recovery key before anything else12:40
mborzeckipedronis: 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
pedronisno, there's also a recovery key for save only12:42
pedronis(called the reinstall.key)12:42
mborzeckipedronis: 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
pedronisyes12:46
pedronisit might also be the only recovery key we ask if/when we had a clear re-install mode12:47
zygahey pedronis12:47
zygawelcome back12:47
pedroniszyga: hi :)12:48
pstolowskihey12:50
zygahey pawel12:50
abeatotobias_, it is unmaintained, that's why it is unlisted12:53
ograand on a sidenote people should really not install it on desktops ... for which the unlisting helps too12:54
pedronismborzecki: 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 returns12:56
pedronis(which I think is something I mentioned last week)12:57
mborzeckipedronis: 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
ograheh12:58
pedronismborzecki: yes, it looks reasonable12:58
abeatotobias_, 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 need12:58
abeatos/why/we/12:58
ograand the existing one was heavily broken before alfonso fixed it in his heroic effort12:59
tobias_abeato, ogra: Sounds reasonable, thanks for the explanation!13:00
pedronismborzecki: the multi key unlock would do all the top 3 boxes on the right, in one go13:02
=== mborzeck1 is now known as mborzecki
mborzeckiheh, there's no switch in secboot options to not try the recovery key13:13
mborzeckihm but recovery tries can be set to 013:14
mborzeckiha13:14
ijohnsonin 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 initramfs13:24
pedronisijohnson: fwiw there's also a default timeout of 90s in systemd-ask-password I think13:26
pedronisnot that I think it makes sense to rely on it for this stage13:27
ijohnsonyes we were talking about the timeout there but couldn't remember what it was13:30
ijohnsonwelcome back btw13:30
pedronisthx13:30
ijohnsonis 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 SU13:33
mborzeckiijohnson: i'm adding a switcht to eanble/disable recovery key in unlocking the volumes13:34
ijohnsonok, 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
mborzeckiyes13:34
ijohnsonI sent an invite, maybe we don't need the meeting and can just talk during SU13:37
* ijohnson gets back to eating13:37
mborzeckipedronis: ijohnson: https://github.com/snapcore/snapd/pull/960213:40
mupPR #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
mupPR 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
mborzeckiand then 9600 should disable recovery key completely (?)13:40
pedronismborzecki: ?13:41
mborzeckipedronis: i mean in the code path that calls UnlockVolumeUsingSealedKeyIfEncrypted for recovery and do it in an explicit step13:43
pedronismborzecki: ah, yes, explicit step13:43
pedronisyour 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
ijohnsontobias_: ah sorry yeah I didn't see that you had responded, let me take a look at your message now14:38
* cachio lunch14:55
mborzeckiafk for a bit, need to drive the kids around15:34
mupPR snapcraft#3356 opened: extensions: correctly spell the GTK_USE_PORTAL variable <Created by seb128> <https://github.com/snapcore/snapcraft/pull/3356>16:18
ijohnsonpedronis: 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
ijohnsonpedronis: 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-boot16:35
pedronisijohnson: I think that's fine16:36
ijohnsonpedronis: ok just wanted to make sure before I go much further16:36
pedronisijohnson: if we are moving things though maybe we should model -> device/model as well17:14
ijohnsonpedronis: sure that shouldn't be too hard to move17:14
ijohnsonpedronis: this is taking a bit longer to move the keys to ubuntu-boot, because now we need to mount ubuntu-boot in recover mode too17:14
ijohnsonpedronis: and as such I have to update like 13 tests in cmd_initramfs_mounts_test.go for that too :-/17:14
ijohnsonhmm we don't seem to have a spread test that checks for the model file on ubuntu-boot ?17:49
pedronisijohnson: it's possible, it was added fairly late toward the first beta17:54
ijohnsonyeah I don't see one, so I am going to add something to basic20 for it17:54
ijohnsonif there is already a check, it's well hidden :-)17:55
ijohnsonand it will fail in spread anyways so I can fix it then17:55
ijohnsonpedronis: I opened https://github.com/snapcore/snapd/pull/960318:12
mupPR #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
ijohnsonpedronis: I need to break for lunch now but will check back in when I am back18:12
=== ijohnson is now known as ijohnson|lunch
mupPR 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
mupPR 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
ijohnsonmerge conflict de-conflicted19:08
=== the-mentor3 is now known as the-mentor
zyga-mbpmvo how's the release?19:33
ijohnsonhey zyga-mbp (or zyga ?) the 2.48 release is now very close, which means that uc20 1.0 is very close20:00
zyga-mbpwoot20:00
ijohnsonactually my immediate tasks before EOD are to finish up the last PR's for 2.4820:01
zyga-mbpI didn't contribute to uc20 much20:01
zyga-mbpbut core20 is a monumental achievement that I'm happy I at least participated in a little20:01
ijohnsonI'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-mbpijohnson I'm sure you will do a great job, that area needed a fresh pair of eyes20:03
ijohnson:-)20:03
* ijohnson hugs zyga-mbp 20:03
zyga-mbpijohnson speaking of eyes, me checks cnn.com20:03
zyga-mbpno news yet20:04
ijohnsonyep but we could have a final result by midnight (my TZ) tonight20:04
zyga-mbpI should get to sleep and check back in the morning20:04
ijohnsonyeah I've stayed up too late the fast few nights to have nothing of large relevance happen for it :-/20:04
zyga-mbpijohnson at least we are not drinking ourselves to death20:06
zyga-mbpI think this will be a good weekend20:06
* ijohnson hopes so too20:06
ijohnsonanyways I should get back to finish these PR's20:06
ijohnsonnice talking to you zyga-mbp !20:06
zyga-mbpindeed, good luck!20:07
ijohnsonthanks20:07
mvozyga-mbp: churning along!20:11
mvopedronis: I just applied your feedback for 9539 but no good idea yet about RecoveryKey.String() :/20:11
ijohnsonpedronis: 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
ijohnsonI have this:20:40
ijohnsonhttps://www.irccloud.com/pastebin/BU4J2FTs/20:40
ijohnsonI was able to finagle the errors returned from snapcore/secboot functions to get the info we need to know the UnlockMethod to set on returning20:41
ijohnsonwell I guess I'm almost done I think it's the right thing to do so hopefully I'm not too far off track20:52
mupPR snapcraft#3357 opened: project schema tests: ensure json format checkers are loaded <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3357>21:13
pedronisijohnson: we can look at the details in the PR but it sounds reasonable22:43
ijohnsonpedronis: ack I will propose it then22:43
ijohnsonpedronis: https://github.com/snapcore/snapd/pull/960422:44
mupPR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9604>22:44
ijohnsondon't need to review it tonight, it can certainly wait til tomorrow morning too22:44
mupPR 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!