main
2636
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 George Karr
|
bc537a37d3 |
Support GCS presigned downloads for large packages on GCP (#50479)
**Related issue:** Resolves #49553 ## Summary When `s3_software_installers_signed_url` is enabled, Fleet returns a GCS SigV4 presigned URL for software installer, in-house app, and bootstrap package downloads, so clients fetch directly from GCS instead of streaming through the Fleet server. This unblocks packages over 50MB on GCP Cloud Run over HTTP1, while keeping live query working. Startup validation requires a GCS endpoint and HMAC credentials, and rejects combining the option with GCS IAM auth. Builds on community PR #47729 with review fixes. # Checklist for submitter - [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] QA'd all new/changed functionality manually ### Manual testing steps - [x] Confirm GCS parses our presigned URL format. A live GET with a wrong secret returned `SignatureDoesNotMatch`, so GCS reached signature validation. - [x] Full round-trip against live GCS with real HMAC credentials: upload, presign, and download. GCS returned HTTP 200 with the exact bytes. - [x] On a GCS-backed premium instance, installed a package on a host. Orbit received a `storage.googleapis.com` presigned URL and the host downloaded the package straight from the bucket. ## New Fleet configuration settings - [x] Setting(s) is/are explicitly excluded from GitOps <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **New Features** * Added support for delivering software installers, in-house apps, and bootstrap packages through Google Cloud Storage presigned URLs. * Downloads can be served directly from cloud storage instead of through the Fleet server. * **Improvements** * Added validation for supported endpoints and authentication settings. * Improved URL generation across supported signing methods. * Downloads fall back to Fleet URLs when signing cannot be completed. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
George Karr
|
d96ceb2c51 |
Add patch when closed policies (#50726)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #39962 # 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [ ] 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 ## Database migrations - [x] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [ ] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - N/A - [x] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). ## New Fleet configuration settings - [ ] Setting(s) is/are explicitly excluded from GitOps If you didn't check the box above, follow this checklist for GitOps-enabled settings: - [x] Verified that the setting is exported via `fleetctl generate-gitops` - [x] Verified the setting is documented in a separate PR to [the GitOps documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485) - [x] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) - [x] Verified that any relevant UI is disabled when GitOps mode is enabled <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added “Patch when closed” deployment policies to update software only when the application is not running. * Added deployment controls for force install, patching, and manual, forced, or closed-app patch options. * Fleet-maintained apps now automatically detect whether the application is open. * GitOps configurations support patch-when-closed settings with validation. * **UI Improvements** * Added clear activity and installation messages when updates are skipped because an app is open. * Replaced the Patch action with a unified Deploy workflow. * **Bug Fixes** * Prevented skipped updates from being incorrectly retried as failed installations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
RachelElysia
|
ddbc65a4f6 |
Self-service: "Install all" respects the search query (#50751)
## Issue Resolves #50528. ## Description On the My device > Self-service page, with a category selected and a search query typed, the "Install all" button previously ignored the search: it counted (and queued) every uninstalled item in the category, including software the search had filtered out. This PR scopes the button — count *and* install target — to the visible subset: - **Backend:** `POST /device/{token}/software/install_all` now accepts a `query` param. It's threaded through `SelfServiceInstallAllSoftwareTitles` → `GetSoftwareTitlesForInstallAll` → `opts.ListOptions.MatchQuery` on `ListHostSoftware`, reusing the same LIKE-on-`software_titles.name` semantics as the self-service list endpoint. - **Frontend:** new `filterSoftwareByQuery` helper layers on top of the category filter to drive `uninstalledCount` / `hasInProgress` and the value sent to install_all. Empty queries are stripped so the API isn't called with `?query=`. `display_name` matching is deliberately out of scope — the search filter across BE list, desktop table, and mobile filter is all raw-`name`-only today, so broadening install_all alone would re-introduce a similar mismatch. Filed as a follow-up: #50750. ## Screen recording In recording: - (FE fix) showing that the UI is filtering out install all count to be only what's on the screen - (BE fix) showing that the call to the API only queues up the install all for the installers shown on the screen when clicked https://github.com/user-attachments/assets/aaae3d29-dccf-484d-910f-67ca335bf0e8 ## Testing - FE unit tests: `filterSoftwareByQuery` helper, `SelfServiceCard` count-with-query + POST-with-query, `InstallAllInCategoryButton` prop forwarding. - BE unit test: EE service forwards the match query to the datastore. - BE datastore test: query, category+query, empty-match cases. - BE integration test: new "scopes to the query parameter when provided" subtest in `TestInstallAllSelfServiceSoftware`. - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * “Install all” now respects the active self-service search query. * Counts, progress indicators, and installation requests now reflect only software matching the current search and category filters. * Empty or whitespace-only searches continue to include all software in the selected category. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Carlo
|
8705b8def0 | Merge branch 'main' into feat-49553-gcp-large-packages | ||
|
Allen Houchins
|
051d12718c |
Add JetBrains ReSharper as a Windows Fleet-maintained app (#50659)
**Related issue:** Resolves #50567 Adds JetBrains ReSharper as a Windows Fleet-maintained app (winget `JetBrains.ReSharper`, version `2026.2.0.2`). ReSharper is a Visual Studio extension rather than a standalone app, so it does not follow the pattern of the other JetBrains FMAs (Rider, PhpStorm, DataGrip, etc.), which are plain NSIS installers that take `/S`. Reviewers should read the risks below before approving — a couple of things can only be confirmed from a validator run. ## What's here - `ee/maintained-apps/inputs/winget/resharper.json` - `ee/maintained-apps/inputs/winget/scripts/resharper_install.ps1` / `resharper_uninstall.ps1` - Generated `ee/maintained-apps/outputs/resharper/windows.json` + `apps.json` entry - Icon (`Resharper.tsx`, website PNG, alphabetical `index.ts` entries), generated from JetBrains' own brand asset ## Decisions that differ from the other JetBrains FMAs **`use_display_version_for_patch` is omitted.** Every other JetBrains winget input sets it, but the ReSharper manifest has no `AppsAndFeaturesEntries`, so the ingester hard-errors with `use_display_version_for_patch is set but no DisplayVersion found in winget manifest`. The patch policy therefore compares against winget's `2026.2.0.2`. **Custom `exists_query` instead of `fuzzy_match_name`.** The prefix is loose enough to match a possible per-VS-instance suffix, and excludes the separate ReSharper C++ and ReSharper SDK products: ```sql SELECT 1 FROM programs WHERE name LIKE 'JetBrains ReSharper%' AND name NOT LIKE 'JetBrains ReSharper C++%' AND name NOT LIKE 'JetBrains ReSharper SDK%' AND publisher = 'JetBrains s.r.o.'; ``` **Install script detects Visual Studio.** It builds `/VsVersion` from the instances `vswhere` reports and runs the installer with `/Silent=True /PerMachine=True /SkipEtwService=True`: - `/PerMachine=True` — the installer otherwise targets `%LocalAppData%`, which under Fleet's SYSTEM context would land in the SYSTEM profile instead of the developer's. The path is not configurable ([RSRP-428991](https://youtrack.jetbrains.com/issue/RSRP-428991)). - `/SkipEtwService=True` — JetBrains documents that `EtwHostService.msi` always raises a UAC prompt, so a fully silent install of every component is not possible ([SUPPORT-A-3189](https://youtrack.jetbrains.com/articles/SUPPORT-A-3189)). - It then waits for the uninstall registry entry (what osquery reads), because the web bootstrapper can outlive its own exit code, and logs the resulting ARP entries. **Uninstall removes every matching entry**, since ReSharper registers one per Visual Studio instance, using the defensive `UninstallString` parser and appending `/Silent=True` rather than the NSIS `/S`. Switches come from [JetBrains' silent install/uninstall article](https://resharper-support.jetbrains.com/hc/en-us/articles/207241485-How-to-use-silent-install-and-silent-uninstall-of-ReSharper-via-Command-Line), not guesswork. ## `unique_identifier` is provisional `program_publisher` is verified — `JetBrains s.r.o.` is hard-coded next to the ARP value names (`DisplayName`, `DisplayVersion`, `UninstallString`, `Publisher`) in `JetBrains.Platform.Installer.exe`, extracted from the installer. The **DisplayName is not verifiable offline.** The winget URL is a two-stage web bootstrapper: the 69 MB `.web.exe` contains `JetBrains.Platform.Installer.Bootstrap.exe`, which downloads the JetBrains dotUltimate installer, which downloads the product packages. The ARP entry is written by that downloaded stage under `Software\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}`, with `DisplayName` taken from a per-VS-host `PresentableName`. So `JetBrains ReSharper` is a best-supported guess. It can be confirmed from a validator run: `cmd/maintained-apps/validate/windows.go` searches `programs` with a loose `LOWER(name) LIKE '%…%'` on both the catalog name and `unique_identifier`, and logs `Found app: '<DisplayName>' … Version: <ver>` after running `MutateSoftwareOnIngestion`. That reveals both the true DisplayName and the post-mutation version. The install script prints the same information. **Expect a follow-up commit correcting `unique_identifier` (and possibly the exists query) once that log lands.** ## Risks 1. **Payload is not pinned.** The SHA covers only the 69 MB bootstrapper; roughly 1.7 GB is fetched from `download.jetbrains.com` at install time. JetBrains publishes only a `windowsWeb` download for ReSharper, so there is no offline installer to point at. Install duration may exceed script timeouts. 2. **Requires Visual Studio.** With no VS present the installer has nothing to install, so the script exits 1 with a clear message. `windows-latest` runners ship Visual Studio 2022 Enterprise, so validation should be able to install. 3. **`/PerMachine=True` conflicts with pre-existing per-user installs.** JetBrains states machine-wide mode "is not compatible with existing installations in user profiles"; one must be removed first. 4. **`/SkipEtwService=True` omits the ETW host service**, so dotTrace/dotMemory profiling integration is incomplete. This is the documented tradeoff for an unattended install. 5. **Version reconciliation unconfirmed.** If the DisplayName ends in a marketing version, the JetBrains name-based version mutation fires and the validator's prefix check passes; a VS-suffixed name would instead fall back to the registry `DisplayVersion`. # Checklist for submitter - [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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] `go test ./ee/maintained-apps/...` passes; both output JSON files parse; generated SHA matches the winget manifest. - [ ] QA'd all new/changed functionality manually — **not done.** Install/uninstall need a Windows host with Visual Studio; relying on the FMA Windows validator, which is also how `unique_identifier` gets confirmed. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added ReSharper to the maintained Windows applications catalog. * Added support for silent machine-wide installation and uninstallation. * Added Visual Studio compatibility checks and installation failure reporting. * Added a ReSharper icon for display in the software catalog. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
616f9ab108 |
Update scripts in Fleet-maintained apps (#50756)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Updates** - Refreshed macOS and Windows installer metadata for numerous maintained applications, including AltTab, Arc, Calibre, ChatGPT, Chrome, Kiro, Loom, Postman, Prisma Access Browser, RustRover, and others. - Updated release versions, download links, version detection, and integrity checks. - **Bug Fixes** - Improved Evernote removal verification on Windows. - Enhanced Krita and Proton Drive macOS cleanup, including related support files and background services. - **Configuration** - Webex is now marked as frozen. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> Co-authored-by: Allen Houchins <allenhouchins@mac.com> |
||
|
Allen HouchinsandClaude
|
9b5e9775ce |
Unfreeze XnConvert (macOS) (#50700)
Automated unfreeze probe. Removes `"frozen": true` and regenerates the output manifest so test-fma-macos-pr-only can validate `xnconvert/darwin` at its current upstream version. Frozen since: not recoverable from this checkout (squashed/shallow history — every input file is attributed to the same import commit) Version: 1.112.0 -> 1.115.0 Draft until validation reports. Merge only if the FMA checks are green and the validate shard actually ran for this slug. --- _Generated by [Claude Code](https://claude.ai/code/session_01Hx5UA4Dhqh2UUCX8h6k6Vv)_ Co-authored-by: Claude <noreply@anthropic.com> |
||
|
kitzyandAllen Houchins
|
5db78a63e3 |
Add Visual Studio 2022 (Community/Professional/Enterprise) as Windows FMAs (#50717)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #50653 Adds **Visual Studio 2022 Community, Professional, and Enterprise** as Windows Fleet-maintained apps. customer-universitas needs all three editions. ## What's here - Three input files, one per edition, each pointing at its own winget package (`Microsoft.VisualStudio.2022.{Community,Professional,Enterprise}`, all at `17.14.37`). - A shared install script (`visual_studio_2022_install.ps1`) — the downloaded file is a ~4 MB bootstrapper, not the IDE. The real multi-GB payload downloads from Microsoft *during* the install script, so install time depends on the host's network speed and counts against Fleet's 1-hour software-install timeout. `--wait` is required or the bootstrapper forks the real install to a background process and returns almost immediately. - Three uninstall scripts (one per edition) that resolve the install path via `vswhere.exe -products Microsoft.VisualStudio.Product.<Edition>` and call `vs_installer.exe uninstall --installPath <path> --quiet --norestart --wait`, since VS has no normal `UninstallString`. - Both scripts map winget's documented `3010`/`1641` (reboot pending/initiated) to a successful exit, and fail clearly on `1001`/`1618` (another VS Installer operation already running). - Default install ships the bare IDE shell (no `--add` workloads) — matches plain `winget install` behavior, per the issue's own conclusion that this needs no special-casing. - Icons: no scriptable source (no Windows host to extract the real per-edition `.exe` icon, and Microsoft's own download pages don't expose one) turned up distinct Community/Professional/Enterprise badge art, so all three currently use the same public Visual Studio mark ([Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Visual_Studio_Icon_2022.svg), marked public domain). **Flagging for #g-software Product Designer** to swap in the real per-edition badges if we have them. ## What I could not verify (no Windows host in this environment) - `unique_identifier`/publisher (`Visual Studio Community/Professional/Enterprise 2022`, publisher `Microsoft Corporation`) are taken from the winget locale manifest, not confirmed against a live registry entry. - The version-string quirk the issue calls out: winget's `AppsAndFeaturesEntries.DisplayVersion` is `"17.14.37 (July 2026)"`, not a clean version. I deliberately did **not** set `use_display_version_for_patch` — feeding that non-numeric string in as the patch target would break `version_compare` ordering across future version bumps (see the comment in `ingester.go`). Instead the patch policy compares against the plain winget `PackageVersion` (`17.14.37`), same as most winget FMAs. This should hold up if `version_compare` reads leading numeric-dot segments and ignores the trailing text, but I can't confirm that against real `programs.version` output without a host. - Whether `vs_installer.exe` actually honors `--wait` for `uninstall` the way the bootstrapper does for `install` — Microsoft's own docs say `--wait` "can only be passed into the bootstrapper; the installer (setup.exe) doesn't support it," which is in tension with the exact command this issue asked for and what I've seen used in the wild. Worth watching in validation logs. - End-to-end install timing on a normal (non-datacenter) connection, within the 1-hour timeout. # Checklist for submitter - [ ] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. <!-- Not added — no precedent for a changes file on FMA-addition PRs (e.g. #50553, TeamViewer Host). --> - [ ] 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. - [ ] Timeouts are implemented and retries are limited to avoid infinite loops - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] `apps.json` is valid JSON with descriptions filled in for all three editions - [x] Generator output reviewed: exists/patched queries, SHA256 (matches the live winget manifest), installer URLs - [x] `go build`/`go test ./ee/maintained-apps/...` pass; no shared ingester/validator code changed - [ ] FMA validator: install → detect → uninstall on a Windows host — **pending, needs a Windows host** - [ ] QA'd all new/changed functionality manually — **pending, same reason** ## FMA-specific (from issue #50653's acceptance criteria) - [x] Edition scope decided and recorded on the issue (all three: Community, Professional, Enterprise) - [x] Input added under `ee/maintained-apps/inputs/winget/` - [x] Custom install script handles `3010`/`1641` as success and fails clearly on `1618`/`1001` - [x] Custom uninstall script resolves the install path via `vswhere` and calls `vs_installer.exe uninstall` - [ ] Identity fields verified against a real installed host — **not yet, see above** - [ ] Patch policy verified against actual `programs.version` — **not yet, see above** - [ ] Install verified end to end within the 1-hour timeout on a normal-speed connection — **not yet** - [ ] Passes the FMA validator: install → detect → uninstall — **not yet** - [x] Icon exists (shared placeholder mark across all three editions — flagged for PD) No shared/ingester/validator code changed. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added Visual Studio 2022 Community, Professional, and Enterprise editions to the software catalog. - Added support for installing and uninstalling each edition with quiet execution, installation detection, error handling, and reboot handling. - Added version 17.14.37 metadata and update detection. - Added Visual Studio branding and edition-specific icons throughout the software interface. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Allen Houchins <allenhouchins@mac.com> |
||
|
Jonathan Katz
|
6ef4ba3910 | Merge remote-tracking branch 'origin/main' into feat/39962-patch-when-closed | ||
|
Nico
|
5a1365dc41 |
40493 webhooks for host activities (#50595)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #40493 Changes already reviewed in the PRs merged to this feature branch. Only additive change was https://github.com/fleetdm/fleet/pull/50595/commits/c0934e1fee46a734f9499a4c782563d4fcc345c4 to address CodeRabbit's comments. # Checklist for submitter - [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. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually https://github.com/user-attachments/assets/ea7f5157-a67a-4d83-842d-62197bd1546d ## New Fleet configuration settings - [ ] Setting(s) is/are explicitly excluded from GitOps If you didn't check the box above, follow this checklist for GitOps-enabled settings: - [x] Verified that the setting is exported via `fleetctl generate-gitops` - [x] Verified the setting is documented in a separate PR to [the GitOps documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485) - [x] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) - [x] Verified that any relevant UI is disabled when GitOps mode is enabled <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **New Features** * Added host activity automations with configurable webhook destinations. * Manage automations from the Hosts page with validation, permissions, and enable/disable controls. * Added GitOps support for team and unassigned-host webhook settings. * Activity webhooks now include fleet-scoped host IDs where applicable. * Added profile UUIDs to MDM profile resend activity details. * **Bug Fixes** * Improved Windows MDM enrollment activity details by including the linked host ID when available. * Preserved existing webhook settings when omitted during updates. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Rajendra Kadam
|
25cfac309c |
Let an edit clear a declaration's activation (#50711)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves # Raised by the frontend while building the Edit modal: there was no way to clear a declaration's custom activation. An absent `activation` field meant "keep it" on a labels-only edit but "delete it" when the profile contents were replaced, so clearing wasn't expressible and an ordinary content edit silently dropped the activation. The field is now three-state: | Request | Result | |---|---| | no `activation` key | stored activation left alone | | `activation` as an empty value | removed | | `activation` as a file | replaced | Multipart has no null, so an empty value stands in for one. Note this changes one existing behaviour: replacing a profile's contents without sending an activation used to delete it, and now preserves it. Removal has to be explicit. Anything ambiguous is rejected rather than guessed at, since every ambiguous form would otherwise resolve to deleting the stored activation: | Request | Result | |---|---| | `activation` as a nonempty value | 422 — more likely a malformed upload than a request to delete | | `activation` as a zero-byte file | 422 — a failed upload shouldn't delete anything | | `activation` sent as both a file and a value | 422 — one says replace, the other says remove | The unsupported-profile check also keys on the field being present rather than on it carrying content, so clearing an activation on a Windows, Android or mobileconfig profile is rejected instead of quietly succeeding. On the datastore side, `SetOrUpdateMDMAppleDeclaration` now takes an explicit action (`MDMAppleActivationKeep` / `MDMAppleActivationApply`) instead of inferring intent from the struct. The write is a full replace, so "keep" has to be stated — otherwise preserving the activation would mean reading it back and handing it to the write, which also risked dropping its Fleet variable associations. As a side effect the OS updates cron no longer fires a DELETE for an activation it never had. # 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`. 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. - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [ ] QA'd all new/changed functionality manually Integration test covers all three states end to end through the multipart decoder, plus service-level tests for preserve and explicit removal. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Apple MDM declaration updates now support preserving, replacing, or explicitly removing activation settings. * Omitted activation fields leave existing settings unchanged, while empty fields remove them. * Apple OS update declarations retain activation settings by default. * **Bug Fixes** * Labels-only updates no longer unintentionally carry forward activation data. * Invalid, empty, or conflicting activation uploads now receive clear validation errors. * Unsupported profile types now reject activation updates. * **Tests** * Added coverage for activation preservation, replacement, removal, and integration scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Allen Houchins
|
01f9e534f7 |
Fix Genesys Cloud FMA: winget dropped x86, ship x64 MSI (#50742)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> # Checklist for submitter If some of the following don't apply, delete the relevant line. - [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] QA'd all new/changed functionality manually # Details The nightly maintained-apps ingestion job panicked with `failed to find installer for app` on Genesys Cloud: ``` {"time":"2026-08-07T03:17:22.787715966Z","level":"INFO","msg":"ingesting winget app","name":"Genesys Cloud"} panic: ingesting winget app: failed to find installer for app ``` ## Why Genesys.GenesysCloud **2.53.923.0** stopped publishing x86 installers upstream. Previous versions (e.g. 2.51.916.0) shipped two x86 installers (a burn `.exe` and a wix `.msi`); the latest manifest ships only a single **x64** wix MSI. Our input pinned `installer_arch: "x86"`, so the ingester filtered out the only available installer and panicked. ## What changed - `ee/maintained-apps/inputs/winget/genesys-cloud.json`: `installer_arch` `x86` → `x64` - `ee/maintained-apps/outputs/genesys-cloud/windows.json`: regenerated with `go run ./cmd/maintained-apps -slug genesys-cloud/windows` — version 2.51.916.0 → 2.53.923.0, installer URL now the x64 MSI, sha256 matches the winget manifest's `InstallerSha256` ## Notes for reviewers - Exists/patched queries are unchanged (still keyed on ARP `name = 'GenesysCloud'`, `publisher = 'Genesys Inc.'`), and install/uninstall script refs are identical since it's still a machine-scope MSI — detection and remediation carry over for existing installs. - The MSI `UpgradeCode` is unchanged upstream (`{A0E8C487-C337-441C-83AF-90364DA4B793}`), so the x64 MSI upgrades existing x86 installs in place (ProductCode is new, install dir moves from `ProgramFiles(x86)` to `ProgramFiles`). - The new manifest declares a `Microsoft.VCRedist.2015+.x64` dependency (the old x86 MSI declared the x86 variant). Fleet doesn't resolve winget dependencies; the FMA validator run on this PR will confirm whether the installer tolerates its absence. |
||
|
Harrison RavazzoloandLucas Manuel Rodriguez
|
32802c5731 |
Fix Google Calendar scheduling over Focus Time and Out of Office events (#50605)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves https://github.com/fleetdm/fleet/issues/50548 Fleet's calendar integration was scheduling maintenance events over users' **Focus Time** and **Out of Office** blocks, even when those were marked Busy. The root cause is the event query in `ListEvents` (ee/server/calendar/google_calendar.go), which only requested `"default"` event types — so `focusTime` and `outOfOffice` events were never returned and never considered during conflict detection. ## Change Added the blocking event types to the query: ```go EventTypes("default", "focusTime", "outOfOffice"). ``` # 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`. --------- Co-authored-by: Lucas Manuel Rodriguez <lucas@fleetdm.com> |
||
|
Carlo DiCelico
|
a5101d796f |
Address review feedback for GCS presigned downloads
- config: require an https GCS endpoint and HMAC credentials when signed URLs are enabled, and reject combining them with STS assume role (alongside the existing GCS IAM auth check). - s3 store: build the presign client once and reuse it across Sign() calls. - changes: note bootstrap package downloads are covered too. - tests: assert the presigned URL shape and cover the STS assume-role rejection. |
||
|
7-1337
|
8c01492d20 |
Address review: strict GCS host validation, reject signed URL + IAM auth
CodeRabbit review on #47729: - config: validate the endpoint by parsed hostname instead of a substring match, so a look-alike host or a path containing "storage.googleapis.com" no longer satisfies the GCS requirement. Accepts storage.googleapis.com and *.storage.googleapis.com (with or without an explicit scheme). - s3 store: reject software_installers_signed_url combined with GCS IAM (bearer) auth at store init. Presigning needs SigV4 HMAC credentials, but IAM auth uses placeholder static creds plus bearer middleware that presigning drops, which would yield unusable signed URLs. - logs: make the installer/in-house-app signing error messages mode-agnostic ("check signed URL configuration") since they now cover GCS presigning too. - tests: add coverage for strict host validation and the signed-URL + IAM-auth rejection. |
||
|
7-1337
|
c7dabdc939 |
Add GCS presigned URL support for software installer downloads
Fleet can already hand out signed download URLs so clients fetch software installer and in-house app packages directly from object storage instead of streaming the bytes through the Fleet server. That path was AWS-only: it relied on CloudFront URL signing, which has no Google Cloud Storage equivalent. On a GCS-backed deployment, downloads always proxied through Fleet. This adds a GCS counterpart. When the new `s3_software_installers_signed_url` option is enabled, the S3 store returns a SigV4 presigned GET URL generated locally from its own credentials (no call to the bucket), pointing directly at the GCS endpoint. The signing logic prefers an existing CloudFront signer when configured and otherwise falls back to presigning; behavior is unchanged for deployments using neither. The option is gated and validated at startup to require a GCS (storage.googleapis.com) endpoint, so it fails fast rather than silently proxying large files on an unsupported backend. |
||
|
Allen Houchins
|
ec59e20971 |
Regenerate Fleet Desktop FMA manifests for v1.4.0 (#50674)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA — follow-up to #49910 ## What changed Regenerates `api/fleet-desktop.json` and `outputs/fleet-desktop/darwin.json` for Fleet Desktop v1.4.0. No cask changes. ## Why #49910 bumped `Casks/fleet-desktop.rb` to 1.4.0 but never ran `regenerate.sh` or the ingester, so the generated manifests — the files Fleet actually serves — were still on 1.3.4 and still pointed at the old `allenhouchins/fleet-desktop` GitHub release URL. That release feed is stale (it stops at v1.3.4); 1.4.0 is hosted at `download.fleetdm.com`. The `.rb` bump had no effect in production, and nothing in CI catches this kind of drift. This was found during a routine custom-tap maintenance pass. All four casks (druva-insync, fleet-desktop, xcreds, zoom-rooms) are at their latest upstream versions, so this is the only change needed: | Cask | Version | Upstream | | |---|---|---|---| | druva-insync | 8.1.3,110967 | `inSync-8.1.3r110967` | current | | fleet-desktop | 1.4.0 | 1.4.0 (1.4.1 → 404) | **manifests were stale** | | xcreds | 5.9,9148 | `tag-5.9(9148)` | current | | zoom-rooms | 7.1.5.13403 | `cdn.zoom.us/prod/7.1.5.13403/` | current | ## Notes for reviewers Verified the 1.4.0 installer against the cask stanzas before regenerating: - sha256 of the downloaded pkg matches the cask's `c920b983…` - receipt id `com.fleetdm.fleet-desktop` (from `PackageInfo`) matches both the `pkgutil:` and `quit:` stanzas - `CFBundleShortVersionString` is `1.4.0`, matching the cask version — so the `patched` query won't produce a perpetual false "Update available" - the `pkg` stanza filename `fleet_desktop-v1.4.0.pkg` matches the downloaded filename `regenerate.sh` rebuilds all four api JSONs; only fleet-desktop changed, so there was no brew schema drift to absorb on the others. The `install_script_ref` changes (`5d021f75` → `0341b271`) only because the pkg filename inside the script changed; `uninstall_script_ref` is unchanged. Unrelated, not addressed here: brew emits a deprecation warning on three casks for `depends_on macos: ">= :ventura"` (string comparison) vs `depends_on macos: :ventura`. It doesn't affect the generated JSON. # Checklist for submitter - [x] QA'd all new/changed functionality manually ## fleetd/orbit/Fleet Desktop - [x] If the change applies to only one platform, confirmed that `runtime.GOOS` is used as needed to isolate changes This is a macOS-only FMA manifest regeneration — no Go code, no schema, no fleetd/orbit runtime changes. The remaining template sections (changes file, SQL/input validation, timeouts, automated tests, migrations, config settings, fleetd compatibility/auto-update) don't apply; prior custom-tap bumps (#49563, #50651) likewise carry no changes file. |
||
|
Carlo
|
aac22ec9bc |
Align software installer authorization (#50630)
Software title details now return installer scripts and managed app configuration only to users who can read the installer. Uninstalling software from the My device page now applies the same self-service and label scope rules as installing. # Checklist for submitter - [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. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Security & Permissions** * Restricted installer scripts, managed-app settings, and related configuration to authorized viewers. * Preserved package metadata while hiding sensitive installation details from unauthorized roles. * Improved access handling for requests without an assigned team or involving inaccessible fleets. * **Bug Fixes** * Updated device-initiated software removal to honor self-service eligibility and label scope. * Added clearer errors when software is unavailable for self-service or outside the device’s scope. * Prevented software titles from inaccessible fleets from appearing in results. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Lucas Manuel Rodriguez
|
58a7679144 |
Add support for nested Entra groups in IdP vitals (#50469)
Resolves #48886. - [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. ## Testing - [X] Added/updated automated tests - [x] QA'd all new/changed functionality manually ## Database migrations - [X] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [X] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [X] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added support for nested groups in Entra IDP vitals. * SCIM groups can now include child groups and resolve membership across multiple levels. * Host filters and group-based access now account for inherited group memberships. * Added validation and duplicate prevention for nested group membership updates. * **Bug Fixes** * Corrected membership updates and removals to keep nested group relationships synchronized. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Jordan Montgomery
|
600fbf461d |
Update fleet desktop FMA to v1.4.0 (#49910)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #45524 Release alongside v4.90.0 release. Don't release prior FMA update of Fleet Desktop macOS to 1.4.0 https://github.com/fleetdm/fleet/actions/runs/30112916197 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Updated the Fleet Desktop Homebrew cask to version 1.4.0. * Downloads now use the official Fleet Desktop distribution URL. * Updated the project homepage reference. * **Maintenance** * Adjusted automatic update detection to use manual, release-based versioning. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
fleet-releaseandallenhouchins
|
cfe2a08269 |
Update Fleet-maintained apps (#50651)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added the latest available releases for a broad range of macOS and Windows applications, including Signal, AWS VPN Client, WebStorm, Zed, Filebeat, Loom, Ollama, and others. * Updated installer details and verification checks to support reliable installation of current versions. * **Bug Fixes** * Improved removal behavior for selected applications, including cleanup of background services, cached data, recent documents, and related components. * Updated uninstall handling for applications with changed installer identifiers. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> |
||
|
|
ecdf1ff003 |
Add TeamViewer Host as a Windows Fleet-maintained app (#50553)
**Related issue:** Resolves #50332 Adds **TeamViewer Host** as a Windows Fleet-maintained app. ## The issue's premise was wrong — this needed no new capability #50332 was blocked on "not in winget." It is in winget: `TeamViewer.TeamViewer.Host`, published continuously since **June 2023** (v15.42.8), currently **15.80.4** (merged upstream as microsoft/winget-pkgs#409335, 2026-07-29). I downloaded the live x64 installer and its SHA256 matches that manifest byte-for-byte. It reads as absent because it's nested a level deeper than you'd expect — `manifests/t/TeamViewer/TeamViewer/Host/`, a sibling of the full client's *version* directories rather than of the publisher's package directories. Consequence: this comes off the dependency on #50364, and that FR loses one of its three examples. The other two (#50328, #50329, OLE DB Driver 18/19) still hold — there is no OLE DB package under any winget publisher. ## Identity verified against the installer, not winget metadata Per the `new-fma` golden rule, from the x64 MSI's `Property` and `Registry` tables: | Field | Value | Evidence | |---|---|---| | `unique_identifier` | `TeamViewer Host` | MSI `ProductName`; no `ARPDISPLAYNAME`, empty `Registry` table, so this is the ARP DisplayName | | publisher | `TeamViewer` | MSI `Manufacturer`, equal to the winget locale `Publisher` → no `program_publisher` override | | `installer_scope` | `machine` | `ALLUSERS=1` | | bootstrapper? | No | no `ARPSYSTEMCOMPONENT` | Corroborated independently by [silentinstallhq's PSADT script](https://silentinstallhq.com/teamviewer-host-install-and-uninstall-powershell/), which detects the app with `Get-InstalledApplication -Name 'TeamViewer Host'` and uses `/S` for both install and uninstall. Generated exists query: ```sql SELECT 1 FROM programs WHERE name = 'TeamViewer Host' AND publisher = 'TeamViewer'; ``` No collision with the existing `teamviewer/windows` FMA, which generates an exact `name = 'TeamViewer'`. ## Why exe + `ignore_hash`, matching the full client winget offers Host as an NSIS exe and as a nested `wix` MSI inside a zip. The ingester can't select the zip (`installer.InstallerType` is `zip`, which never normalizes to `msi`), so the exe is the only reachable installer. TeamViewer publishes no version-pinned Host exe — `TeamViewer_Host_Setup_x64_15.80.4.exe` and the x86 equivalent both 404 — so the manifest's URL is the unpinned `TeamViewer_Host_Setup_x64.exe` and `ignore_hash: true` is required. This is vendor asymmetry, not a fixable winget defect: the *full* client does publish pinned exe URLs. Same reason `teamviewer/windows` already sets `ignore_hash`. ## Correcting the coexistence note in #50332 The issue assumed Host and the full client can co-exist. They can't. The Host MSI's `LaunchCondition` table blocks the install outright: > Error 25001: An incompatible TeamViewer package was detected that conflicts with the current MSI package: TeamViewer_Full 64-bit. Please manually uninstall this package. …plus equivalents for Full 32-bit/ARM64, Host ARM64, and the NSIS installs. **Relevant to validation: the validator host must not already have `teamviewer/windows` installed.** ## Icons No `index.ts` change needed — `matchLoosePrefixToKey` treats keys as whole words at the start, so `"teamviewer host"` matches the existing `teamviewer` key and inherits the TeamViewer brand icon. Verified against the real 1,163-key map. The website resolves its icon from the slug (`app-icon-${slug}-60x60@2x.png`) with no such fallback, so `app-icon-teamviewer-host-60x60@2x.png` is added — a copy of the existing TeamViewer brand asset, since Host ships the same logo. ## Two things for review 1. **The PowerShell is unverified.** Authored on macOS with no PowerShell available, so install/uninstall have not been executed. The uninstall script searches ARP by DisplayName instead of a hardcoded key, and uses the three-shape `UninstallString` parser (TeamViewer's is unquoted and contains a space in `C:\Program Files\...`, which the older `.Split('"')` approach in `teamviewer_uninstall.ps1` mishandles). Validator run is the real check. 2. **Category mismatch with the macOS side.** This uses `Communication`, matching the merged `teamviewer/windows`. #47121 adds `teamviewer-host/darwin` with `Productivity`. Worth reconciling — and that PR will want this same website PNG, so expect a trivial conflict. `name` is `TeamViewer Host`, matching #47121 so both platforms group together in the FMA library. ## Testing - [x] `go test ./cmd/maintained-apps/... ./ee/maintained-apps/...` passes - [x] Generator is idempotent — re-running produces no diff and preserves the `apps.json` description - [x] `apps.json` is valid JSON with no empty descriptions - [x] Live installer SHA256 confirmed against the winget manifest - [ ] FMA validator: install → detect → uninstall on a Windows host **(pending — needs a host without the full TeamViewer client)** No shared code changed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Allen Houchins <allenhouchins@mac.com> |
||
|
Allen Houchins
|
92aaf1de81 |
Fix Steam patch policy comparing an empty bundle_short_version (#50428)
**Related issue:** Resolves #50408 ## What changed Steam.app ships without a `CFBundleShortVersionString`, so osquery's `apps.bundle_short_version` is an empty string: ``` $ /usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" /Applications/Steam.app/Contents/Info.plist Print: Entry, ":CFBundleShortVersionString", Does Not Exist $ /usr/libexec/PlistBuddy -c "Print :CFBundleVersion" /Applications/Steam.app/Contents/Info.plist 6.0 ``` The generated patch policy compared that column, and `version_compare('', '6.0')` returns `-1`, so the `< 0` predicate was always true. The "Steam up to date" policy could never pass on **any** host with Steam installed, at any version. Meanwhile software inventory falls back to `bundle_version` and correctly showed Steam as up to date, so the two features disagreed about the same app on the same host — and with `install_software: true` the policy repeatedly reinstalled a version that was already installed. This adds a per-app override in the homebrew ingester comparing `bundle_version` (CFBundleVersion `6.0`, which the cask version tracks), following the pattern already used for `sonos` and the Firefox pre-release channels: ```diff -version_compare(bundle_short_version, '6.0') < 0 +version_compare(bundle_version, '6.0') < 0 ``` `ee/maintained-apps/outputs/steam/darwin.json` was regenerated with `go run ./cmd/maintained-apps -slug steam/darwin` — one line changed, no upstream version drift pulled in. ## Why scoped to one app The issue suggested changing the shared darwin version column in `pkg/patch_policy` to `COALESCE(NULLIF(bundle_short_version, ''), bundle_version)`. I didn't do that. It would be a no-op for the ~300 macOS FMAs that do set a short version, but that generator is load-bearing for every one of them, and the blast radius isn't justified by a single broken app. The per-app override is the established mechanism for exactly this. Side note for a possible follow-up: `patch_policy_path` exists in both the homebrew and winget input structs but is never read anywhere — a dead field. If we want a data-driven way to express these overrides instead of token checks in Go, that's the hook. ## Reviewer note: existing deployments do not self-heal `software_installers.patch_query` is snapshotted when the installer is created, and only refreshes on an FMA version change or an "Edit software" save. **Steam's cask version is a static `6.0`**, so this manifest change alone will not fix already-deployed Steam FMAs — the admin has to re-add or re-save the app. A GitOps re-apply doesn't help either; `ApplyPolicySpecs` regenerates from the stale installer row. Closing that gap means either a migration that rewrites stored patch queries, or refreshing `patch_query` when the manifest changes at the same version. Both are broader calls than this bug, so I left them out — happy to file a follow-up if you want it tracked. The exists query is unaffected — it matches on `bundle_identifier` only, with no version predicate. That's why install detection and self-service always worked correctly for Steam. # Checklist for submitter - [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. <sub>No new interpolation surface: the override formats the same bundle identifier and cask version the surrounding generator already formats.</sub> ## Testing - [x] Added/updated automated tests <sub>New `steam` case in `TestIngestApps` asserting both the patched and exists queries.</sub> - [x] QA'd all new/changed functionality manually Validated with osquery **5.23.1** — the same version as in the bug report. `version_compare('', '6.0')` returns `-1` and `version_compare('6.0', '6.0')` returns `0`, confirming the root cause directly. For an end-to-end check against the real `apps` table without planting a fake Steam.app on a Fleet-enrolled host, I used an already-installed app with the identical shape (`com.citrix.HDXCast`: empty `bundle_short_version`, `bundle_version` `24.05.0.3`): | Query | Host state | Result | |---|---|---| | exists | app installed | row → detected ✅ (unaffected by the bug) | | **old** patched | up to date | **no row → policy FAILS** ← reproduces the bug | | **new** patched | up to date | row → policy PASSES ✅ | | **new** patched | genuinely outdated (available `25.0.0`) | no row → policy FAILS ✅ | | **new** patched, verbatim from the regenerated manifest | Steam not installed | row → PASSES ✅ | The fourth row is the important one: the fix is not a blanket pass — it still fails hosts that are genuinely behind. Not verified: a live host with Steam actually installed (I don't have one). The `com.citrix.HDXCast` row has byte-identical column semantics, so I'm confident, but a QA pass on a real Steam host would close it out. `go test ./cmd/maintained-apps/... ./pkg/patch_policy/... ./ee/maintained-apps/...` passes; `go vet` and `gofmt` clean. I could not run `make lint-go-incremental` locally — it builds a custom golangci-lint via `git clone`, which my sandbox blocked, so I'm relying on CI for that. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved Steam patch detection on macOS by using the correct application version information. * Steam updates are now accurately recognized in Fleet software inventory and Homebrew-generated patch policies. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Noah Talerman
|
781ba43596 | Rename 'Certificate enrollment' to 'Certificate authorities' (#50535) | ||
|
Allen Houchins
|
bc3eee5f32 |
Re-add Dell Display and Peripheral Manager Windows FMA, validate on client-OS runner (#50313)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA (Windows FMA workstream; follow-up to #49127, which dropped DDPM) Re-adds **Dell Display and Peripheral Manager** (`Dell.DisplayAndPeripheralManager` 2.2.2.8) as a Windows Fleet-maintained app, and adds a `requires_client_os` routing override so its CI validation always runs on the `windows-11-arm` runner. ## Why DDPM was dropped before, and why it's viable now DDPM was dropped from the earlier re-add because its InstallShield setup aborted with `0x80042000` under every documented silent switch, which was diagnosed at the time as a .NET-prerequisite/headless-chaining problem. A new debug run with Dell's own `/CreateDebugLog` switch shows the real cause: the setup evaluates the OS at `OFUIBefore` and terminates because the runner reports **Microsoft Windows Server 2025**. DDPM is a Windows 10/11 client application and refuses to install on Server SKUs — which is exactly what GitHub's x64 `windows-latest` image is. ``` OSetUMode() 0 AP:2.2.2.8 OFUIBefore Os Major10 Minor0 OS - 44444 // End Log File... ``` ## `requires_client_os` CI routing - New optional winget input field `requires_client_os: true` (documented in `ee/maintained-apps/README.md` and on the Go input struct; ignored by ingestion). - `.github/scripts/partition-fma-apps.sh` routes any app with this flag to `windows-11-arm` — the only GitHub-hosted client-OS Windows runner — regardless of `installer_arch`. The x64 installer runs there under Prism emulation; DDPM's gate is the OS SKU, not the architecture. - Verified locally: partitioning the full 421-app Windows catalog reroutes only `dell-display-and-peripheral-manager/windows`. ## App identity (verified against the real installer) - Downloaded `DDPM-Setup_2.2.2.8.exe` from `dl.dell.com` (Chrome UA per #49123); SHA256 matches the winget manifest. - Embedded InstallShield `[Application]` block: `Name=Dell Display and Peripheral Manager`, `Company=Dell Technologies`; ProductCode matches the manifest GUID. The setup log reports `AP:2.2.2.8` as the registering version. - Installs with Dell's documented managed-deployment switches `/Silent /HeadlessMode=true /TelemetryConsent=false /TurnOffCA` — the final pre-drop iteration (6d0f2c00af), which also declines telemetry and disables DDPM's self-updater on Fleet-managed hosts. Uninstalls via `msiexec /x` on the ProductCode looked up in the registry by DisplayName. Input/uninstall script/icon are restored from the pre-drop state; the install script is the final pre-drop iteration with its root-cause comment corrected (Server-SKU OS gate, not headless-SYSTEM chaining). Output regenerated (winget still at 2.2.2.8; script refs verified). # Checklist for submitter If some of the following don't apply, delete the relevant line. - [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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] QA'd all new/changed functionality manually (partition script exercised locally over the full catalog and a mixed PR-style slug list; ingester regenerated with no output drift; `go test ./ee/maintained-apps/ingesters/winget/` passes) - [ ] `test-fma-windows-pr-only` validates DDPM on the `windows-11-arm` runner in this PR's CI <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added Dell Display and Peripheral Manager to the Windows software catalog, including installation, uninstallation, detection, metadata, and an app icon. * Added support for routing applications that require a Windows client operating system to the appropriate Windows 11 ARM test environment. * **Documentation** * Documented Windows client operating system routing behavior and test environment architecture details. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Allen HouchinsandClaude
|
5ec4c650d3 |
Update Evernote maintained app to 11.28.2 (#50583)
**Related issue:** Resolves # # Checklist for submitter - [ ] 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 - [ ] QA'd all new/changed functionality manually ## Summary Bumps the Fleet-maintained Evernote (macOS) app from `11.27.5` to `11.28.2`, the latest version per the [Evernote release notes](https://evernote.com/release-notes). - Updated `version` and the embedded `version_compare` target in the `patched` osquery query in `ee/maintained-apps/outputs/evernote/darwin.json`. - `installer_url` and `sha256` are unchanged — Evernote's DMG installer link always serves the latest build (`sha256: "no_check"`). - `inputs/homebrew/evernote.json` is frozen and untouched, as required. --- _Generated by [Claude Code](https://claude.ai/code/session_015tHhSdANCAv2WdENhRF4hf)_ Co-authored-by: Claude <noreply@anthropic.com> |
||
|
fleet-releaseandallenhouchins
|
935118d2ab |
Update Fleet-maintained apps (#50594)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Updated Akiflow, Lulu, PDFsam Basic, and TextExpander for macOS to their latest releases. * Updated Claude and Rancher Desktop for Windows to newer versions. * Updated Firefox Nightly for macOS to the latest nightly build. * Refreshed installer details and verification data to support the updated packages. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> |
||
|
fleet-releaseandallenhouchins
|
d2fe9be461 |
Update Fleet-maintained apps (#50584)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Updated Graphviz for Windows to version 15.1.1. * Updated PDFsam Basic for Windows to version 6.0.5.0. * Updated Visual Studio Code for macOS to version 1.132.0. * Updated Wavebox for macOS ARM to version 151.2.148.2. * Updated WhatsApp for macOS to version 26.31.19. * Refreshed installer details and version checks where applicable. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> |
||
|
fleet-releaseandallenhouchins
|
72c224bd78 |
Update Fleet-maintained apps (#50574)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Refreshed supported macOS and Windows application packages to their latest releases, including Asana, Chrome, Dropbox, Microsoft 365, Postman, Thunderbird, Todoist, and many others. * Updated version detection so devices recognize the new releases and receive applicable upgrades. * Refreshed installer downloads and verification data where required. * Updated installation instructions for selected applications, including Duo Desktop, Microsoft Office, Nextcloud, Nudge, Santa, and Tailscale. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> |
||
|
Andrew MellorandMagnus Jensen
|
192ac4eb51 |
48093 auld api gitops latest os version (#50213)
**Related issue:** Resolves #48093 - [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] QA'd all new/changed functionality manually ## New Fleet configuration settings - [ ] Setting(s) is/are explicitly excluded from GitOps If you didn't check the box above, follow this checklist for GitOps-enabled settings: - [x] Verified that the setting is exported via `fleetctl generate-gitops` - [x] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added “latest” version enforcement for macOS, iOS, and iPadOS updates using required `deadline_days`. * Updates dynamically target each device’s available OS version and deadline. * Configuration and GitOps outputs now include `deadline_days`. * **Bug Fixes** * Improved validation when switching update modes or omitting deadline settings. * GitOps updates now clear previously stored deadline values when omitted. * Changes to `deadline_days` are detected and applied consistently. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Magnus Jensen <magnus@fleetdm.com> |
||
|
|
33b4efe9c1 |
Update install script and Fleet-maintained apps (#50499)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Chores * Updated numerous maintained application definitions with newer releases, download links, version checks, and checksums across Windows and macOS. * Improved Windows installation reliability by recognizing successful installations that require a restart. * Corrected installer log-path handling for paths containing spaces. * Refreshed metadata for applications including Firefox, Docker Desktop, Discord, Tailscale, and many others. * Adjusted Google Credential Provider validation settings to support its installer distribution. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> Co-authored-by: Allen Houchins <allenhouchins@mac.com> |
||
|
Victor Lyuboslavsky
|
a4af4d896c |
Add default fleet for new Windows MDM enrollments (#41787) (#49922)
Demo: https://www.youtube.com/watch?v=cWxZlu9WuwA Guide updates: https://github.com/fleetdm/fleet/pull/49603/changes IT admins can configure the fleet that hosts enrolling through user-driven Windows MDM enrollment (Windows Autopilot, Entra join) are automatically assigned to, via the Windows MDM settings page, the mdm.windows_enrollment.default_fleet config setting, or GitOps. - New windows_enrollment_config row stores the default team; the config API surfaces it by fleet name and hydrates reads from the row so team renames and deletions never serve a stale name. Deleting the fleet clears the setting. - New edited_windows_enrollment_default_fleet activity, emitted only when the value changes. - The OMA-DM session persists the device-reported SMBIOS serial on still-unlinked enrollments, and orbit enrollment reverse-links by that serial and assigns the default fleet before orbit's one-shot setup-experience init, so the default fleet's software, scripts, and profiles apply during the Autopilot ESP. The DevDetail and osquery link paths keep the same assignment as fallbacks, and the EUA-token link path now shares the same post-link bookkeeping. - Hosts are only assigned when new to Fleet in this enrollment cycle: existing hosts, including ones parked in Unassigned, keep their fleet on re-enrollment, matching macOS ABM behavior. - GitOps defers applying the setting until teams declared in the same run are created, and fleetctl generate-gitops exports it. - Windows MDM settings page redesign per Figma: programmatic enrollment toggle, User driven enrollment section with the Entra-gated Default fleet dropdown, and a Migration section. <!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41787 # 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## 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 ## Database migrations - [x] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [x] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). ## New Fleet configuration settings - [x] Verified that the setting is exported via `fleetctl generate-gitops` - [x] Verified the setting is documented in a separate PR to [the GitOps documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485) - [x] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) - [x] Verified that any relevant UI is disabled when GitOps mode is enabled <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added support for assigning a default Fleet Premium fleet to new Windows MDM enrollments, including Autopilot and Entra join. * Default-fleet settings can be configured, cleared, and managed through Windows MDM settings and GitOps. * Assigned fleet software, scripts, and profiles can apply during out-of-box setup. * Added activity-feed visibility for default-fleet changes. * Improved Windows enrollment matching using hardware serial numbers. * **Documentation** * Documented default-fleet assignment for Windows enrollment. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Dante Catalfamo
|
f17c8cbd8d |
Bound Google Workspace directory sync pagination (#50092)
**Related issue:** Resolves #49365 |
||
|
Luke Heath
|
7cd67856aa | Fix medium-severity code scanning alerts (#50346) | ||
|
Allen Houchins
|
4d6dbf8639 |
Fix Gpg4win FMA ingest panic after winget relabeled 5.1.0 as x64 (#50494)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA — caught from a failing `Update Fleet-maintained apps` ingest run. # What this does Changes `installer_arch` from `x86` to `x64` for the Gpg4win Windows FMA, and regenerates its output (5.0.2 → 5.1.0). ## Why the ingest was failing ``` {"level":"INFO","msg":"ingesting winget app","name":"Gpg4win"} panic: ingesting winget app: failed to find installer for app ``` This is **not** a removed winget package — Gpg4win is still published as `GnuPG.Gpg4win`. The manifest was fetched and parsed fine; the failure is the `selectedInstaller == nil` check in `ee/maintained-apps/ingesters/winget/ingester.go`, which means no installer entry matched all four selector fields from our input. Upstream flipped the architecture label between versions: | | 5.0.2 (last ingested) | 5.1.0 (new) | |---|---|---| | `Architecture` | **x86** | **x64** | | Manifest generator | `wingetcreate 1.10.3.0` | `YamlCreate.ps1 Dumplings Mod` | Our input pinned `x86` to match 5.0.2, so nothing matched once 5.1.0 landed in `winget-pkgs` (2026-08-03 18:11 UTC, microsoft/winget-pkgs#409397). The ingester only walks to an older version directory on a genuine 404 of the installer manifest — never because the newest version's installer failed to match — so it panics instead of falling back. ## The new x64 label is the correct one Verified against the real installer rather than trusting either manifest: - The NSIS stub's PE header is i386, which is very likely what `wingetcreate` guessed `x86` from. Installer stubs are almost always 32-bit, so stub arch says nothing about the payload. - The payload ships 64-bit binaries in `bin/` (PE machine `0x8664`) alongside a 32-bit `bin_32/` compatibility set. So 5.0.2's `x86` was the inaccurate manifest and the bot corrected it. Regenerated `sha256` also matches a fresh download of `gpg4win-5.1.0.exe` bit-for-bit (`9682f282…20a2e`). ## Blast radius Worth flagging: this one field blocked **the entire FMA ingest**, not just Gpg4win. `failed to find installer for app` isn't matched by `isTransientGitHubError`, so it returns up to `panic(err)` in `cmd/maintained-apps/main.go`, which aborts the process before `processOutput` writes *any* app's manifest. Because the `ingesters` map is iterated in random order, this could take out the homebrew side too. Any future upstream flip of `installer_arch` / `installer_scope` / `installer_type` / `installer_locale` on any single app will do the same thing — worth a follow-up to make non-transient per-app ingest errors skip-and-report instead of fatal. ## Why no changes file The net user-visible effect is a routine FMA version bump (Gpg4win 5.1.0), which the scheduled ingest PR delivers without changelog entries. Happy to add one if you'd rather it be called out. # Checklist for submitter - [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] QA'd all new/changed functionality manually Verification performed: - `go run ./cmd/maintained-apps -slug gpg4win/windows` completes with no panic (previously fatal). - Diff is scoped to the two expected files; `outputs/apps.json` is untouched, since name/description didn't change. - Regenerated `sha256` matches a fresh download of the upstream installer. - Install/uninstall scripts need no changes — both already enumerate the native *and* `Wow6432Node` registry views across `HKLM`/`HKCU`, so detection survives the 32→64-bit flip. - `installer_arch` is only a manifest selector plus CI runner routing in `.github/scripts/partition-fma-apps.sh`, where x64/x86/neutral all land on the same x64 runner. No routing change, and the field is never written into `outputs/`, so no user-visible arch claim changes. Still needs the FMA validator's install/uninstall run on a Windows runner to confirm 5.1.0 installs and is detected — that's what the draft is for. |
||
|
Allen Houchins
|
b668734d5c |
Remove Fig FMA (cask removed from Homebrew upstream) (#50483)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA Removes the **Fig** Fleet-maintained app. Its Homebrew cask no longer exists. Homebrew deleted the `fig` cask in [`a36fac3b75`](https://github.com/Homebrew/homebrew-cask/commit/a36fac3b75f633a9c787c4c73fc46606939947a3) on **2026-08-04**, the end of a long deprecation: | Date | Upstream change | |---|---| | 2024-08-03 | `fig: deprecate` | | 2025-08-02 | `fig: disable` | | 2026-08-04 | `fig: remove cask` | `https://formulae.brew.sh/api/cask/fig.json` now returns **404**, so the nightly ingester panics and no maintained apps are generated at all: ``` {"time":"2026-08-04T02:38:58.15272663Z","level":"INFO","msg":"ingesting homebrew app","name":"fig"} panic: ingesting homebrew app: app not found in brew API ``` Note that `"frozen": true` does **not** fix this — that flag only gates the output write, and the ingester still fetches the cask first and panics on the 404. Removing the input is the fix. There is no successor cask to migrate to. Fig was acquired by AWS and folded into Amazon Q Developer CLI, which is not distributed via Homebrew (`amazon-q`, `amazon-q-developer-cli`, `q-cli`, and `codewhisperer` all 404), and `fig.io` itself now returns 503. ### Changes - Deleted `ee/maintained-apps/inputs/homebrew/fig.json` - Deleted `ee/maintained-apps/outputs/fig/darwin.json` - Removed the `fig/darwin` entry from `ee/maintained-apps/outputs/apps.json` - Deleted the `Fig` icon component and its `index.ts` import/map entry - Deleted `website/assets/images/app-icon-fig-60x60@2x.png` The output file is deleted rather than orphaned so the PR validator's changed-app detector doesn't keep validating a removed app. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [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] QA'd all new/changed functionality manually Verified `apps.json` still parses and the `fig/darwin` slug is gone (1390 apps remain, `figma` untouched), `tsc --noEmit` is clean after removing the `Fig` icon import, and no references to `fig`, `com.mschrage.fig`, `fig/darwin`, or `repo.fig.io` remain anywhere in the repo. > [!NOTE] > Existing hosts with Fig installed will no longer see it as a Fleet-maintained app. The app is end-of-life upstream, so there is no version for Fleet to track or patch to. |
||
|
Lucas Manuel Rodriguez
|
f053a9fd49 |
Allow enabling/disabling software inventory per-fleet via the API (#50481)
Resolves #45735. - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. ## Testing - [X] Added/updated automated tests - [x] QA'd all new/changed functionality manually. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Team settings can now enable or disable Software Inventory through API updates. * Partial updates preserve existing settings when the Software Inventory option is omitted. * Software Inventory configuration can be re-enabled after being disabled. * **Bug Fixes** * Invalid or null Software Inventory values are handled correctly without affecting global or Unassigned settings. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Allen Houchins
|
b2b2081ad4 |
Remove Gadwin PrintScreen, PrintScreen Pro, and ScreenRecorder FMAs (expired TLS cert on download host) (#50470)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA Removes the three Gadwin Fleet-maintained apps: **Gadwin PrintScreen**, **Gadwin PrintScreen Pro**, and **Gadwin ScreenRecorder**. All three download their installers from `www.gadwin.com`, whose Let's Encrypt certificate **expired 2026-08-02** and has not been renewed: ``` subject=CN=gadwin.com issuer=C=US, O=Let's Encrypt, CN=R13 notBefore=May 4 13:06:54 2026 GMT notAfter=Aug 2 13:06:53 2026 GMT ``` Every FMA validation run now fails these three apps: ``` level=ERROR msg="Error downloading maintained app: downloading installer: performing request for URL https://www.gadwin.com/download/PrintScreen650_Win64.msi: tls: failed to verify certificate: x509: certificate has expired or is not yet valid" app="Gadwin PrintScreen" ``` This is not just CI: Fleet fetches the installer from that same URL when a user installs the app, so all three are currently uninstallable for customers. > [!NOTE] > The certificate expired only one day before this PR was opened. If Gadwin renews it, these apps become viable again and the alternative fix is `"frozen": true` in each winget input (which skips validation) rather than removal. Removing was chosen because a lapsed auto-renewing certificate means no one is maintaining the download host, and a broken installer URL is worse for users than an absent app. Happy to switch to a freeze if reviewers prefer to wait it out. ### What's removed Per app, all locations that applied: | Location | PrintScreen | PrintScreen Pro | ScreenRecorder | |---|---|---|---| | `ee/maintained-apps/inputs/winget/<slug>.json` | ✅ | ✅ | ✅ | | `ee/maintained-apps/outputs/<slug>/windows.json` | ✅ | ✅ | ✅ | | `ee/maintained-apps/outputs/apps.json` entry | ✅ | ✅ | ✅ | | `frontend/.../icons/<Name>.tsx` | ✅ | ✅ | — (none existed) | | import + mapping in `icons/index.ts` | ✅ | ✅ | — | | `website/assets/images/app-icon-<slug>-60x60@2x.png` | ✅ | ✅ | — (none existed) | All three are Windows-only (no Homebrew input or `darwin.json`), so no macOS counterpart is affected and no shared icons needed to be retained. `apps.json` goes from 1393 to 1390 apps. The diff is deletion-only. # Checklist for submitter - [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] QA'd all new/changed functionality manually Verification performed: - `apps.json` parses as valid JSON; no `gadwin` slugs remain. - Repo-wide grep for `gadwin` returns no dangling references. (The one remaining hit, `cmd/osquery-perf/software-library/software.sql`, is a simulated host-inventory fixture, not an FMA definition — intentionally left in place.) - `npx tsc --noEmit` reports no errors related to the removed icon components or the icon index. - `npx prettier --check` passes on `icons/index.ts` and `apps.json`. - `go build ./cmd/maintained-apps/... ./ee/maintained-apps/...` and `go test ./ee/maintained-apps/...` pass. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Removed Gadwin PrintScreen, Gadwin PrintScreen Pro, and Gadwin ScreenRecorder from the maintained Windows application catalog. * Removed their associated software listings, installation details, and product icons from the application interface. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Allen Houchins
|
2431d580b0 |
Add QEMU as a Windows Fleet-maintained app (#50471)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #50126 Adds **QEMU** (`SoftwareFreedomConservancy.QEMU`) as a Windows Fleet-maintained app, requested by a customer in #50126. Windows-only: on macOS, Homebrew ships QEMU as a formula (CLI tools, no `.app` bundle), so it isn't a viable macOS FMA. ## App identity (verified against the real installer) - Downloaded `qemu-w64-setup-20260501.exe` from `qemu.weilnetz.de`; SHA256 matches the winget manifest. - QEMU's NSIS definition ([`qemu.nsi`](https://gitlab.com/qemu-project/qemu/-/blob/master/qemu.nsi)) writes the uninstall key `HKLM\...\Uninstall\QEMU` (64-bit view via `SetRegView 64`) with `DisplayName "QEMU"` and `DisplayVersion` set to the meson project version — which equals the winget `PackageVersion`, so the patch policy reconciles cleanly. - **No `Publisher` value is written to the registry**, so the default generated exists query (`... AND publisher = 'QEMU Community'`) would never match. The input overrides it with `exists_query: SELECT 1 FROM programs WHERE name = 'QEMU';` — exact name match, so entries like "QEMU guest agent" (virtio-win) are left alone. ## Install/uninstall scripts - NSIS installer, machine scope, x64. Install: standard silent `/S` (same pattern as AnyBurn). - Uninstall: registry lookup by exact DisplayName across both registry views, defensive UninstallString parsing, `/S _?=<installdir>` so the uninstaller runs in place (instead of relaunching from `%TEMP%` and returning immediately), verification that the ARP entry is actually gone, then sweep of the leftover uninstaller/install dir, `HKLM\SOFTWARE\QEMU`, and shortcuts. ## Version caveat winget's newest version dir for this package is **11.0.50 — a QEMU development snapshot** (QEMU uses `x.y.50` for post-release dev builds; only x64, no arm64), added upstream alongside the 11.0.0 stable release. The ingester picks the highest version, so this FMA currently ships the snapshot build; it will move to the next stable (e.g. 11.0.1/11.1.0) as soon as winget has it. The installer URL is date-pinned (`.../2026/qemu-w64-setup-20260501.exe`), so there's no hash-drift risk. If we'd rather not offer dev snapshots, that needs an ingester-level version filter — flagging for maintainer input rather than building it into this PR. ## Icon Official 128×128 QEMU icon from the upstream source tree (`ui/icons/qemu_128x128.png`), generated via `tools/software/icons/generate-icons.sh`. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] Verified installer SHA256, registry identity (DisplayName/DisplayVersion/no Publisher), and silent switches against the real installer and upstream `qemu.nsi`/`meson.build` - [ ] `test-fma-windows-pr-only` validates QEMU install/uninstall in this PR's CI <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added QEMU to the Windows software catalog. * Added support for silent QEMU installation and reliable uninstallation. * Added QEMU version detection and upgrade validation. * Added a QEMU icon to the software interface. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Allen HouchinsandClaude
|
bbbe93d1b7 |
Bump Zoom Rooms FMA (custom-tap) to 7.1.5.13403 (#50442)
**Related issue:** NA — routine custom-tap cask maintenance # Checklist for submitter - [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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] `go test ./ee/maintained-apps/...` passes - [ ] QA'd all new/changed functionality manually (installer metadata, URL, and checksum verified as below; not yet deployed through a Fleet server) No `changes/` file, consistent with prior custom-tap cask-bump PRs (#49563, #48028, #45912). ## Version bump details | | Old | New | |---|---|---| | Version | 7.1.0.13088 | 7.1.5.13403 | - **Upstream source:** `https://zoom.us/client/latest/ZoomRooms.pkg` redirects to `https://cdn.zoom.us/prod/7.1.5.13403/ZoomRooms.pkg` (Zoom does not expose a parseable Zoom Rooms version feed, per the cask's `livecheck` block, so this is the standard manual-bump discovery method). - **New download URL:** `https://cdn.zoom.us/prod/7.1.5.13403/ZoomRooms.pkg` - **sha256:** `3b303bc150a3a5d639f09439abf84f2117784a2124ba660f7c73917ba5ef9ab6` - Downloaded installer verified: 587 MB, `xar archive` (matches expected `.pkg` format). **Reviewer note:** `api/zoom-rooms.json` was updated mechanically because `regenerate.sh` requires macOS. Before merging, run `ee/maintained-apps/inputs/homebrew/custom-tap/regenerate.sh` locally and confirm `git diff` is clean for `api/zoom-rooms.json`. --- _Generated by [Claude Code](https://claude.ai/code/session_01U8YEGYFy9Uc88wvyg96ySE)_ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Updated Zoom Rooms for macOS to version 7.1.5.13403. * Refreshed download links and package verification checksums. * Installation and uninstallation behavior remains unchanged. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Allen Houchins
|
183aa052d2 |
Defuse Docker Desktop's install-on-quit updater in macOS FMA install script (#50451)
**Related issue:** Customer reports of failed Docker Desktop updates from self-service on macOS. ## Details The reported error is Docker Desktop's own updater speaking, not Fleet's: ``` failed to back up /Applications/Docker.app before update: renaming (moving) file from /Applications/Docker.app to /Applications/Docker.app.back: rename /Applications/Docker.app /Applications/Docker.app.back: file exists ``` Hosts showing "update available" in self-service are exactly the hosts where Docker Desktop has already downloaded and staged its **own** self-update at `~/Library/Application Support/com.docker.install/in_progress/Docker.app`. When the FMA install script gracefully quits Docker Desktop, that quit triggers Docker's install-on-quit updater, which renames `Docker.app` → `Docker.app.back` and moves the staged copy into place — racing the script's own `mv`/`rm`/`cp` of `/Applications/Docker.app`. The script previously cleaned up after this race (leftover `.back` bundle and staged copy); this PR prevents it instead: - Remove the entire `com.docker.install` staging directory (staged bundle + updater state) **before** quitting the app, so the quit can't trigger Docker's updater. Same whole-directory removal the uninstall's `post_uninstall_scripts` already does. - Wait out (bounded, 30s) any updater already in flight before touching `/Applications/Docker.app`. - Output regenerated via `go run ./cmd/maintained-apps -slug docker-desktop/darwin`; version pinned at 4.85.0, installer URL/sha unchanged, only the install script ref changed. Hosts already wedged with a stale `Docker.app.back` self-heal: the script still removes `.back` before copying the new bundle. ## Local validation (macOS arm64, Docker Desktop 4.84.0 running) - shellcheck and `bash -n` clean; embedded output script matches input byte-for-byte with correct sha256[:8] ref - Downloaded the pinned 4.85.0 DMG; sha256 matches the manifest - Seeded affected-host state (non-empty `/Applications/Docker.app.back`, staged `com.docker.install/in_progress/Docker.app`) and ran the shipped script: staging dir removed before quit, running Docker Desktop (VM + active build) quit gracefully, wait loop did not hang - Wait loop unit-tested against a live process matching `com\.docker\.install`: waits until it exits, 30s cap # Checklist for submitter If some of the following don't apply, delete the relevant line. - [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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] QA'd all new/changed functionality manually |
||
|
Allen Houchins
|
89acb97395 |
Add NVDA as a Windows Fleet-maintained app (#50450)
**Related issue:** Resolves #50125 Adds NVDA as a Windows Fleet-maintained app, from winget `NVAccess.NVDA` (2026.1.1, NSIS/nullsoft, x86 launcher). ## Identity — read out of the shipped installer, not the manifest I downloaded the 60 MB installer, extracted the NSIS payload, and read the identity fields from `_buildVersion.pyc` and the PE headers. The winget manifest is misleading in two ways: | Field | winget says | Actually is | Source | |---|---|---|---| | Architecture | `x86` | **x64** app behind a 32-bit NSIS launcher stub | `nvda_noUIAccess.exe` / `nvda_slave.exe` PE headers | | Registry DisplayName | PackageName `NVDA` | **`NVDA 2026.1.1`** | `source/installer.py` `getUninstallerRegInfo()`: `DisplayName=f"{name} {version}"` | | Publisher | `NV Access` | `NV Access` (matches) | `_buildVersion.pyc`: `publisher = "NV Access"` | Two consequences: - Because NVDA itself is a **64-bit** process, it registers under the native registry view, **not** `Wow6432Node` (the launcher's 32-bit-ness is irrelevant). Both scripts check both views anyway, for legacy 32-bit copies. - DisplayName carries the version, so this needs `fuzzy_match_name: true` → `name LIKE 'NVDA %'`. Publisher matches the locale manifest, so no `program_publisher` override. `installer_arch` stays `x86` because that's what the manifest declares and the ingester matches on it. ## Version reconciles without a validator exception DisplayVersion is the 4-part `2026.1.1.55980` (`version_detailed`) against winget's `2026.1.1`: - **Validator:** passes via the existing `strings.HasPrefix(result.Version, appVersion+".")` branch in `cmd/maintained-apps/validate/windows.go`. No new skip added — deliberately, since existence-only skips make patch policies always report "patched". - **Patch policy:** `version_compare('2026.1.1.55980', '2026.1.1')` is `> 0`, so an installed copy reads as newer, not outdated. No perpetual false "update available". ## The install script can't trust the exit code `source/gui/installerGui.py` `doInstall()` pops `winUser.MessageBox` / `gui.messageBox` on **every** install failure path with **no `if silent` guard**, and then falls through and exits **0**. Under SYSTEM in session 0 that means: 1. a failure **hangs forever** — nobody can click Retry/Cancel; and 2. if it were dismissed, a failed install would report **success**. So `nvda_install.ps1` uses a watchdog plus an Add/Remove Programs registration poll as the real success signal — the same shape as the existing `azure_data_studio_install.ps1`. Timeouts are 420 + 120 + 30 = 570s, under the caller's 10-minute cap. On timeout it kills only the launcher's `%TEMP%` children (`nvda_noUIAccess` / `nvda_uiAccess`), **deliberately not `nvda.exe`** — an installed NVDA runs as `nvda.exe`, and force-killing it would cut off a signed-in user's screen reader with no warning. ## Uninstall Vendor-documented `/S` (NVDA user guide, "Uninstalling NVDA"), plus `_?=` last so the NSIS uninstaller runs in place instead of relaunching from `%TEMP%` and returning immediately. NVDA writes **no** `QuietUninstallString`, and its `UninstallString` is an **unquoted path containing spaces** (`C:\Program Files\NVDA\uninstall.exe`), so the parser handles that form. The directory comes from NVDA's `InstallDir` value (not `InstallLocation`). Absence of the ARP entry is the success signal, since NVDA removes it via `nvda_slave.exe unregisterInstall`. ## Reviewer notes - **`installer_scope` is `""`, not `"machine"`.** NVDA genuinely installs machine-wide (`%ProgramFiles%\NVDA` + HKLM), but the winget manifest declares no `Scope`, so the ingester derives `""` and `"machine"` panics with "failed to find installer". The one-line ingester fix for this is designed in #48248 but isn't in `main`; I chose not to change shared installer-selection code for a single-app addition. Happy to land that fix here instead if preferred. - **Upgrade caveat:** if NVDA is running for a signed-in user, `--install-silent` refuses to overwrite its own running files by design (`installer.py` `install()`). The script fails with an actionable message rather than force-killing the screen reader. - Installer URL is version-pinned (`download.nvaccess.org/releases/2026.1.1/...`), not a "latest" redirect. SHA verified against my own download of the file. # Checklist for submitter - [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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [ ] QA'd all new/changed functionality manually `go test ./ee/maintained-apps/...` passes; prettier and `tsc --noEmit` are clean. I have no Windows host or `pwsh`, so **the install/uninstall scripts are unexercised** until FMA validation CI runs them on a Windows runner. No changes file — consistent with other FMA additions (#50415, #50348, #50352). |
||
|
Allen Houchins
|
51044325e7 |
Treat MSI reboot-required exit codes as success and quote the msiexec log path (#50407)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA ## What & why Two independent defects in the default MSI scripts. Neither has any server-side handling, so the script text is the only place either can be fixed. ### 1. Reboot-required exit codes reported as install failures The default MSI install script (`pkg/file/scripts/install_msi.ps1`) ended with `Exit $installProcess.ExitCode`, passing msiexec's raw exit code straight through. An install that **succeeded but requested a reboot** therefore reported as a failed install: - `3010` — `ERROR_SUCCESS_REBOOT_REQUIRED` - `1641` — `ERROR_SUCCESS_REBOOT_INITIATED` Both default MSI *uninstall* scripts (`uninstall_msi.ps1` and `uninstall_msi_with_upgrade_code.ps1`) already carve these out via `$successCodes = @(0, 3010, 1641)` — install was the only MSI script missing it. This change adds the same check, using the identical idiom and comment wording as the uninstall scripts. ### 2. Unquoted log file path in the `/lv` argument The default MSI install and remove scripts passed the log path unquoted: ```powershell -ArgumentList "/quiet /norestart /lv ${logFile} /i `"${env:INSTALLER_PATH}`"" ``` `Start-Process` appends a single-string `-ArgumentList` to the command line verbatim — it adds no quoting of its own. `${env:INSTALLER_PATH}` was already protected by escaped quotes; `${logFile}` was not. So when `TEMP` contains a space, msiexec tokenizes the path on whitespace: `/lv` receives only the chunk up to the first space (`C:\Users\John`), and the remainder (`Smith\AppData\...\fleet-install-software.log`) is left as a stray token, which msiexec rejects as an invalid command line (`1639`). The install fails outright rather than merely writing its log somewhere unexpected. The fix quotes it the way `${env:INSTALLER_PATH}` already was: ```powershell -ArgumentList "/quiet /norestart /lv `"${logFile}`" /i `"${env:INSTALLER_PATH}`"" ``` **On severity:** this is latent under normal fleetd operation. Install scripts inherit `os.Environ()` from orbit (`orbit/pkg/installer/installer.go`), which runs as a LocalSystem service, so `TEMP` is `C:\Windows\TEMP` — no spaces. It bites when the system `TEMP` is redirected to a path containing a space, or when an admin copies the script (Fleet renders it in the UI) and runs it in a user context whose profile name contains a space. Not reproduced on a Windows host; the analysis is from msiexec's whitespace tokenizing, not from an observed failure. The newer hand-written FMA scripts (`mozilla-vpn_install.ps1`, `egnyte_install.ps1`, `vnc-server_install.ps1`, `vnc-viewer_install.ps1`, `agent-ransack_install.ps1`) already used the quoted form. This brings the older ones in line with them. ## Scope `GetInstallScript("msi")` feeds two paths, both fixed by change 1: 1. The default install script for **user-uploaded MSI packages** (`ee/server/service/software_installers.go`). 2. The generated install script for **MSI-based Fleet-maintained apps** (`ee/maintained-apps/ingesters/winget/ingester.go`). Change 2 additionally covers `remove_msi.ps1` (the uninstall script used for packages added before the uninstall feature shipped) and the nine hand-written winget install scripts that still carried the unquoted form: `azure-functions-core-tools`, `bluej`, `crisisgo`, `delinea-connection-manager`, `geogebra-classic`, `google-ads-editor`, `gotomeeting`, `imageglass`, `sourcetree`. Notes: - **FMA outputs are not regenerated here.** `install_script_ref` is content-addressed, and existing `outputs/*/windows.json` files carry both the ref and the script text, so they stay internally consistent. The ingest workflow runs every 4 hours and will roll the refs for MSI-based apps forward on its own. Regenerating them in this PR would produce a huge diff and trigger Windows FMA validation for every MSI app. - Several per-app FMA install scripts exist **only** to add the exit-code carve-out and become redundant once this lands (for example `scribe_install.ps1` from #50341). They are harmless duplicates of the new default and can be removed in follow-up. Per-app scripts that do other work too (e.g. `delinea-connection-manager_install.ps1` forcing `ALLUSERS=1`) still need to keep their own copy — those got the quoting fix instead. - Neither change applies to `uninstall_msi.ps1` or `uninstall_msi_with_upgrade_code.ps1`: they already handle the reboot codes, and they build `-ArgumentList` as an array with no `/lv` argument at all. - `install_exe.ps1` deliberately left alone — EXE installers have no standard exit-code convention, which is why they use per-app scripts. - The per-app example scripts embedded in `articles/` (CrowdStrike, Cloudflare WARP, SentinelOne) are separate copy-paste content and are not touched. # Checklist for submitter - [ ] 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. No changes file is currently in this PR — the earlier one was removed. Both fixes change user-visible install/uninstall outcomes, so one may be warranted before merge. - [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. Change 2 is precisely this: a path interpolated into a command line is now quoted so whitespace can't split it into extra arguments. ## Testing - [x] Added/updated automated tests `pkg/file`'s golden test (`TestGetInstallAndRemoveScript`) covers the script contents; each script and its golden were changed in lockstep, so they remain byte-identical. `go test ./pkg/file/ -run Script` and `go test ./ee/server/service/ -run TestGetInstallScript` pass. Goldens can be regenerated with `go test ./pkg/file/... -update`. - [ ] QA'd all new/changed functionality manually Not QA'd on a Windows host. Change 1 needs an MSI that returns 3010 under Fleet's SYSTEM context to confirm the install now reports success. Change 2 needs an MSI install run with `TEMP` pointed at a path containing a space. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved MSI installation and removal reliability when log-file paths contain spaces. * MSI installations requiring a restart are now recognized as successful. * Standard MSI success and restart-required results are handled consistently while other errors remain available for troubleshooting. * Updated supported application installers to use the more reliable logging behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
fleet-releaseandallenhouchins
|
5111bd9fb2 |
Update Fleet-maintained apps (#50439)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Updates** - Updated AdLock to version 2.1.9.2. - Updated AlDente to version 1.38.1. - Updated Cherry Studio to version 1.9.13. - Updated Docker Desktop to version 4.85.0. - Updated Elgato Camera Hub to version 2.3.0.7286. - Updated Firefox Nightly, Granola, and Hubstaff to their latest available macOS releases. - Refreshed download packages, checksums, and version detection for the updated applications. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> |
||
|
kitzyandAllen Houchins
|
4036f9bfcb |
Add Microsoft ODBC Driver 18 for SQL Server as a Windows Fleet-maintained app (#50348)
**Related issue:** Resolves #50327 Adds Microsoft ODBC Driver 18 for SQL Server as a Windows Fleet-maintained app, from winget `Microsoft.msodbcsql.18` (18.6.2.1, MSI, machine scope, x64, en-US). Sibling of #50342 (driver 17); the two install side by side and are separate products. ## Verification Identity read from the MSI Property table: ``` ProductName Microsoft ODBC Driver 18 for SQL Server Manufacturer Microsoft Corporation ProductCode {820A3DEC-9783-42AE-B12D-750FCCF07E10} UpgradeCode {ADA68B65-BFF8-4E6A-B082-CC6682D425B8} ALLUSERS 1 ``` - Installer SHA confirmed against a local download (`20314529…4b82`). - The UpgradeCode differs from driver 17's (`{0123A210-…}`), which confirms they are independent products rather than upgrades of one another. The generated uninstall script picked up 18's, so uninstalling one will not touch the other. - Because `ProductName` already carries the major version, the exists query is a simple equality — no `version LIKE '18.%'` pinning needed, and no risk of 17 and 18 matching each other. Like driver 17, the MSI refuses to install without `IACCEPTMSODBCSQLLICENSETERMS=YES`, which Fleet's default MSI script does not pass, so this ships a small custom install script. It is deliberately a **separate file** from driver 17's rather than a shared path, following the repo's one-script-per-app convention and keeping the two PRs independently mergeable. The icon comes from the MSI's own `ARPPRODUCTICON` stream. As with #50342 it is natively 32×32, so the 128×128 asset is an upscale — happy to drop it in favour of the generic fallback if reviewers prefer. The icon map key also needed the same manual correction (the generator derives it from the slug, which omits "for sql server"). The manifest declares a `Microsoft.VCRedist.2015+.x64` dependency, which the ingester ignores; we ship `vc-redist-x64/windows` and the redistributable is present on most hosts. # Checklist for submitter - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added Microsoft ODBC Driver 18 for SQL Server to the maintained Windows software catalog. * Added support for version 18.6.2.1, including installation, upgrade, uninstall, detection, and license acceptance handling. * Added the software’s icon and catalog display details. * Included support for SQL Server and Azure SQL connectivity scenarios. * Installation now provides appropriate handling for successful completion, restart requirements, and installation failures. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Allen Houchins <allenhouchins@mac.com> |
||
|
fleet-releaseandallenhouchins
|
3734c28980 |
Update Fleet-maintained apps (#50433)
Automated ingestion of latest Fleet-maintained app data. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Updated available versions and download metadata for 20 maintained applications across macOS and Windows. * Included the latest releases for Antigravity, Postman, Zoom Rooms, NordVPN, Wavebox, and others. * **Bug Fixes** * Improved CrystalDiskMark installation validation and ensured stalled uninstall processes terminate safely. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: allenhouchins <32207388+allenhouchins@users.noreply.github.com> |
||
|
Allen HouchinsandClaude
|
a586a53f9a |
Unfreeze Adobe Acrobat Pro (macOS) (#50402)
Automated unfreeze probe. Removes `"frozen": true` and regenerates the output manifest so `test-fma-darwin-pr-only` can validate `adobe-acrobat-pro/darwin` at its current upstream version. Frozen since: 2026-06-23 (#48089, automated FMA update run) Version: 26.001.21691 -> 26.001.21771 Upstream Homebrew reports 26.001.21771, newer than the pinned 26.001.21691 that #50370 set from the delivered installer, so this is a genuine forward bump rather than a regression. The cask uses a stable "latest" download URL with `sha256: no_check`, so the regenerated diff is version and `patched` query only. Draft until validation reports. Merge only if the FMA checks are green and the validate shard actually ran for this slug. <!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA # Checklist for submitter - [x] QA'd all new/changed functionality manually — pending CI validation, see above. --- _Generated by [Claude Code](https://claude.ai/code/session_01LvsXk65MD2s93jeGJuHAk5)_ Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Victor Lyuboslavsky
|
98060b08a6 |
Add Windows managed local account server flow (#48721) (#49924)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #48721 Part 2 of https://github.com/fleetdm/fleet/issues/43488 # Checklist for submitter - [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] QA'd all new/changed functionality manually ## Database migrations - [x] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Windows devices can now create and securely escrow managed local account passwords during enrollment. * Added Windows managed local account status and password availability to host details. * Device-reported setup errors are surfaced with helpful details. * Account creation is automatically requested when supported by the device, plan, and configuration. * **Bug Fixes** * Windows accounts are excluded from password rotation workflows. * Re-enrollment correctly triggers account creation when needed. * Passwords remain available when settings change after enrollment. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Allen Houchinsandcoderabbitai[bot]
|
a4d058384c |
Add CrystalDiskMark as a Windows FMA (#50415)
**Related issue:** Resolves #50322 Adds CrystalDiskMark as a Windows Fleet-maintained app, from winget `CrystalDewWorld.CrystalDiskMark` (9.0.3, Inno Setup, machine scope, x64). Found in a customer's ManageEngine ServiceDesk Plus Windows deployment catalog with no Fleet equivalent. ## Identity — read out of the Inno header, not the manifest The winget manifest carries no `AppsAndFeaturesEntries`, so the ARP identity had to come from the installer itself. I LZMA-decompressed the Inno setup-data block and read the header directly: | Header field | Value | |---|---| | `AppName` | `CrystalDiskMark` | | `AppVerName` | `CrystalDiskMark 9.0.3` | | `AppVersion` | `9.0.3` | | `AppPublisher` | `Crystal Dew World` | | `AppId` | `CrystalDiskMark9` | | `UninstallDisplayName` | *(empty)* | | `DefaultDirName` | `{pf}\CrystalDiskMark9` | With `UninstallDisplayName` empty, Inno falls back to `AppVerName` for the ARP `DisplayName` — so this registers as **`CrystalDiskMark 9.0.3`**, version-suffixed, and the exists query is a prefix match (`fuzzy_match_name: true`). That the name is version-suffixed isn't inferred from "Inno usually does this." The Aoi edition's header sets `AppVerName` to `CrystalDiskMark 9.0.3 Aoi Edition` while its `AppName` is `CrystalDiskMark Aoi Edition` — the compiler's synthesized default would have been `CrystalDiskMark Aoi Edition 9.0.3`, so the script is setting `AppVerName` deliberately, and Setup will write exactly that string. `AppPublisher` matches the winget locale `Publisher` verbatim, so no `program_publisher` override is needed, and `DisplayVersion` is `AppVersion` = `9.0.3`, which reconciles with the FMA version with no validator exception. Generated query: ```sql SELECT 1 FROM programs WHERE name LIKE 'CrystalDiskMark %' AND publisher = 'Crystal Dew World'; ``` ## Silent flags — the `[Run]` entries were decoded, not assumed The header contains three `[Run]` entries with `{cm:LaunchProgram,CrystalDiskMark9}` descriptions (one per architecture), which is exactly the shape that has hung silent Inno installs for us before. I parsed the entry structure through to the flag bytes: - wait enum = `1` → `nowait` - flags = `0x14` → bit 2 `postinstall` + bit 4 `skipifsilent` So `/VERYSILENT /SUPPRESSMSGBOXES /NORESTART` will not launch the GUI, and there is no post-install hang to work around. The install script still uses the poll-and-kill wrapper rather than `-Wait`, plus an ARP-registration wait, since the installer can return before the registry entry lands. `/ALLUSERS` is deliberately omitted: `DefaultDirName` is `{pf}`, which requires admin install mode already, so the switch would be a no-op. ## Uninstall `UninstallString` is Inno's quoted `unins000.exe` path, but the script uses the three-branch defensive parser (quoted / unquoted-with-spaces / bare token) anyway. Two app-specific bits: - The 12 `DiskMark*.exe` binaries are stopped first — the uninstaller won't proceed while the `CrystalDiskMark9` mutex is held. - The script waits for the registry entry to disappear rather than trusting the exit code. Inno's uninstaller relaunches itself from a temp copy and the original process returns early, so its exit code is not a completion signal. ## Icon The setup exe's `MAINICON` is Inno's stock CD-and-box artwork, not the app's, so the icon was extracted from `DiskMark64.exe`'s own resources (`innoextract` → `wrestool -t 14 -n 130` → `icotool`, 256×256 32-bit). ## Two things for reviewers 1. **This carries a shared-code change to the winget ingester** (`normalizeSourceForgeURL`). A bare SourceForge project file URL serves non-browser clients a 133KB HTML landing page with a 200, so the first validator run downloaded that instead of the installer and failed on the hash. Only the `.../download` form serves the binary. WinSCP works today only because its manifest happens to carry the suffix, so the fix normalizes in the ingester rather than depending on manifest authors. WinSCP regenerates byte-identical and is the only other SourceForge-hosted app in the catalog; `TestNormalizeSourceForgeURL` covers both shapes. Details in [this comment](https://github.com/fleetdm/fleet/pull/50415#issuecomment-5162501140). 2. **The Aoi and Shizuku editions share this package's `AppId` and install directory.** They occupy the same ARP slot (`CrystalDiskMark9_is1`), can't be co-installed, and will match the exists query as `CrystalDiskMark 9.0.3 <Edition>`. I treated that as correct rather than something to exclude — it is the same product at the same version — but flagging it in case we'd rather pin to the plain edition. ## Verification - Inno header dumped offline; `AppVerName` / `AppPublisher` / `AppVersion` read directly, `[Run]` flag bytes decoded. - Generated SHA matches the winget installer manifest (`1a255154…917e5e`), and the download was verified through the exact code path the validator uses (`maintained_apps.DownloadInstaller` with `http.DefaultClient`) — 4,523,144 bytes, hash matches. - `apps.json` valid, description filled, icon generated and inserted alphabetically in `index.ts` under the key `crystaldiskmark`. - `go test ./ee/maintained-apps/...` passes; `GOOS=windows go build ./cmd/maintained-apps/validate/` builds; `gofmt`/`go vet` clean. `make lint-go-incremental` could not run in my environment (`custom-gcl` fails to clone golangci-lint, pre-existing and unrelated). - First validator run failed on the download issue above and is fixed; the full validator pass (install → detect → uninstall on a Windows host) still needs to go green before this leaves draft. # Checklist for submitter - [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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [ ] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added CrystalDiskMark as a supported Windows application, including installation, uninstallation, detection, categorization, and software catalog details. * Added CrystalDiskMark branding to the software interface. * Improved SourceForge installer URL handling by automatically appending download paths when needed. * **Bug Fixes** * Preserved existing download URLs, query parameters, and unsupported or malformed URLs during normalization. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> |
||
|
Luís Teles
|
1dc1a51313 |
Fix Windows Git FMA patch policy never detecting outdated installs (#50424)
**Related issue:** Resolves #50283 Git for Windows registers itself in the Windows uninstall registry as exactly `Git` — its Inno Setup script has set `UninstallDisplayName={#APP_NAME}` since [build-extra#365](https://github.com/git-for-windows/build-extra/pull/365) (2021). The generated queries matched `programs.name LIKE 'Git %'`, which cannot match that name, so the patch policy's `NOT EXISTS (...)` was always true and every host reported `Pass` regardless of installed version — update automations never fired. The same mismatch meant an existing Git install couldn't be matched to the maintained app. The input now uses the custom fuzzy pattern `Git%`, which also covers the pre-2021 `Git <version>` DisplayName form (the oldest installs, which are exactly what a patch policy needs to flag), and relies on the existing `publisher = 'The Git Development Community'` guard to exclude GitHub Desktop, Git LFS, GitKraken and Git Extensions. This is the same match the app's own uninstall script and the FMA Windows CI workflow already use. Instances that already created this policy pick up the corrected query when the next Git version becomes active, since the patch policy query is regenerated from the active installer. # Checklist for submitter - [x] Changes file added for user-visible changes in `changes/`. ## Testing Verified the `LIKE` semantics in SQLite against real-world `programs` rows (old pattern misses `Git`, new pattern matches both DisplayName forms, publisher guard still excludes GitHub Desktop / Git LFS / GitKraken / Git Extensions), and confirmed winget's `PackageVersion` matches the registry `DisplayVersion` for Git so up-to-date hosts still pass. `outputs/git/windows.json` was regenerated with the ingester rather than hand-edited. Not manually QA'd on a Windows host — relying on `test-fma-windows` validation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved Git for Windows detection across supported environments. * Outdated installations can now be correctly identified and included in update automation, including registrations named “Git.” * Existing publisher and version checks remain unchanged. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
