[00:00] PR snapcraft#3366 opened: tools: split local environment setup from environment-setup.sh [00:00] PR snapcraft#3367 opened: requirements: pin pip to 20.1.1 for devel [02:43] PR snapd#9621 opened: many: address degraded recover mode feedback, cleanups [03:53] anyone know of a snap permission for chromium that one can enable to make PWAs/website shortcuts function properly? [04:15] kinghat: not at present. The current method Chrome uses is to try and install .desktop files in a place where the shell will try and launch them. Without any intermediation, that represents a pretty trivial sandbox escape. [04:47] i was fine with it the way it was before the snap. how do you revert? [05:02] You may be able to get some of the shortcuts working by copying desktop files from ~/snap/chromium/current/.local/share/applications (I think) to ~/.local/share/applications. I'm not sure if you'd need to fix up the Exec= line or not [05:14] PR snapd#9540 closed: snap: add new `snap recovery --show-keys` option

[05:19] PR snapd#9619 closed: cmd/snap-bootstrap,o/devicestate: use a secret to pair data and save [05:19] PR snapd#9620 closed: spread.yaml: increase number of workers on 20.10 [08:10] PR snapd#9622 opened: vendor: update to current secboot [09:27] PR snapcraft#3361 closed: extensions: use SNAP_COMMON instead of SNAP_DATA for fonts [09:27] PR snapcraft#3366 closed: tools: split local environment setup from environment-setup.sh [11:10] PR snapd#9622 closed: vendor: update to current secboot [11:13] mvo: I reviewed #9621, there's a small consistency problem afaict [11:13] PR #9621: many: address degraded recover mode feedback, cleanups [11:16] mvo: I can look into it after lunch [11:21] Does the order inside a uc20 model definition's snaps header define the installation order? (I have multiple snaps that plug network-manager, and judging from the serial console output, nm is installed last if declared last in the array. That is not mentioned in the docs) [11:31] pedronis: thank you [11:32] dot-tobias, the order used to rule it in UC16-18 so i'd expect the same in UC20, put NM before the snaps using it in the list [11:34] dot-tobias, if the app snaps are fully under your control and are services you can also follow what i just wrote here: https://forum.snapcraft.io/t/how-to-set-the-boot-order-for-snaps-after-reboot/13837/9 [11:34] (simply make them come up with disabled services and use hooks and "snapctl is-connected" to start the service when the interface is connected) [11:35] s/is/is getting/ [11:50] dot-tobias: yes, for app snaps, the required-snaps/snaps order is the installation order [12:04] ogra, pedronis: Thanks, booting an image with modified model atm, will see if that resolves the issue. Weird that there was no error during seed, was watching the serial console output and all hooks ran, or at least I didn't see an error … afterwards I was dropped to a login prompt (disabled console-conf), but the system-user assertion doesn't seem to be picked up. [12:06] well i generally use the hooks solution, that way you simply are not depending on the seed ordering and even if seeding of one snap fails it wont cause an avalanche of failure 😉 [12:11] PR snapd#9623 opened: tests: set the opensuse tumbleweed system as manual in spread.yaml [12:12] ogra: It's less a service startup problem than it is an interface/install hook issue – and I can't defer those afaik 😅 In my snap, these hooks attempt to create network-manager connections, so I guess the nm snap needs to be … installed? 😄 I've added a similar solution with `snapctl is-connected` to work around the issue that interface hooks run before the install hook when booting a custom image, but I can't really check either [12:12] since my attempts to create a local user all fail 🙈 [12:15] you can always have a while/d👋sleep loop in your interface hooks ... for debugging your last resort is always cloud-init ... that should work for creating a user, even in UC20 [12:15] (silly emoji plugin) ... "while,do,sleep" [12:16] PR snapd#9624 opened: secboot: call BlockPCRProtectionPolicies even if the TPM is disabled [12:17] dot-tobias, a cloud-init.conf i have used before (note the ssh key is moot) https://paste.ubuntu.com/p/jMVGrg5Cfm/ [12:20] (i guess for UC20 the console-conf hack at the bottom wont work, rip that out) [12:20] ogra: I meant that such a loop wouldn't let the hook finish, as they're run sequentially – so the “thing to wait for” would never happen if the respective snap wasn't installed before? Or am I missing something and things are run in parallel? [12:20] oh, right [12:20] no, you are correct, that would just hang the hook forever [12:21] ogra: Phew 😄 [12:23] https://forum.snapcraft.io/t/remote-logging-on-ubuntu-core/14621 might also be an option (just seeding logsync-james, define the config in your gadget and receive the logs on a central machine running logsync-receiver), that way you'D get the logs but dont need a user [12:23] it is definitely more effort than just using cloud-init and a user though [12:24] and indeed it requires a working network ... [12:25] ogra: Nice to know this setup, thanks! But the user account is intended for users to be able to SSH on their device (the resulting, pre-booted image is intended as a download to flash to your own device) [12:26] sure, i didnt mean to use it permanently but for debugging [12:26] ogra: That cloud.conf looks almost identical to mine, except you use “plain_text_passwd” whereas I pass an encrypted PW. Which was working fine in a core18 model, but then again that cloud.conf was passed directly to ubuntu-image … Ian suggested that this is most likely due to a seed failure (then cloud-init won't run at all) - btw huge thanks ijohnson, very much appreciated! [12:27] ogra: Ah, gotcha. [12:27] it's like 99% working but I can't figure out the last % 🙃 [12:30] heh ... well, the ordering should surely help [12:31] ogra: To be sure: To get a system-user via USB stick, I'd put the `auto-import.assert` from make-system-user on a thumb drive (FAT formatted?), plug that into the RasPi and then start up the freshly flashed image? When would snapd (?) pick up the assertion? [12:34] uh, i dont know when exactly it does that ... also, the USB key doesnt need to be plugged in before boot, there is a udev rule that will handle it at any point in time when you plug it in [12:35] it should tell you about importing the assertion in the logs though [12:44] ogra: Re-plugging worked! I was able to log in, just to find out that all non-auto-connected interfaces weren't connected at all 🙃 So something must be wrong with my gadget, but I don't understand why … especially since the serial console showed me “connecting snap:xyz to slot-snap:xyz` … [12:46] snap changes ... [12:47] should have details [12:47] … checked that, only shows “initialize device“ errors. [12:47] (which is expected since I don't have a serial vault yet) [12:48] correction: gadget connections for wpe-webkit-mir-kiosk *are* applied, so it's only for one snap where the gadget connections are not applied [12:48] wrong snap id or typo ? [12:48] you can work around the initialize device errors btw [12:50] I sense a very dumb error on my side … to check if Ian's suggestion with is-connected in the install/interface hook works (to enable connection creation for both scenarios, manual snap install and gadget seed), I modified the downloaded snap to save some time + passed it via --snap. Which is of course not signed, so the defaults aren't applied as they pertain to the snap's store ID … [12:50] "serial-authority": [ "generic" ], [12:50] add that to your model ... [12:51] then the initialize device errors go away [12:51] ogra: Cool! Is that documented anywhere 😄 [12:51] not sure 🙂 [12:53] (probably not though) [12:54] mvo: we have a real issue with snap-bootstrap, that was hidden because the tests were mocking too much [12:56] degville, "serial-authority": [ "generic" ] should probably documented in the model assertion documentation somewhere (makes the device receive a generic assertion so it does not fail the "initialize device" setp) [12:57] ogra: thanks for letting me know. I'll make sure it's added. [12:57] thanks ! [12:59] degville: On that point, I opened a PR for the core20 docs https://github.com/canonical-web-and-design/ubuntu-core-docs/pull/126 → not sure if somebody was notified 😊 [12:59] PR canonical-web-and-design/ubuntu-core-docs#126: Correct error in `snaps` header docs for uc20 [12:59] (or feel free to close if I misunderstood the docs) [13:00] dot-tobias: thanks for letting me know. I must have missed it, but that's definitely the right place. I'll merge and rebuild. [13:06] degville: Thanks! Please do review if the change makes sense 😊 Discovered that by trial and error during my model assertion upgrade. [13:08] dot-tobias: will do - thank you! [13:39] pedronis: oh no, do you have more details? why did we not notice during the spread tests? [13:39] mvo: it's about the fallback paths [13:40] we don't have spread tests for those [13:40] mvo: I don't know if you want to chat before the standup? [13:40] pedronis: oh, ok [13:40] pedronis: yeah, let me make a cup of tea, then I can join [13:42] bit of a mess [13:48] mvo: I'm in the SU [13:48] pedronis: should I join too ? [13:48] * ijohnson just got here [13:49] ijohnson: yes [13:49] k [14:24] pedronis: do you want to just push up the change you were making somewhere for me to look over? [14:25] ijohnson: yes, but probably once I have all the tests changed [14:25] ok [14:25] atm I have 2 failing tests and new failing test (no data at all) [14:25] right [14:25] we might need one or more tests [14:25] that I are not a blocker for me to push though [14:27] PR snapcraft#3368 opened: ci: use github actions for cla check [14:28] Can someone confirm https://bugs.launchpad.net/snapcraft/+bug/1898877 , or am I just “holding things wrong”? [14:28] Bug #1898877: [remote-build] source-type 'zip' aborts with KeyError [14:30] cjp256: ^ [14:41] PR snapd#9625 opened: snap: add new "fde-setup" hooktype [14:43] ijohnson: https://github.com/pedronis/snappy/commit/18012b6ad1c035611b7a2833090daab5b882f97c there I get 3 failures in cmd/snap-bootstrap [14:43] pedronis: thanks let me have a look [14:45] ijohnson: taking a break, we can chat afterward if needed [14:45] sounds good [14:55] dot-tobias: confirmed, we'd need to enable zip support for osx which shouldn't be a problem [14:55] i can put up a PR if you'll give it a test :D [14:56] * cachio lunch [15:01] cjp256: Thanks! 😊 [15:02] PR snapd#9626 opened: snap-bootstrap,secboot: call BlockPCRProtectionPolicies in all boot modes [15:03] ijohnson: I'm back [15:03] pedronis: ok, I'm working on adjusting secboot to have a DecryptedDevice and using it from initramfs-mounts [15:10] ijohnson: mvo: we have also Chris' PRs to take into account [15:10] pedronis: yes I think that should be fairly easy to accomodate though, at least the one I saw this morning [15:10] it is fairly orthogonal to this work I think [15:11] ijohnson: #9626 touches secboot quite a bit [15:11] PR #9626: snap-bootstrap,secboot: call BlockPCRProtectionPolicies in all boot modes [15:11] anyway I need to review them next [15:11] oh I didn't see that one, I only saw 9624 [15:12] mmm that one is going to be a bit difficult to work with :-/ [15:13] PR snapcraft#3369 opened: sources: enable 7z, bzr, hg, svn, zip for non-linux [15:13] dot-toabis: https://github.com/snapcore/snapcraft/pull/3369 given the speed of travis lately, maybe we'll have a build to test by tomorrow :D [15:13] PR snapcraft#3369: sources: enable 7z, bzr, hg, svn, zip for non-linux [15:21] pedronis: the issue with at least one of the tests (TestInitramfsMountsRecoverModeEncryptedDegradedNoDataFoundSaveHappy) is that the wrong disk setup is being mocked, the disk we get from the ubuntu-seed mountpoint still has data in it [15:22] ijohnson: that test is not complete, it will still fail [15:22] yes I know [15:22] just thought I would share that in case you hadn't already figured that bit out [15:22] anyways I'm fixing it all now === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [15:39] * ijohnson is very grateful for writing all the consistency checks on the unlockRes :-) [15:44] mvo: I updated 9626 [15:46] pedronis: do you have opinions on storing the decrypted device as "decrypted-device" inside degraded.json partitions [15:46] ? [15:46] that's what I've code and is working well I think [15:46] ijohnson: I'm not sure, we should discuss [15:46] pedronis: SU ? [15:46] yes [15:47] pedronis: ok, actually give me a minute I can push my changes up to a branch and we can review together [15:47] pedronis: thanks, I have a look [15:48] pedronis: https://github.com/anonymouse64/snapd/tree/bugfix/uc20-consistent-unlock-result-and-consequences-2 [15:48] pedronis: joining SU now [16:11] @ijohnson, hey, do you know if there has been any recent change in UC20 for auto imports? I use to drop a system-user assertion in the ubuntu-seed partition to get a user after first boot (so I could run tests automtaically), but it looks like it is not working anymore [16:12] abeato: yes support for that was dropped [16:12] ijohnson, ouch... what would be the alternative? [16:17] PR snapd#9624 closed: secboot: call BlockPCRProtectionPolicies even if the TPM is disabled [16:17] abeato: use console-conf in your gadget snap [16:18] sorry cloud-init [16:20] ijohnson, ok, is there any example around? [16:30] * cachio -> kinesiologist [16:41] abeato: so you put a file in the root of your gadget snap called cloud.conf, and put content like this in it: [16:42] https://pastebin.ubuntu.com/p/mNCz53qjQr/ [16:43] ijohnson, I see, thanks a lot! [16:43] np === asottile is now known as albertosottile [16:43] ijohnson, "# #cloud-config", is that right? [16:43] abeato: haha no it's not sorry [16:43] it should be just [16:44] :) [16:44] ``` [16:44] # cloud-config [16:44] ``` [16:44] ok [16:44] actually I don't remember how intelligent the cloud-init parser is in reading the first line and comment for that file [16:44] maybe it still works with the space there or without the space there [16:45] I think it prefers without the space, but not 100% sure [16:52] * ogra wonders if ijohnson has heard of the "plain_text_passwd:" key of cloud-init ... 🙂 [16:52] that would be too easy [16:52] saves all the crypting [16:53] yeah that seems way easier! [17:05] mvo: ijohnson: #9626 needs reviews (I fixed it and added more tests) [17:05] PR #9626: snap-bootstrap,secboot: call BlockPCRProtectionPolicies in all boot modes [17:05] pedronis: ack, I'm still fixing up the branch from this morning with the new degraded state things [17:05] pedronis: it's going ok, a bit fiddly and tedious but no complications thus far [17:07] pedronis: will do after dinner [17:12] ijohnson: hopefully, not too fiddly, let me know if it's getting too messy [17:13] yeah I think it's ok, hopefully will be done with the right code soonish and then just need to update all the tests [17:13] ijohnson: the tests shouldn't need much updating I think [17:13] ijohnson: just the helpers [17:13] yes hopefully [17:47] PR snapd#9627 opened: interfaces/raw_usb: allow read access to /proc/tty/drivers (LP: #1890365) [18:06] pedronis: ok, I've got basically what I think is needed, one thing I didn't realize while implementing but I now remember is that you mentioned you wanted the internal "raw decrypted device" to be unset if we found the encrypted device but couldn't unlock it, is that correct ? [18:07] pedronis: because what I accidentally ended up implementing is that the raw decrypted device setting is now the block device if we can't unlock it [18:07] I can fix it to be what we agreed upon, just wanted to make sure that I should fix it that way [18:10] ijohnson: yea, that sounds not we agreed [18:10] sorry, I'll fix it then [18:10] not what we agreed [18:10] ijohnson: but maybe it's easier to push what you have [18:11] pedronis: sure, should I open a PR or just send you the branch ? [18:11] ijohnson: it shouldn't make a big difference, it still seems the right thing [18:11] ijohnson: I'm also confused because I'm not sure why you are calling it "raw" [18:11] eh just the var name I used in the code since it's not the "exported" one [18:11] I have no personal attachment to the word "raw" here [18:11] mmh [18:12] ijohnson: well if it's almost PR ready, let's make a PR, you mark it draft [18:12] just didn't want to spend brain cycles on a better word yet [18:12] it is PR ready I have added the new tests we discussed and updated all the tests [18:12] I'll mark it as a draft then [18:12] one moment [18:18] PR snapd#9628 opened: secboot,cmd/snap-bootstrap: fix degraded mode cases with better device handling [18:18] pedronis: ^ [18:21] whoops had a gofmt typo, just force pushed === ijohnson is now known as ijohnson|lunch [18:23] PR snapcraft#3370 opened: repo: address issue with fix_symlink() when pointed at directory [18:42] pedronis: I updated the fde hooks gdoc fwiw [18:42] ijohnson|lunch: thanks for 9628! [18:53] ijohnson|lunch: a bunch of comments in #9628, sadly it looks messier than the old code :/ so it's quite hard to review [18:53] PR #9628: secboot,cmd/snap-bootstrap: fix degraded mode cases with better device handling === ijohnson|lunch is now known as ijohnson [19:12] pedronis: well that's unfortunate [19:17] ijohnson: please look at my comment, and let me know if you have questions, I can be around a bit more [19:17] yes I'm reading through them now [19:31] ijohnson: ah, there is something off in secboot itself, that's why maybe things are confusing for me [19:31] what's off in secboot ? [19:32] ijohnson: tbh this is probably simpler with chris PR [19:32] ijohnson: if you have a purely uncrypted device you don't set DecryptedDevice [19:32] ... does that not make sense though ? [19:33] ijohnson: that's what we dicussed [19:33] sorry I guess I missed that then [19:33] well, it simplifies code quite a bit [19:33] but as I said it's probably easier with chris PR then now [19:33] it just doesn't make sense to me to be setting DecryptedDevice for something that erm well isn't a decrypted device ? [19:34] if that's what is desired I think we should rename it from DecryptedDevice to something more generic like ActivatedDevice or TargetDevice or something [19:36] ijohnson: sorry, I thought I explained this, we can argue on the name (it's internal anyway) [19:37] I guess I only understood you to mean to set the block device on the degraded state and not on the secboot return result [19:37] anyways I'm looking at 9626 now [19:37] ijohnson: my point is that it's always correct to mount DecryptedDevice if set [19:38] sure I guess in this case we should just rename it to something else then [19:39] I wonder if we should also rename Device to BlockDevice [19:40] ijohnson: maybe FsDevice or FilesystemDevice [19:41] those seem fine to me [19:42] yeah I see why this is simpler with Chris' PR [19:42] pedronis: shall I finish a review of that so we can merge that first then I'll rebase my PR as we just discussed on top of that ? [19:43] * ijohnson just does a review anyways [19:43] PR snapd#9606 closed: tests: Use systemd-run on tests part2 [19:43] PR snapd#9623 closed: tests: set the opensuse tumbleweed system as manual in spread.yaml [19:43] ijohnson: we should also land #9621 [19:43] PR #9621: many: address degraded recover mode feedback, cleanups [19:43] I guess 9621 isn't more wrong than the current state of things [19:44] ijohnson: yea, my bit your new PR contains addresses my comment there [19:44] ijohnson: I'm landing it [19:44] ok [19:45] ijohnson: I wonder how mvo plans to backport these though [19:45] perhaps we should squash merge then [19:46] or maybe he needs to just merge master back, not sure [19:46] I fear it's going to be messy either way [19:46] hmm does my pr conflict with 9626 ? [19:46] I suspect so [19:47] err sorry [19:47] does 9621 conflict with 9626 ? [19:48] maybe, not massively though [19:49] ijohnson: I can deal with that [19:49] I'm just wondering if we could land chris' pr first, maybe squash maybe not, then I could force-push a rebase of my pr on top of master so it is not conflicting [19:49] I mean, landing 9626 [19:50] I'm almost done with a review, it looks good to me, I think it needs more tests, but probably fine to do in a follow-up [19:50] ijohnson: mmh, I added quite a few tests [19:51] I guess not so much new tests, I just think the specific tests added are a little weird, I think other tests would make more sense [19:51] anyways just a minute and I will submit my review [19:51] ijohnson: maybe [19:53] PR snapd#9621 closed: many: address degraded recover mode feedback, cleanups [19:59] ijohnson: anyway it does conflict so I'll have to sort that [20:00] pedronis: mmm, well I submitted my review now [20:01] I will rebase my newer pr on top of chris' pr locally then and wait to push anything more until that has landed [20:02] ijohnson: TestInitramfsMountsRunModeHappy still exists afaik [20:02] it does ? [20:02] where ? [20:02] ah [20:02] no [20:03] it became TestInitramfsMountsRunModeHappy [20:03] you are right [20:04] I was almost doubly confused about it disappearing and then reappearing right before my eyes! [20:07] heh, anyway I probably can fix your 2nd point [20:08] first I need deal with the conflicts [20:16] ijohnson: actually 9626 is a bit buggy [20:16] pedronis: how so? [20:17] in the secboot code ? [20:17] it sets res.Device too eagerly [20:17] at least it's a change of behavior [20:18] yeah I noticed that but I think it's fine though given that we will be rewriting that code immediately after in my PR to use i.e. FsDevice or whatever [20:19] well, it's a change of behavior [20:19] it's more likely to confuse you than anything [20:19] well to be fair I am easily confused so that's not saying much :-) [20:20] sorry, that was a generic you [20:20] it's also interesting that no test fails :/ [20:21] either way [20:21] I'm starting to get highly suspicious of the tests around UnlockVolumeUsingSealedKeyIfEncrypted [20:21] I don't think the tests around that are really testing all the cases [20:22] it's testing a lot of cases, but I don't think it's testing the right things [20:24] I added something to tests that would have failed [20:28] ijohnson: pushed [20:28] ack I'll have a look [20:29] ijohnson: the diff of the merge is readable [20:31] I forgot to add the extra tests though [20:31] which extra tests ? [20:32] the install/recover ones? I don't think those are needed for htis pr, they can be followsup imho [20:32] followups [20:34] ijohnson: actually all the NoModel tests share code, so it's very easy to add [20:34] nice [20:35] pushed [20:38] ijohnson: anything more that I can help with? [20:39] pedronis: if you have thoughts on what to name the *Device things on secboot.UnlockResult so that it's not quite so confusing I would appreciate input on that [20:41] ijohnson: Part(ion)Device and FsDevice ? [20:42] so PartDevice will always be the partuuid one, and FsDevice will be the one that's always safe to mount? [20:42] yes [20:42] got it, that sounds fine then [20:43] It will probably be an hour or two before I can finish that and push it up [20:43] so for the encrypted case they are the same [20:43] you mean the unencrypted case they are the same ? [20:43] sorry, unencrypted case [20:43] right [20:47]