chore: Synchronize fips with master by github-actions[bot] · Pull Request #17773 · canonical/snapd

github-actions · 2026-10-05T14:02:41Z

Synchronize fips with master, using snapcraft-fips.yaml from master as snapcraft.yaml. Merge using "Create a merge commit".

* many: add system snapd startup security logging Emit a SYS sys_startup_snapd event from Daemon.Start after READY=1 on a normal startup, with this process's version and the kernel boot id. * cmd/snapd/daemon: move startup logging right after enable * tests/main/security-logging: add spread coverage * cmd/snapd/daemon: moved security logging setup after orgon2 hijack * cmd/snapd/daemon: clarify comment about boot id error not preventing logging * daemon: clarify why preseed deamon stop event is not logged

* github: use download action instead of api to download prebuilt packages * github: remove continue-on-error from download step Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

This test was created long time about to validate some snaps but is not needed anymore.

Step `preseed` was until here absent from the OpenAPI spec. This commit documents it. Because the order of the `preseed` step (after `finish`) is important, a description of the step was included that mentions it. For consistency, descriptions were added to all other steps of action `install`

* workflows: set run-name per nightly-spread variant Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! workflows: set run-name per nightly-spread variant Wrap workflow_dispatch condition in parens for readability/consistency, per review. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> --------- Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

…ert fails, the unlock defer doesn't fail (#17777)

…17765) Follows #17738. See the [previously prepared list](https://warthogs.atlassian.net/browse/SNAPDENG-35741?focusedCommentId=1146421) of interfaces that do not support parallel instances. This change flags some of those interfaces with appropriate error msg that will be included in the user shown error when trying to parallel install such a snap. **Notes** * Exception to the above list: \<none\> * There are more interfaces that do not support parallel instances on only-slot side, but these will be handled in follow-ups to limit the PR size [SNAPDENG-37498](https://warthogs.atlassian.net/browse/SNAPDENG-37498)

* tests: new image-generator test tool used for nested tests This is a new tool used to create the images used for nested tests and ubuntu-core tests. Also it is moved the ubuntu-image tool setup to the tool which previoulsy was installed in several places. * fix after rebase * Minor fixes based on review comments * fix base_channel change in other releases then core26 * Added a comment explainig why we manage different the core26 channel * add new ubuntu-image tool * fix shellcheck errors in ubuntu-image * Fix copilot issues * update url for ubuntu-image binary * Manual merge an changes on ubuntu-image.sh tool * fix shellcheck error in image.sh * fix output name for ubuntu-image * Fix more shell check errors from tests/unit/go:static * fix nested tests using ubuntu-image snap instead of the new tool * fix nested tests using the api-url * remove store-url from tests incorrectly set

…cpu0 add (#17778) rtc add event is unreliable in nested VMs: rtc-cmos's platform_driver_probe() can lose an initcall race against ACPI creating PNP0B00, leaving no rtc device for the whole boot. Use cpu0's add event instead, registered earlier via subsys_initcall with no ACPI/driver-probe race. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

…ystem holds (#17745) This removes support for gate-auto-refresh-hook, but retains the internal implementation in case someone complains that they need it back. If no one does, we'll remove all of this code later. I've just dropped the spread tests for now. These are easier to add back later if needed. For the unit tests, we'll probably want to convert some of those to system hold tests, so I've retained them for now.

…KB (#17789) OVMF builds with the SecurityPkg default PcdTcgLogAreaMinLen of 64KB for the preboot TCG event log. Measured TPM event logs for a nested test, taken at baseline and after adding 1 and 2 recovery systems, show the log growing by ~3.9KB per additional recovery system (~13-15 new events per recover+run reboot cycle), with baseline usage already at 57.5KB (88% of 64KB). Tests that create several recovery systems in one run (e.g. seed-refresh-back-to-revision/install_path_kernel, which goes through 3 seed-refresh cycles) exceed the 64KB cap. When systemd-stub's kernel cmdline measurement into PCR 12 fails with EFI_VOLUME_FULL, the PCR12 value no longer matches what the sealed FDE key's PCR policy expects, so snap-bootstrap fails to unlock the encrypted data partition on every keyslot, triggering emergency-reboot.service, which repeats the same failure until the run eventually surfaces as 'cannot finish ... installation, there was a rollback across reboot'. 128KB gives headroom for roughly 19 additional recovery-system cycles from baseline. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

…17715)

* daemon: record AUTHZ grant and deny reasons Thread the recorder into access checks and log it from ServeHTTP using the action already cached for the request and the ucred peer. * daemon, seclog: outcome -> match, add iface side constants, support unknown side * tests/main/security-logging: add grant and deny case * daemon: add setLevel and convert helpers to methods * tests/main/security-logging: remove curl dependency

* tests: new script used to find the snaps used in snapd tests This script is used to generate a list of snaps classified and showing the owner. * Add definition of missing snaps in tests/lib/snaps/store * Add missing files for wayland snap * allow running with --yaml and --exclude-used-by * fix shellcheck in wayland snap * update wayland snap

…17780) Follows #17765. See the [previously prepared list](https://warthogs.atlassian.net/browse/SNAPDENG-35741?focusedCommentId=1146421) of interfaces that do not support parallel instances. This change flags some of those interfaces with appropriate error msg that will be included in the user shown error when trying to parallel install such a snap. **Notes** * Exceptions to the above list: * The list marked these unsupported only on slot side but I've marked these **unsupported** on plug-and-slot sides * `physical-memory-control`: raw writes to arbitrary physical addresses can corrupt kernel state or crash the system even from a single writer, so parallel instances cannot safely share this. We [discussed](#17765 (comment)) that it is fine to mark it unsupported. * `xilinx-dma`: similar to the [previously agreed rejection](#17666 (comment)) of the `fpga` interface, allowing concurrent reprogramming of fpga via Xilinx Virtual Cable (XVC) may lead to incorrect hw configuration [SNAPDENG-37498](https://warthogs.atlassian.net/browse/SNAPDENG-37498)

Signed-off-by: Oliver Calder <oliver.calder@canonical.com>

…#17842)

* tests/nested/core: do not always rely on seal key file present * tests/nested/core/core20-{gadget,kernel}-reseal: stricter check <= core24

…17845) * tests/main: revert to static user session socket * tests/main: enable the session agent socket before the user session A packaged wants symlink makes systemctl disable not stick. Keep dh_installsystemduser, and enable the socket in snap-user-service before that test starts a user session.

…e checks (#17840)

* o/c/configcore: fix vitality computation with duplicate entries Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * o/c/configcore: add comment explaining first-wins behavior for vitality Signed-off-by: Oliver Calder <oliver.calder@canonical.com> --------- Signed-off-by: Oliver Calder <oliver.calder@canonical.com>

* o/{i,apparmorprompting,notices,state}: do not mutate notices It is important that notices are not mutated after they are initially created and returned. Otherwise, if one goroutine has retrieved a pointer to a notice while another goroutine is updating a notice via `Reoccur`, there's a race between the read and the write. Worse, if the `lastData` map were mutated directly, there could be a runtime panic (though the map is always replaced rather than mutated). Previously, the `Notice.Reoccur` method mutated a notice in place. This commit changes the behavior to instead create a deep copy of the notice with the required changes and then return it. Then, callers are responsible for replacing the existing notice in the relevant notice backend. Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * fixup! o/{i,apparmorprompting,notices,state}: do not mutate notices Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * o/state: copy user ID and data map in AddNotice Based on canonical/pebble#1084 Prevent callers from mutating already-recorded notice state by copying the user ID and occurrence data during AddNotice. Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * o/state: copy userID and data in exported notice helpers Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * fixup! o/state: copy user ID and data map in AddNotice --------- Signed-off-by: Oliver Calder <oliver.calder@canonical.com>

…naps (#17805) * data/systemd,packaging: ship boot-time mount units for parallel installs Parallel installed classic snaps need snap-mount-dir (/snap or /var/lib/snapd/snap) and /var/snap to be MS_SHARED mount points on the host, for snap-confine's per-instance bind mounts. Ship native-packaging-only systemd mount units that set this up once, early at boot, replacing the bind-mount-on-self snap-confine used to do on first run, which could propagate into an already running strict snap's preserved mount namespace and shadow content already mounted there. Unit properties: - ConditionPathExistsGlob=!/run/snapd/ns/*.mnt: skip while a preserved mount namespace exists, to avoid the shadowing above. - Options=rbind,private,shared: rbind preserves already-mounted content across a live upgrade (a plain bind would shadow it); private before shared gives the mount its own peer group instead of inheriting root's (a bind mount sourced from an already-shared path otherwise becomes a peer of it, duplicating every subsequent snap content mount). - Before=snapd.mounts-pre.target: snapd starts that target itself rather than it being pulled in by the standard boot chain, and every snap content mount unit is After=snapd.mounts-pre.target. - The parent mount units are static and pulled in by per-snap content mounts when needed. var-snap.mount is separately enableable under local-fs.target for boot. Two units exist (snap.mount, var-lib-snapd-snap.mount): the unit filename must match the escaped Where= path, and snap-mount-dir is /snap on Ubuntu/Debian but a symlink to /var/lib/snapd/snap elsewhere. Exactly one is installed per distro via the existing USE_CANONICAL_SNAP_MOUNT_DIR/USE_ALT_SNAP_MOUNT_DIR flags. openSUSE gets var-lib-snapd-snap.mount even though it can set both flags; a system still using /snap as a real directory needs to migrate first. var-snap.mount covers /var/snap, no distro split needed. wrappers.AddSnapdSnapServices does not pick these up: it returns early on classic, and excludes .mount files from its unit glob anyway. Wiring per distro: - Debian/Ubuntu: dh_installsystemd enables/starts var-snap.mount; upgrade restarts are excluded (a running bind mount's child content mounts do not survive one). The parent is static. - Fedora/openSUSE/Arch: var-snap.mount is not enabled on install (opt-in for boot, like classic snap support on those distros); the static parent can also be pulled in by content mounts. Both mounts are stopped on final package removal after snap-mgmt --purge, and var-snap.mount is disabled. Validated with kulturysta for all five targets, and in LXD VMs across live upgrade, reboot, and reboot-with-preexisting-snaps scenarios. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * cmd/snap-confine: stop lazily creating the shared snap mount, assert it Remove sc_ensure_shared_snap_mount() (legacy, LP:#1668659) and sc_ensure_snap_dir_shared_mounts(): both lazily bind-mounted snap-mount-dir and /var/snap on every invocation, now superseded by the boot-time systemd mount units. sc_initialize_mount_ns() drops its now-unused experimental_features parameter. snap-confine's remaining job is to assert snap-mount-dir and /var/snap are mount points before bootstrapping a classic snap with a non-empty instance key - strict confinement and classic without an instance key don't depend on them. Replace the static is_mounted_with_shared_option() (mount-point + shared check) with an exported sc_is_mount_point() (mount-point only; propagation is no longer snap-confine's concern). If either check fails, sc_mount_unit_file_exists() (stat() against the usual systemd unit directories) decides the error: if both units are shipped, start the selected static parent and enable/start var-snap.mount; otherwise update the native package. Add a unit test for sc_is_mount_point(). Validated with `make check` (256/256) and end-to-end in an LXD VM: upgrading the native package with a strict snap's preserved namespace already present left it untouched, while a parallel installed classic snap instance was correctly refused until reboot, after which it ran correctly. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * overlord/snapstate: check snap mount dir before installing classic parallel instance snapd does not bootstrap the snap execution environment itself (that's snap-confine's job). Its part is an install-time check: when installing a classic snap under a non-empty instance key, assert SNAP_MOUNT_DIR and /var/snap are already mount points, aborting with an actionable error if not, instead of letting the install succeed only for snap-confine to then refuse to run it. Add checkSnapMountDirForParallelClassicInstall, wired into ensureInstallPreconditions next to checkParallelInstancesSupport and validateFeatureFlags. Skipped unless classic-confined, non-empty instance key, and not already installed - only fresh installs are checked, refreshes are not. ensureInstallPreconditions' single call site (earlyChecks) only runs during target resolution for a fresh Install/Update, before any Task/Change exists, so in-progress changes are unaffected. mountUnitFileExists checks for the unit files themselves (under the usual systemd unit directories) to tell the two failure cases apart: name the selected static parent unit to start and var-snap.mount to enable/start if both are shipped, or say the native package needs updating otherwise. Add tests covering both error cases and the alternate parent unit name. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * tests: add spread test for the parallel installs boot-time mount transition Exercises the ConditionPathExistsGlob safety guard end to end. This suite installs snapd via the snapd snap, not a native package update, so it must deploy the mount units itself: - deploys snap.mount/var-lib-snapd-snap.mount and var-snap.mount manually - confirms they refuse to start once a preserved strict snap mount namespace exists - confirms a fresh classic-snap-under-instance-key install is rejected while the mount is missing - enables var-snap.mount and reboots - confirms the mounts are active with no duplicated content mounts, every snap works, and a parallel installed classic snap installed after the reboot works too - purges everything, leaving a clean state Validated with NO_REBUILD=1 ./run-spread -debug garden:ubuntu-26.04-64:tests/main/parallel-install-transition and garden:fedora-44-64:tests/main/parallel-install-transition. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * tests/main/parallel-install-classic: prepare mount units for classic instances Classic parallel instances need the snap-mount-dir and var-snap bind mounts active, so this needs to run under the snapd native package, not just the snapd snap. Skip unless the native package shipped the var-snap.mount unit, then enable/start it and start the static snap-mount-dir unit before installing anything. Fedora/openSUSE/Arch ship var-snap.mount disabled (opt-in for boot, like classic snap support on those distros) so this needs to opt in itself. Verified against a live Fedora 44 failure (var-lib-snapd-snap.mount present but inactive) and with fresh NO_REBUILD=1 ./run-spread -debug runs on garden:ubuntu-24.04-64 (skips, no native package there) and garden:fedora-44-64 (passes). Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * tests/main/parallel-install-remove-after: prepare native mount units Same fix as parallel-install-classic: classic parallel instances need the snap-mount-dir and var-snap bind mounts active, so the classic part of this test needs to run under the snapd native package. This test also runs on core and non-classic systems and only conditionally exercises the classic path (if os.query is-classic), so both the skip and the enable are gated the same way: core/strict-only runs are unaffected. Verified with fresh NO_REBUILD=1 ./run-spread -debug runs on garden:ubuntu-24.04-64 (skips, no native package there) and garden:fedora-44-64 (passes). Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * tests/main/parallel-install-socket-activation: prepare native mount units for classic instances Classic parallel installs need /var/snap and the snap mount dir to be mount points. Keep strict socket activation coverage independent of the native mount units; skip the classic variant if var-snap.mount is absent. Enable and start var-snap.mount, and start the static snap mount-dir unit before installing a classic parallel instance. Snapshot and restore both units' enabled and active states, including static, and remove test snaps before stopping their parent mount. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * cmd/snap-mgmt/snap-mgmt: lazily unmount snap-mount-dir Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * tests/main/parallel-install-inside-lxd: split strict and classic variants Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! tests: add spread test for the parallel installs boot-time mount transition * fixup! overlord/snapstate: check snap mount dir before installing classic parallel instance Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! tests: add spread test for the parallel installs boot-time mount transition Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! overlord/snapstate: check snap mount dir before installing classic parallel instance Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> --------- Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

* tests: new nightly workflow to check test snaps This nightly workflow checks if there are new test snaps which need to be registered under canonical account. Also check if test snaps have to be saved under tests/lib/snaps/store * Make workflow more strict

…gging on the kernel command line for non-debian systems (#17858)

* interfaces/builtin: support profile stacking for docker_support The `docker` snap (the intended user of the `docker_support` interface) transitions profiles from `snap.docker.dockerd` to `docker-default` when launching containers. However, with `NoNewPrivs` set, we plan to have the `docker` snap start stacking profiles instead of transitioning. Thus, the `docker_support` interface should support both the standalone `docker-default` profile and the stacked `docker-default//&snap.docker.dockerd` profile. For containers running with these stacked profiles, the allowed permissions are the intersection of the `snap.docker.dockerd` profile and the `docker-default` profile. Therefore, we must extend the signal and ptrace rules to ensure that peer-to-peer operations continue to work. In particular, the `docker-default` profile allows `signal (send, receive) peer=docker-default`, and we need to also allow `signal (send, receive) peer="docker-default//&@{profile_name}"`. Same goes for the `ptrace (read, readby, trace, tracedby) peer=docker-default` rule, for which we add `ptrace (read, readby, trace, tracedby) peer="docker-default//&@{profile_name}"`. If these were omitted, then `dockerd` can still signal and trace stacked containers itself, but stacked container-to-container signalling and tracing is blocked. Note that AppArmor sorts the names of the stacked profiles when constructing the canonicalized profile name, and which was the original profile has no effect. Thus, it ends up as `docker-default//&snap.docker.dockerd` instead of `snap.docker.dockerd//&docker-default`. Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * tests: add check of docker NoNewPrivs support For now, the docker snap does not stack profiles, so if it is run with `--security-opt no-new-privileges`, it hits an "operation not permitted" error. However, the profile stacking support added in this PR will allow the docker snap to use profile stacking, and thus launch containers under the more constrainted `docker-default` profile, stacked on top of the `snap.docker.dockerd` profile, which is compatible with `NoNewPrivs`. Therefore, this commit adds a commented-out check that the docker snap can run a container with `--security-opt no-new-privileges`, which we should un-comment-out once the docker snap is updated. Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * i/builtin: ensure docker-support profile stacking doesn't assume order Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * i/builtin: add comment about stacked profile names in docker-support Signed-off-by: Oliver Calder <oliver.calder@canonical.com> --------- Signed-off-by: Oliver Calder <oliver.calder@canonical.com>

In some context, snap-boostrap unlocked disks with keys we should remove during reprovision. That means we lose the only keyslots that are in the kernel keyring and we cannot do any further reprovision operations. To avoid this issue, we reserve a special keyslot of each disk which correspond to a currently used key by the kernel kerying, but that needs to be at some point removed. Since there can be only one key in use per disk, there is only one slot.

…tion (#17859)

* github: use noble runners for unit tests * github: switch to using jammy

This applies some constraints to list writing to prevent us from getting into weird scenarios where multiple matched paths conflict. In particular, forbidding nils in lists avoids paths being matched as unsets that then change the meaning of writes for the indexes that come after. This also forbids constant list indexes in the storage. This is because we want to prevent mapping request side maps into storage side lists. Consider this example: ``` rules: - request: items storage: items - request: foo.first storage: items[0] - request: foo.name storage: items[0].name - request: foo.second storage: items[1] ``` Writing `view.Set(bag, "foo", map[string]any{"name": "new"})` gives us the following matches: ``` unset items[0] // from foo.first, branch missing in value set items[0].name = "new" // from foo.name unset items[1] // from foo.second, branch missing in value ``` On the request side the user just asks to set a single value, but on the storage it becomes pretty nonsensical and there's no good way of servicing this. It likely won't prevent all of the issues but rejecting constant indexes on the storage side as well means that lists must have placeholders, so, since those must match between request and storage paths, we're essentially saying that storage side lists like `foo[{n}]` must have a matching request path. Signed-off-by: Miguel Pires <miguel.pires@canonical.com>

* Squashed 'tests/lib/external/snapd-testing-tools/' changes from e150463458..01d49e99af 01d49e99af New persistent remote.exec (#85) bfbe19e9bf Remove repack-kernel tool which is not used (#82) 9976d60c9f add halt-timeout to testflinger babckend (#84) 593f90d444 Remove the repack-kernel tool (#83) 0d80e08115 update os.paths and snaps.name for opensuse and core26 (#81) git-subtree-dir: tests/lib/external/snapd-testing-tools git-subtree-split: 01d49e99af9848df137a3a6b1c6aa539a978fd25 * improve how nested tools are copied * reconnect after updating the environment with new tools path * wait until essential tools are available in the nested VM * update how we reconnect to the nested vm to get the new environment * fix PATH during validation The fix explicitly supplies the intended PATH during validation, avoiding dependency on old Core SSH/PAM environment behavior. * Fix for tests with ssh reconnect

* features, o/snapstate: make parallel instances feature default-on * o/snapstate: cleanup now unnecessary enabling of parallel instances feature * tests: cleanup now unnecessary enabling of parallel instances feature * tests: more cleanup left-overs * tests: set experimental parallel instances feature for older snapd * tests: migrate default-on parallel instances in remaining tests * tests/main/mount-ns: update mount entries --------- Co-authored-by: Katie May <katie.may@canonical.com>

* github: add test selector step * github: refresh test-selector and remove oldest results * github: always write list of tests to run tests file * github: use changed file action output * github: convert spread_list to one line * tests/utils/features: do not delete mongodb entry when it is the only one * github: exit if test selector returns non-json output

* cmd/snap-seccomp: support ~ERRNO:syscall for explicit denials Explicit denials (~syscall) always returned EACCES. Allow selecting a different errno with ~ERRNO:syscall, for example ~ENOSYS:openat2. The supported errno names are ENOSYS, EACCES and EPERM. Rules with an explicit errno are added to both the deny and the allow filter. snap-confine installs the allow filter last and the kernel lets the most recently installed filter win among equal ERRNO actions, so the default ERRNO(EPERM) of the allow filter would otherwise mask the requested errno for syscalls that are not explicitly allowed. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> * interfaces/seccomp: return ENOSYS from openat2 in the default template Deny openat2 with ENOSYS instead of EACCES so that callers fall back to openat, which is filtered by mode. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> * tests/main: add snap-seccomp-enosys-openat2 spread test Check with a small C program that openat2 fails with ENOSYS under the default seccomp template and that plain openat still works. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> --------- Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>

…e tagging (#17865) * github: move package builds to reusable workflow and add it to feature tagging * github: allow feature tagging to procede even if a packaging job fails

…leases (#17870) * RELEASE.md: document how to retrieve exact dependency versions for releases Document how to find the exact versions of build dependencies used in the snapd snap and snapd .deb packages on Ubuntu releases. Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * build-aux: include `snap info go` in snapcraft build Ensure that the exact `go` snap version, snap revision, and channel will appear in the snapcraft build log. Signed-off-by: Oliver Calder <oliver.calder@canonical.com> * fixup! build-aux: include `snap info go` in snapcraft build Signed-off-by: Oliver Calder <oliver.calder@canonical.com> --------- Signed-off-by: Oliver Calder <oliver.calder@canonical.com>

) * data/systemd: prevent activation of snap.mount on hybrid systems When using hybrid, the kernel snap is mounted very early during boot. Prevent activation of snap.mount so that we do not end up with duplicated mounts which then confuse systemd. Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! data/systemd: prevent activation of snap.mount on hybrid systems --------- Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

bboozzoo

LGTM

When the device is not using full disk encryption (no sealed keys), an unexpected boot asset should be ignored rather than causing a failure. The trustedAssetsMap is left unchanged in this case, and old hashes are dropped as normal. When sealed keys exist, booting with content that was not expected still returns an error for security reasons. Update unit tests to cover both code paths: the error path when FDE is enabled (via stampSealedKeys) and the ignore path when it is not. Jira: https://warthogs.atlassian.net/browse/SNAPDENG-37794 Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

…tions Because Security Center is running as user as a snap, we need to give access to write actions on /v2/systems related to reprovisions. This uses the io.snapcraft.snapd.manage-fde polkit action that is already used by /v2/system-volumes which is defined as "Manage disk encryption". It also requires connection to interface snap-fde-control. In the same time the GET on running system (that is using ?running=true) is moved from simple authenticated access to more strict access as for the write operations. This is because this causes a post-install check, which probably is information that should not be provided to all authenticated users. This is a breaking change as client without the right permission will get a denied access.

…id classic (#17878) * cmd/snap-bootstrap: generate snap mount dir unit in initramfs on hybrid classic Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * tests/nested/manual/muinstaller-real: check that we can parallel install classic snaps Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com> * fixup! cmd/snap-bootstrap: generate snap mount dir unit in initramfs on hybrid classic * fixup! tests/nested/manual/muinstaller-real: check that we can parallel install classic snaps * fixup! tests/nested/manual/muinstaller-real: check that we can parallel install classic snaps * fixup! tests/nested/manual/muinstaller-real: check that we can parallel install classic snaps --------- Signed-off-by: Maciej Borzecki <maciej.borzecki@canonical.com>

ernestl and others added 2 commits October 5, 2026 15:48

github: remove 25.04 and add 26.10 (#17756)

110ab56

github-actions Bot force-pushed the sync-master-to-fips branch from 60ba320 to b4bafb7 Compare October 5, 2026 14:59

github-actions Bot force-pushed the sync-master-to-fips branch from b4bafb7 to 294660b Compare October 5, 2026 17:08

tests: remove install-snaps nightly test (#17759)

339aa8b

This test was created long time about to validate some snaps but is not needed anymore.

github-actions Bot force-pushed the sync-master-to-fips branch from 294660b to 53ecea1 Compare October 5, 2026 17:36

github-actions Bot force-pushed the sync-master-to-fips branch from 53ecea1 to ddf01ef Compare October 6, 2026 07:44

github-actions Bot force-pushed the sync-master-to-fips branch from ddf01ef to 5de44f3 Compare October 6, 2026 09:00

overlord: only assert after locking the state lock so that if the ass…

86ca4a0

…ert fails, the unlock defer doesn't fail (#17777)

github-actions Bot force-pushed the sync-master-to-fips branch from 5de44f3 to d9b1edb Compare October 6, 2026 09:09

github-actions Bot force-pushed the sync-master-to-fips branch from d9b1edb to 447d121 Compare October 6, 2026 13:47

github-actions Bot force-pushed the sync-master-to-fips branch from 447d121 to 586774c Compare October 6, 2026 19:06

github-actions Bot force-pushed the sync-master-to-fips branch from 586774c to b3ff128 Compare October 7, 2026 06:51

github-actions Bot force-pushed the sync-master-to-fips branch from b3ff128 to 0eb0962 Compare October 7, 2026 11:43

github-actions Bot force-pushed the sync-master-to-fips branch from 0eb0962 to 4b9e34f Compare October 7, 2026 12:59

.github: update CI to limit spread tests run for PRs targeting fips (#…

3750824

…17715)

github-actions Bot force-pushed the sync-master-to-fips branch from 4b9e34f to 94dca8e Compare October 7, 2026 13:42

github-actions Bot force-pushed the sync-master-to-fips branch from 94dca8e to 7e406ad Compare October 7, 2026 14:35

github-actions Bot force-pushed the sync-master-to-fips branch from 7e406ad to 273de66 Compare October 7, 2026 16:20

olivercalder and others added 24 commits October 16, 2026 23:25

o/snapstate: set name.String() when name is an InstanceName (#17856)

5190d77

Signed-off-by: Oliver Calder <oliver.calder@canonical.com>

tests/lib/tools, tests/main/nss-modules: increase wait, improve debug (…

d528682

…#17842)

tests/nested/core: do not always rely on seal key file present (#17843)

1c1dde3

* tests/nested/core: do not always rely on seal key file present * tests/nested/core/core20-{gadget,kernel}-reseal: stricter check <= core24

daemon, o/snapstate: consider components in install/refresh disk spac…

be57e8c

…e checks (#17840)

tests/lib: fix unbounded FIPS_BUILD_OPTION and fix setting feature ta…

c2323bc

…gging on the kernel command line for non-debian systems (#17858)

tests/utils/features: separate out coverage data into separate collec…

c216bae

…tion (#17859)

github: use jammy runners for unit tests (#17864)

21804b1

* github: use noble runners for unit tests * github: switch to using jammy

github: build snapd snap on nightly builds (#17862)

8567c0c

github: also use jammy runners for master push workflow (#17873)

1f03f70

github: move package builds to reusable workflow and add it to featur…

bfa3e4c

…e tagging (#17865) * github: move package builds to reusable workflow and add it to feature tagging * github: allow feature tagging to procede even if a packaging job fails

bboozzoo approved these changes Oct 22, 2026

View reviewed changes

maykathm and others added 5 commits October 22, 2026 15:50

spread: use --key flag instead of --cert (#17880)

cf0ff24

Merge master into fips, using snapcraft-fips.yaml

6c53f63

Navigation Menu

Repository navigation

chore: Synchronize fips with master - #17773

chore: Synchronize fips with master#17773
github-actions[bot] wants to merge 108 commits into
fipsfrom
sync-master-to-fips

github-actions Bot commented Oct 5, 2026

Uh oh!

bboozzoo left a comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

19 participants

Conversation

github-actions Bot commented Oct 5, 2026

Uh oh!

bboozzoo left a comment

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

19 participants