<bgilbert>
frigo: I almost proposed trying to test that changing a PCR value would break the unlock
<bgilbert>
frigo: by creating a data volume instead of using the rootfs, then sealing to PCR 8
<bgilbert>
frigo: but we wouldn't really prove much, since the CoreOS second boot uses different kernel arguments than the first one
gursewak_ has joined #fedora-coreos
<bgilbert>
(I was thinking we'd reboot once to prove that it worked, then change the PCR and reboot again to prove that we broke it)
<bgilbert>
not sure if there's a PCR that we could use in that way
<frigo>
yes, we can use PCR8 for that
<bgilbert>
except we can't first prove that reboot works correctly, right?
<frigo>
since it hashes the cmdline, it breaks after the first reboot (where the firstboot parameter disappears...)
<bgilbert>
right
<bgilbert>
i.e., it's possible that the reboot breaks for unrelated reasons
<frigo>
yeah indeed it's completely broken :D
<bgilbert>
well, the simple test is still an improvement
<frigo>
at least it document a bit the usage of custom bindings (although in practice, it's useless in the current state of the technology...). For data volume we can bind against a PCR, then mount/unmount to prove it works, then run tpm2_pcrextend to change the PCR value, then prove we cannot mount anymore. Maybe that would work
ravanelli has quit [Ping timeout: 276 seconds]
<bgilbert>
frigo: oh yeah, that sounds good
<frigo>
I'm going to take my time. I see multiple failed builds for my pull request. Should I cancel the pull request? to prevent consuming resources uselessly and save the planet
bgilbert has quit [Ping timeout: 272 seconds]
gursewak_ has quit [Ping timeout: 272 seconds]
ravanelli has joined #fedora-coreos
ravanelli has quit [Ping timeout: 268 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
ravanelli has joined #fedora-coreos
ravanelli has quit [Ping timeout: 272 seconds]
plundra has quit [Quit: leaving]
plundra has joined #fedora-coreos
jcajka has joined #fedora-coreos
ravanelli has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanelli has quit [Ping timeout: 276 seconds]
jcajka has quit [Quit: Leaving]
shadowchain has quit [Quit: You have been kicked for being idle]
thempans[m] has quit [Quit: You have been kicked for being idle]
ravanelli has joined #fedora-coreos
ravanelli has quit [Ping timeout: 268 seconds]
bagasse_ has joined #fedora-coreos
bagasse_ has quit [Remote host closed the connection]
<dustymabe>
the problem we saw this morning makes sense now. the multi-arch builders have newer rpm-ostree (rpm-ostree-2022.11-2.fc36.s390x) where the one built and is on quay has the older one (rpm-ostree-2022.10-3.fc36.x86_64) - this PR should fix that: https://github.com/coreos/coreos-assembler/pull/2993
<dustymabe>
I have a semi-related question, though.
<dustymabe>
I want to make sure we don't somehow get our fedora prod ostree repos into a bad state.
<dustymabe>
i.e. if we import one of these new commits into those repos using a newer rpm-ostree/ostree (in our importer container) will other processes in Fedora (like the pungi composes) still be able to access and read/write the repo?
<walters>
we're just changing how we wrap up an ostree commit in a container image
<walters>
the ostree data model and format has not changed
<walters>
IOW, `ostree container unencapsulate` *entirely discards* the container wrapping metadata and just unpacks the underlying ostree data
jpn has quit [Ping timeout: 240 seconds]
<walters>
now there is a separate flow `container store` that *doesn't* discard the container data - and that's what we use client side for upgrades - it's how we avoid re-fetching layers that haven't changed
<walters>
try using e.g. `ostree refs` after rebasing on a container client side (also interesting to do with and without chunking)
<walters>
since we're not setting `deploy_via_container: true`, the disk images we create have no reference or trace of the container
<walters>
but - once we decide to pull the trigger and ship updates via container images, we flip on that flag and the disk images we generate will be "primed" from day 0 to avoid re-pulling container layers that haven't changed
<walters>
now the ostree side has all carefully kept this mostly feature gated - as I said the discontinuity here was flipped on by https://github.com/coreos/coreos-assembler/pull/2970 which we can revert if we want
<dustymabe>
walters: stamped
<dustymabe>
walters: interesting..
<dustymabe>
and it only happens on our rawhide stream because we only set 'oci-chunked' there?
<dustymabe>
i think we should just be able to check the existence of /etc/issue.d/22_clhm_ens6.issue (substitue `ens6` with whatever NIC exists on the system)
saqali_ has joined #fedora-coreos
ravanelli has joined #fedora-coreos
saqali has quit [Ping timeout: 240 seconds]
<aaradhak[m]>
yes dustymabe i can look into writing a test case for that.