- @noahtalerman: Field descriptions show only the new names. JSON
examples show both old and new keys for backwards compatibility.
- Part of the following issue:
- https://github.com/fleetdm/fleet/issues/41419
This is a doc change to further move the documentation away from PoC
wording, but also update with the changes that we are going to introduce
with https://github.com/fleetdm/fleet/issues/30871
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#46637
- Updated the wording and flow of the guide
- Included links to new configuration profiles in the solutions folder
- Added alternative option for enrolling in to cloud management
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a Windows configuration profile to enable enrolling Google
Chrome into enterprise management.
* Included a template with a placeholder enrollment token for
administrators to replace when configuring device management.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Adds a `macos_applications` boolean query parameter to the list host
software endpoint (`GET /api/_version_/fleet/hosts/{id}/software`). When
true, results are restricted to apps installed at the top level of the
macOS /Applications folder, hiding helper apps, system apps,
command-line tools, and user-local apps. The filter applies only to
macOS hosts and is ignored on other platforms.
The filter is applied by pruning the in-memory software maps in
ListHostSoftware down to the title IDs that have a top-level
`/Applications` bundle, so the count and paginated queries stay
consistent and the filter applies uniformly across regular, VPP, and
in-house apps. Top-level is determined from
`host_software_installed_paths` via
`installed_path LIKE '/Applications/%' AND NOT LIKE '/Applications/%/%'
on source 'apps'`.
**Related issue:** Resolves#39017
Resolves#42818.
(I explicitly removed all checklist items.)
This is the least destructing approach to solve the issue.
Other approaches require like moving all Go code under a sub-directory
or keeping these docs/ directories free from invalid characters.
## Problem
[Publishing of Fleet's go
module](https://github.com/fleetdm/fleet/actions/runs/23857371168/job/69554220876)
is failing with the following error:
```
Run GOPROXY=proxy.golang.org go list -m github.com/fleetdm/fleet/v4@v4.83.0
go: github.com/fleetdm/fleet/v4@v4.83.0: reading https://proxy.golang.org/github.com/fleetdm/fleet/v4/@v/v4.83.0.info: 404 Not Found
server response:
not found: create zip: docs/solutions/windows/configuration-profiles/allow network connectivity during connected standby – [ACConnectivityInStandby_2, DCConnectivityInStandby_2].xml: malformed file path "docs/solutions/windows/configuration-profiles/allow network connectivity during connected standby – [ACConnectivityInStandby_2, DCConnectivityInStandby_2].xml": invalid char '–'
[Truncated: too long.]
```
## Summary
Root cause
The [publish go module
step](https://github.com/fleetdm/fleet/blob/main/.github/workflows/publish-go-module.yml)
asks proxy.golang.org to build a module zip for the v4.X.Y tag. That
build was failing on two independent, each-fatal issues — both stemming
from the monorepo carrying non-Go content that violates Go module zip
rules:
1. Invalid path characters — 35 tracked files with characters Go module
zips forbid: en-dash – in 32
docs/solutions/windows/configuration-profiles/*.xml files (the one in
your error), emoji 📜 in 2 handbook/company/legal/ files, and an
apostrophe in 1 website/assets/ image. This is the literal create zip: …
invalid char '–' error.
2. Source tree too large — 582 MiB tracked vs Go's hard 500 MiB limit;
website/ alone is 318.7 MiB.
## Fix
Added a go.mod to website/, docs/, and handbook/, turning each into a
nested module that x/mod/zip omits from the published v4 module — the
same pattern Fleet already uses under tools/. One move solves both: all
35 bad filenames live in those three dirs, and excluding them drops the
module to 207 MiB tracked → 112 MiB zipped.
Files created:
- website/go.mod, docs/go.mod, handbook/go.mod (module markers, each
with a comment explaining why)
Verified safe: no .go files and no //go:embed references in those dirs,
and go list ./... still resolves all 491 packages.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Added standalone module configurations for documentation, handbook,
and website directories.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Removes docs/solutions/windows/scripts/install-yellowkey-extension.ps1
(thin wrapper that fetched Allen's upstream installer) and updates the
policy's run_script.path to install-windows-yellowkey-extension.ps1, the
canonical filename in allenhouchins/fleet-extensions. Users drop Allen's
installer (with its canonical name) into their GitOps scripts directory;
the policy references it directly.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** #46360
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated Windows YellowKey osquery Fleet policy documentation with
revised script references and remediation instructions for hosts that
fail to load the extension.
* **Chores**
* Removed obsolete installation script; installation procedures have
been consolidated for improved clarity and maintainability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#46226
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files)
for more information.
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
## Testing
- [x] Added/updated automated tests
- [x] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Add CA certificate rollover CLI to renew MDM CA certs with an
extend-years option while preserving the private key and certificate
properties.
* **Improvements**
* Decryption logic updated to accept previously-rolled CA certificates
so escrowed disk-encryption keys can be decrypted after rollover.
* **Tests**
* Expanded tests and mocks to cover rollover and decryption scenarios.
* **Chores**
* Updated ignore rules and added a changelog entry for the rollover
process.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/46226?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
After ADE enrollment with enable_disk_encryption: true, hosts reported
as unencrypted with the disk-encryption policy failing and no recovery
key escrowed until the user logged out/in or restarted.
## Root cause
Fleet's shared macOS disk-encryption probe was:
```
SELECT 1 FROM disk_encryption
WHERE user_uuid IS NOT "" AND filevault_status = 'on' LIMIT 1
```
On the osquery disk_encryption table, filevault_status and user_uuid
are populated from independent sources: filevault_status from
`fdesetup status`, user_uuid from `diskutil apfs listCryptoUsers`
(the UUID of a user with SecureToken authority to unlock the volume).
In the post-ADE window, even with ForceEnableInSetupAssistant=true,
SecureToken propagation can lag — filevault_status='on' but
user_uuid='' for a brief period that resolves on a session event.
When the predicate failed, the query returned 0 rows and three
downstream behaviors broke in lockstep:
- host_disks.encrypted flipped to false ("unencrypted")
- the built-in "Full disk encryption enabled (macOS)" policy failed
- mdm_disk_encryption_key_file_*_darwin returned encrypted=0,
gating the PRK ingest and leaving the recovery key un-escrowed
The predicate originated in groob's standard query library entry
from 2021 as a strict compliance check ("is the host actually
protected, with a user able to unlock it?"). When the disk-encryption
status feature shipped in Nov 2022 (PR #8526, issue #3906), the
same string was reused verbatim and later extracted into
usesMacOSDiskEncryptionQuery — never revisited for whether the
SecureToken gate made sense outside the compliance-policy context.
**Related issue:** Resolves#45369
## Summary
Adds detection and mitigation for YellowKey (CVE-2026-45585), an
unpatched BitLocker bypass affecting Windows 11, Server 2022, and Server
2025. This PR provides:
1. **Detection via osquery extension**: A policy that ensures the
`windows_yellowkey` extension is loaded, enabling daily reporting on
host exposure status
2. **Daily report**: Surfaces per-host YellowKey verdict (not affected,
mitigated, mitigated via WinRE disabled, BitLocker off, or exposed)
3. **Mitigation script**: Implements Microsoft's official mitigation by
stripping `autofstx.exe` from WinRE's `BootExecute` registry chain
4. **Installation script**: Downloads and registers the upstream
`windows_yellowkey` osquery extension from
`allenhouchins/fleet-extensions`
The user-facing article is tracked in a separate issue and will land in
its own PR. The `docs/solutions/all/queries/` → `reports/` directory
migration will also be done in a separate PR.
## Changes
### New files
- `docs/solutions/windows/scripts/mitigate-windows-yellowkey.ps1` —
PowerShell script that mounts WinRE, loads the offline SYSTEM hive,
strips `autofstx` from every ControlSet's `BootExecute`, verifies via
read-back, unmounts with commit, and re-seals the BitLocker measurement
chain via `reagentc /disable` + `/enable`. Writes
`HKLM\SOFTWARE\Fleet\YellowKey\BootExecMitigated = 1` on success. Exit
codes: 0 (done), 3 (OS not affected), 4 (failed).
- `docs/solutions/windows/scripts/install-yellowkey-extension.ps1` —
Wrapper that fetches and executes the upstream installer from
`allenhouchins/fleet-extensions/main`. The upstream script handles
download, PE-header validation, service stop/restart, ACL hardening, and
loader registration. This wrapper exists only because Fleet's GitOps
`run_script` requires a file on disk.
-
`docs/solutions/windows/policies/windows-yellowkey-extension.policies.yml`
— Policy that checks `osquery_registry` for the `windows_yellowkey`
table. Passes when loaded; failing hosts run the installer.
- `docs/solutions/windows/reports/windows-yellowkey.reports.yml` — Daily
report querying the extension's `state`, `state_reason`, `needs_action`,
`winre_enabled`, `tpm_only`, and `mitigated` columns.
## Design notes
- **No opt-in gate**: Microsoft's `autofstx` strip is safe on every
affected host, so the mitigation script runs unconditionally.
- **One-way mitigation**: No unmitigate path. When Microsoft ships a
patch, apply it and clear the marker.
- **Extension sourcing**: The extension binary and installer live
upstream in `allenhouchins/fleet-extensions/windows_yellowkey`. Allen's
CI republishes on every push to `main`. The installer always pulls from
`releases/latest/download`, so no edits to this repo are needed when the
binary updates.
- **Loader path**: The installer writes to `C:\Program
Files\osquery\extensions.load` (osquery's compiled default), not to
orbit's directory, avoiding conflicts with TUF-managed extensions.
- **Hive and mount cleanup**: Mount, hive load, edit, and unmount all
run inside a single try/finally block to ensure cleanup even on
exception.
- **Read-back verification**: Each ControlSet's `BootExecute` is
verified after the strip to confirm.
https://claude.ai/code/session_016QZzDFsd1hTrYkQukGon6Y
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Windows YellowKey BitLocker bypass vulnerability detection and
reporting capabilities
* New policy to verify security extension installation and status on
Windows hosts
* New report surfaces vulnerability exposure and state across Windows
fleet
* Added automated remediation for vulnerable hosts, including extension
installation and bypass mitigation procedures
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/46358?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#45862
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
- Already added in the previous PR.
## Testing
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved detection and reporting of enrollment errors sent by the
server, ensuring error messages surface reliably.
* Prevented streaming leaks by stopping background work when a client
disconnects.
* **Documentation / Protocol**
* Made server-to-client streaming more spec-compliant (framing,
heartbeats) for more robust Android Enterprise enrollment communication.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45988?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
For article #45967: Rollout rings with Fleet labels.
Adds three drop-in label YAML files under docs/solutions/all/labels/:
rollout-rings.labels.yml — five cumulative dynamic labels (1%, 5%, 25%,
75%, 100%) for gradual software rollouts via labels_include_any. Each
ring is a superset of the previous.
rollout-waves.labels.yml — five disjoint dynamic labels covering the
same percentage breakpoints, for A/B experiments and per-wave reporting.
pinned-canaries.labels.yml — manual label for pinning specific hosts
(dev Macs, QA machines) into the first wave regardless of their natural
UUID shard.
All three use the same deterministic UUID-based shard expression
(positions 10 and 25, avoiding RFC 4122's fixed version/variant digits
at positions 15 and 20) so a host's ring assignment never changes across
reboots or agent reinstalls.
New folder docs/solutions/all/labels/ follows the existing pattern of
docs/solutions/all/policies/ and docs/solutions/all/queries/.
The companion article is in draft and will follow in a separate PR; it
references these files via
https://github.com/fleetdm/fleet/blob/main/docs/solutions/all/labels/...
URLs.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Documentation**
* Added comprehensive labeling solutions for managing staged rollouts:
manual pinned canaries for selecting priority hosts, cumulative rollout
rings covering multiple deployment phases (1%, 5%, 25%, 75%, 100%), and
partitioned rollout waves for balanced phased distribution strategies.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45971?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Closes#45969
## Summary
The `List certificate templates` API endpoint returned `null` for
certificates because the **API docs documented the wrong query parameter
name**. The docs said `fleet` but the code accepts `fleet_id` (or the
deprecated `team_id`). Customers following the docs used `?fleet=11`,
which was silently ignored, causing the endpoint to default to team 0
(unassigned) -- which typically has no certificates.
- **Docs fix**: Changed the parameter name from `fleet` (string) to
`fleet_id` (integer) in the REST API docs, matching how all other list
endpoints document this parameter.
- **API quality fix**: Initialize the `templates` slice in
`GetCertificateTemplatesByTeamID` so that when no templates exist, the
JSON response returns `"certificates": []` instead of `"certificates":
null`.
## Root cause
In `docs/REST API/rest-api.md`, the "List certificate templates"
endpoint documented the query parameter as `fleet` (string), but the
request struct accepts `fleet_id` or `team_id`:
```go
type listCertificateTemplatesRequest struct {
TeamID uint `query:"team_id,optional" renameto:"fleet_id"`
}
```
When the customer used `?fleet=11` (as documented), the parameter was
unrecognized and silently ignored. The endpoint defaulted to `team_id=0`
(unassigned), which had no certificates. The nil Go slice then
serialized to JSON `null`.
Credit to Andrey Kizimenko for identifying the docs mismatch.
## Changes
- `docs/REST API/rest-api.md` -- Fix parameter name from `fleet`
(string) to `fleet_id` (integer)
- `server/datastore/mysql/certificate_templates.go:174` -- Initialize
slice to avoid `null` in JSON
- `server/datastore/mysql/certificate_templates_test.go:489` -- Add
`require.NotNil` regression test
## Testing
All tests run locally against a real MySQL (Docker) and Redis instance:
| Test suite | Command | Result |
|---|---|---|
| Datastore integration (all certificate tests) | `MYSQL_TEST=1 go test
-run TestCertificates ./server/datastore/mysql/...` | 11 suites, 33
subtests, all PASS |
| Service unit tests | `go test -run
"TestCreateCertificateTemplate\|TestApplyCertificateTemplateSpecs\|..."`
| 4 suites, all PASS |
| Enterprise integration (full HTTP) | `MYSQL_TEST=1 REDIS_TEST=1 go
test -run "TestIntegrationsEnterprise/TestCertificatesSpecs"` | PASS |
| Enterprise integration (team delete) | `MYSQL_TEST=1 REDIS_TEST=1 go
test -run
"TestIntegrationsEnterprise/TestDeleteTeamCertificateTemplates"` | PASS
|
| Static analysis | `go build`, `go vet` | Clean |
Andrey's reproduction confirmed via screenshots:
- `?fleet_id=11` returns certificates correctly
- `?fleet=11` (the documented param) returns `null` -- the bug
- No param returns results when "unassigned" team has certificates
## QA steps
1. Follow the API docs to list certificate templates using
`?fleet_id=<id>`
2. Verify the response contains `"certificates": [...]` with the correct
data
3. Call without `fleet_id` and verify `"certificates": []` (not `null`)
for a team with no templates
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed the "List certificate templates" API documentation with the
correct query parameter name, enabling proper filtering of results.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45978?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Quick doc that should help how DEP sync works (We also have the general
entry) and then how to reset, and a call out that it's okay to do even
for larger deployments.
- @noahtalerman: For the following story:
- https://github.com/fleetdm/fleet/issues/43557
## Summary
- Adds `bundle_identifier` as a top-level field on
`HostSoftwareWithInstaller` struct, which is the response type for all
host software API endpoints (`GET /api/v1/fleet/hosts/{id}/software`,
`GET /api/v1/fleet/device/{token}/software`, etc.)
- The value is sourced directly from `software_titles.bundle_identifier`
via the SQL query, so it is always present even when
`installed_versions` is empty (e.g., software that has never been
installed on a host)
- Falls back to `installed_versions[0].bundle_identifier` if the
title-level value is not available
- The field is retained inside `installed_versions` for full backwards
compatibility
## Changes
### `server/fleet/software_installer.go`
- Added `BundleIdentifier string` field with
`json:"bundle_identifier,omitempty" db:"-"` tag to
`HostSoftwareWithInstaller` struct
### `server/datastore/mysql/software.go`
- Added `TitleBundleIdentifier` field to internal `hostSoftware` struct
mapped to `title_bundle_identifier` DB column
- Added `software_titles.bundle_identifier AS title_bundle_identifier`
to all four SQL query branches:
- Software installers SELECT
- VPP apps SELECT
- In-house apps SELECT
- Available-for-install SELECT (`stmtAvailable`)
- Added `software_titles.bundle_identifier` to GROUP BY clauses for
software installers and VPP apps
- In the return path, populates `BundleIdentifier` from
`TitleBundleIdentifier` (with fallback to first installed version)
### `server/datastore/mysql/software_test.go`
- Added `BundleIdentifier` assertion to both `compareResults` helper
functions (macOS/Linux and iOS/iPadOS test suites)
- Added explicit top-level `BundleIdentifier` assertions in
`testListHostSoftwareWithVPPApps` where the installed version bundle
identifier is already verified
## Example response shape
```json
{
"id": 121,
"name": "Google Chrome.app",
"bundle_identifier": "com.google.Chrome",
"icon_url": null,
"software_package": { ... },
"app_store_app": null,
"source": "apps",
"status": "failed_install",
"installed_versions": [
{
"version": "121.0",
"bundle_identifier": "com.google.Chrome",
...
}
]
}
```
Built for
[ntalerman](https://fleetdm.slack.com/archives/D0AEA6U4SM9/p1774036621198819?thread_ts=1774035719.384099&cid=D0AEA6U4SM9)
by [Kilo for Slack](https://kilo.ai/features/slack-integration)
---------
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
Co-authored-by: Kilo Code <kilo@kilo.ai>
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Co-authored-by: jkatz01 <yehonatankatz@gmail.com>
**Related issue:** Resolves#42288
# Summary
This PR adds support for configuring an optional SES sender domain.
When the SES email backend is enabled, Fleet can now use a configured
sender domain for the `From` address instead of always deriving the
domain from `server.server_url`. If the setting is not provided, Fleet
keeps the existing behavior.
# Impact
This gives self-hosted operators a server-side SES configuration option
for email sending without changing UI-managed SMTP settings.
# Root cause
The SES sender path only generated `do-not-reply@<server host>` from the
Fleet server URL, so there was no way to override the sender domain
through server configuration.
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
- [x] Added/updated automated tests
- [x] Setting(s) is/are explicitly excluded from GitOps
## Testing
- [x] `go test -tags full,fts5,netgo ./server/mail -run
'Test_(getFromSES|sesSender_SendEmail)$'`
- [x] `go test -tags full,fts5,netgo ./server/config -run
'TestConfig(SESSenderDomain|Roundtrip)$'`
- [x] `go test -tags full,fts5,netgo ./server/service -run
'TestService_EmailConfig$'`
- [ ] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added optional SES sender domain configuration. Users can specify a
custom domain for the email "From" address via config or environment
variable; when unset it falls back to the server hostname.
* **Tests**
* Added and expanded tests to verify sender-domain precedence,
From-header generation, and related error cases.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/43811?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Lucas Manuel Rodriguez <lucas@fleetdm.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Marko Lisica
