Files

T

Allen Houchins 4303188e2d Update custom-tap casks: Druva inSync 8.1.3, Fleet Desktop 1.3.4, Zoom Rooms 7.1.0.13088 (#49563 )

**Related issue:** NA — routine custom-tap cask maintenance

## What

Bump three custom-tap casks to their latest upstream releases and
regenerate the api JSONs (`regenerate.sh`) and FMA output manifests (`go
run cmd/maintained-apps/main.go --slug=<token>/darwin`):

| Cask | Old | New |
|------|-----|-----|
| Druva inSync | 7.6.1 (r110931) | 8.1.3 (r110967) |
| Fleet Desktop | 1.3.2 | 1.3.4 |
| Zoom Rooms | 7.0.5.12655 | 7.1.0.13088 |

XCreds 5.9 (9148) is still the latest upstream release and is unchanged.

## Why / reviewer notes

- **Druva:** the 8.0.0 phased rollout never reached the public CDN (its
`.dmg` 404'd since March); 8.1.3 is the first 8.x build served from
`downloads.druva.com`. Druva 8.x officially supports macOS 14 (Sonoma)+
only, so `depends_on` moves from `:big_sur` to `:sonoma` (informational
— the ingester doesn't read it).
- **`api/xcreds.json` +2 lines with no cask change:** `regenerate.sh`
rebuilds all api JSONs, and current Homebrew now emits
`pinned`/`pinned_version` fields. Expected drift; anyone running the
script gets the same output.
- **Verification done against the downloaded installers:**
- sha256 values computed locally from the actual downloads; the Druva
download's SHA1 matches the checksum published on Druva's download page.
- Installer internals inspected: the Druva dmg still contains `Install
inSync.pkg`, and pkg receipt IDs are unchanged across all three
(`com.druva.inSync.pkg` @ 8.1.3, `com.fleetdm.fleet-desktop` @ 1.3.4,
`us.zoom.pkg.zp` @ 7.1.0.13088), so existing install/uninstall stanzas
remain valid.
- No `changes/` file, consistent with prior cask-bump PRs (#45912,
#48028) and the automated FMA-ingestion PRs.

# 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] `go test ./ee/maintained-apps/...` passes
- [ ] QA'd all new/changed functionality manually (installer metadata,
URLs, and checksums verified as above; not yet deployed through a Fleet
server)

2026-07-20 09:43:37 -05:00

api

Update custom-tap casks: Druva inSync 8.1.3, Fleet Desktop 1.3.4, Zoom Rooms 7.1.0.13088 (#49563 )

2026-07-20 09:43:37 -05:00

Casks

Update custom-tap casks: Druva inSync 8.1.3, Fleet Desktop 1.3.4, Zoom Rooms 7.1.0.13088 (#49563 )

2026-07-20 09:43:37 -05:00

README.md

…

regenerate.sh

…

README.md

Fleet custom-tap casks

This directory is a self-contained source of truth for Fleet-maintained apps that don't exist in Homebrew/homebrew-cask and therefore can't be ingested from https://formulae.brew.sh/api/.

It is laid out like a Homebrew tap:

custom-tap/
├── Casks/                # Cask DSL sources (.rb). Edit these.
│   ├── fleet-desktop.rb
│   └── druva-insync.rb
├── api/                  # Generated cask metadata (.json). Do not hand-edit.
│   ├── fleet-desktop.json
│   └── druva-insync.json
├── regenerate.sh         # Regenerates api/*.json from Casks/*.rb.
└── README.md             # You are here.

It is not a real Homebrew tap — the Fleet repo isn't named homebrew-<something> and Casks/ isn't at the repo root, so brew tap / brew install against it won't work. It exists solely to feed Fleet's FMA ingester, and keeping both the source (.rb) and the built artifact (.json) in the same repo means the PR that changes a cask also tests the change in CI.

How it hooks into the FMA ingester

Each app here has an input manifest one directory up (../<token>.json) with a cask_path field pointing at the generated JSON. Example — ../fleet-desktop.json:

{
  "name": "Fleet Desktop",
  "token": "fleet-desktop",
  "cask_path": "ee/maintained-apps/inputs/homebrew/custom-tap/api/fleet-desktop.json",
  ...
}

When go run cmd/maintained-apps/main.go runs, the ingester sees cask_path, reads the local file, and skips the brew API entirely. Apps without cask_path continue to use https://formulae.brew.sh/api/ as before.

Adding a new cask

Write the cask DSL in Casks/<token>.rb. Use an existing file or https://docs.brew.sh/Cask-Cookbook as a reference.
Run ./regenerate.sh in this directory to produce api/<token>.json.
Create an input manifest at ee/maintained-apps/inputs/homebrew/<token>.json that points cask_path at the new JSON. Follow the template in ../fleet-desktop.json.
Generate the FMA output manifest: go run cmd/maintained-apps/main.go --slug="<token>/darwin" from the repo root.
Follow the rest of the FMA contributor flow in ../../../README.md (apps.json description, icon, PR).

Updating an existing cask

Edit the stanza you care about in Casks/<token>.rb.
Run ./regenerate.sh to refresh api/<token>.json.
Regenerate the FMA output manifest: go run cmd/maintained-apps/main.go --slug="<token>/darwin".
Commit all three changes together: the .rb, the .json, and the outputs/<token>/darwin.json.

Why `regenerate.sh` strips fields

brew info --cask --json=v2 includes several fields that depend on the developer's machine or the throwaway tap the script uses internally — installed, installed_time, outdated, full_token, tap, tap_git_head, generated_date. None of these are read by the FMA ingester, so the script strips them to keep committed JSON stable across machines.

Requirements

macOS (the .rb DSL is parsed by Homebrew).
Homebrew installed (brew on PATH).
jq (brew install jq).

README.md

Fleet custom-tap casks

How it hooks into the FMA ingester

Adding a new cask

Updating an existing cask

Why regenerate.sh strips fields

Requirements

Why `regenerate.sh` strips fields