Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it easier to figure out which package, template, or ISO contains a specific bug fix (so it's easier to test specific bug fixes) #8449

Open
tlaurion opened this issue Aug 26, 2023 · 1 comment
Labels
C: infrastructure C: tests P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.

Comments

@tlaurion
Copy link
Contributor

tlaurion commented Aug 26, 2023

Does this problem impact anyone whose ISO includes QubesOS/qubes-core-agent-linux#437?

Probably no, but nobody tried because such ISO does not exist (yet). Fedora templates (until yesterday) were built before the fix was pushed, so any ISO did not include it. That's the whole confusion @tlaurion is talking about.
I think the simple improvement to the process would be to build templates more often (every week? every two weeks?).

@marmarek I would really love to see

  • issues tagged for "installer issue"
  • pr fixing the issue being trackable in built package (downloadable as testing package from repo) commenting/referencing back to issue
  • templates including fixed packages being built commenting/referencing back to issue
  • iso being built with updated templates commenting/referencing back to issue

Sorry for my walls of text @andrewdavidwong but if we want to test fixes, we need to know which package version includes the fix, we need to know which template version includes the fixed packages and we need to know which ISO includes which fixed templates includes which fixed packages.

Even more for fixes correcting installer past related bad assumptions (salts, dom0, pools, LUKS, LVM, filesystem creation, block/sector assumptions etc etc etc)


Some history unrelated to this issue backing up my "meta" analysis (I was first line of support for customers at that time, let's remember this):

  • q4.0 changed pool config of TLVM, separating dom0 from VM pools. That required a reinstallation
  • randomization of mac addresses required a reinstallation of template/sys-net servicevm, otherwise testers don't know, issues were opened, documentation was off and still today there is confusion on what needs to be done to anonymize properly
  • q4.0 upgrade script attempted to deal with pool changes giving warning, but users thought it would work out of the box where reinstallation was really the only solution.
  • LUKs v2 happened between 3.2 and 4.0. This is an important "installer" change that created a lot of rockus and confusion, and changes needed under Heads as well, requiring firmware upgrade which qubes certification guidelines prohibited at that time (same firmware version support for X period of time... Where cryptsetup in firmware needed to be upgraded....)
  • down to drive TRIM, LUKs discards, LVM discards, VM fs discard. Heads applying discard on crypttab file generation injected in secret.cpio to do apply disk unlock key from TPM unsealed disk encryption key passphrase.

Nothing "installer" related problems can easily fix those issues but to backup/reinstall/restore.

Some thoughts.

Installer "tag" should encompass:

  • pool creation changes
  • filesystem creation assumption changes
  • templates upgrade for networking
  • dom0 changes in filesystem management
  • dom0 tooling affecting filesystem optimizations
  • anything else that cannot effectively be retroactively fixed
  • installer issues to be bootable by iso
  • installer issue to be installable on iso origin drive but different partition (optimal tester scenario)

Other examples

A recent bug report to NixOS made them realize that LUKs unlocking was insecure on legacy firmware and that unlocking secret was stored unencrypted on /boot.... Reencrypting LUKS online was an option. Reinstalling is the solution.

Pool change seperation of q4.0 required a reinstall. Upgrade scripts lowered security. Let's remember that LUKS1 was effective prior or that. Reencrypting is possible to upgrade to LUKS2 but far from being recommended. users should reinstall in all case (otherwise unclear why they use Quebesos for insecure use case)


Tldr: an installer issue tag made available globally would track reinstallation requirements and track needed testing more efficiently.

Originally posted by @tlaurion in #8242 (comment)

@tlaurion tlaurion changed the title > > Does this problem impact anyone whose ISO includes [QubesOS/qubes-core-agent-linux#437](https://github.com/QubesOS/qubes-core-agent-linux/pull/437)? Track installer bugs and needed packages (templates versions including needed packages) Aug 26, 2023
@tlaurion tlaurion changed the title Track installer bugs and needed packages (templates versions including needed packages) Track installer related bugs and needed packages (templates versions including needed packages) Aug 26, 2023
@andrewdavidwong
Copy link
Member

andrewdavidwong commented Aug 27, 2023

issues tagged for "installer issue"

Already exists: C: installer

if we want to test fixes, we need to know which package version includes the fix

Makes sense, but don't we already have that in the form of updates-status issues and the automated qubes-bot comments on issues?

we need to know which template version includes the fixed packages and we need to know which ISO includes which fixed templates includes which fixed packages.

These parts also make sense. Not sure if they're already tracked anywhere.

Installer "tag" should encompass:

pool creation changes
filesystem creation assumption changes
templates upgrade for networking
dom0 changes in filesystem management
dom0 tooling affecting filesystem optimizations
anything else that cannot effectively be retroactively fixed
installer issues to be bootable by iso
installer issue to be installable on iso origin drive but different partition (optimal tester scenario)

Well, that seems like overloading the C: installer label to me. We already have other labels for most or all of those other components.

Maybe what you want isn't a component (C:) label after all, then. I guess what you really want is something more like a label that means "applying this label should trigger a rebuild of the installer for testing," and not "this issue affects the installer in some way" (which is what C: installer means).

@andrewdavidwong andrewdavidwong added T: enhancement C: tests P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. C: infrastructure labels Aug 27, 2023
@andrewdavidwong andrewdavidwong changed the title Track installer related bugs and needed packages (templates versions including needed packages) Make it easier to figure out which package, template, or ISO contains a specific bug fix (so it's easier to test specific bug fixes) Aug 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: infrastructure C: tests P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.
Projects
None yet
Development

No branches or pull requests

2 participants