2fd2a02e2d71b65e19bd06f97d14186866f514b7
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Lucas Manuel Rodriguez
|
703dcf0b4f |
Update go to 1.26.5 (#48993)
Resolves #48988. I ran `make update-go version=1.26.5`. - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. ## Testing - [X] QA'd all new/changed functionality manually Fleet: <img width="301" height="102" alt="Screenshot 2026-07-09 at 8 41 49 AM" src="https://github.com/user-attachments/assets/baf76ce7-6192-4506-a9db-52f5318939ee" /> fleetctl: ``` fleetctl --version fleetctl - version orbit-v1.57.0-402-ge3d0c005dc branch: 48988-update-go-1.26.5 revision: e3d0c005dc6698c024ad47a124c99e4f264855a0 build date: 2026-07-09 build user: lucas go version: go1.26.5 ``` Also verified orbit in Linux: <img width="582" height="121" alt="Screenshot 2026-07-09 at 8 51 55 AM" src="https://github.com/user-attachments/assets/65672676-8010-45a1-8c28-9f9959e72134" /> ## fleetd/orbit/Fleet Desktop - [X] Verified compatibility with the latest released version of Fleet (see [Must rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md)) - [X] Verified auto-update works from the released version of component to the new version (see [tools/tuf/test](../tools/tuf/test/README.md)) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated the project and all included tooling modules to Go 1.26.5. * Refreshed build images used by desktop Linux, load testing, and related utilities to the newer Go toolchain. * Updated change log entries to reflect the Go version bump. * **Bug Fixes** * Improved the automation that refreshes Go-pinned Docker image references to resolve and apply correct digests, helping prevent broken build images. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
George Karr
|
af51636bda |
tools: bump x/net and x/crypto to clear high-severity CVE alerts (#48822)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** NA — resolves high-severity code-scanning alerts in `tools/` Bumps the outdated `golang.org/x/net` and `golang.org/x/crypto` indirect dependencies in the four `tools/` Go modules to clear 39 high-severity code-scanning (SCA) alerts on `main`. Target versions match the root Fleet module. | Module | x/net | x/crypto | | --- | --- | --- | | `tools/dibble` | v0.53.0 → **v0.55.0** | v0.50.0 → **v0.52.0** | | `tools/hangar` | v0.53.0 → **v0.55.0** | v0.50.0 → **v0.52.0** | | `tools/terraform` | v0.48.0 → **v0.55.0** | v0.46.0 → **v0.52.0** | | `tools/github-manage` | v0.38.0 → **v0.55.0** | — | CVEs cleared: - **x/net v0.55.0**: CVE-2026-25681, -27136, -33814, -39821, -42502 - **x/crypto v0.52.0**: CVE-2026-39827, -39828, -39829, -39830, -39832, -39835, -42508, -46595, -46597 All four modules `go mod verify` clean and build. Dependency-only change to internal dev tooling — no product code, no user-visible behavior. > The remaining 8 high-severity alerts in `tools/` are OpenSSF Scorecard > "Binary-Artifacts" findings for embedded dibble seed installers; those are > tracked separately and not addressed here. # 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. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated several bundled Go dependencies across internal tooling to newer versions. * This includes refreshes to common networking, cryptography, text, and system packages, plus one added telemetry-related dependency. * No user-facing features or behavior changes were introduced. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Andrey Kizimenko
|
a13cd2c373 |
Remove dead Wails-template scaffolding from tools/hangar (#48126)
**Related issue:** N/A — follow-up cleanup to #46406 (Add Hangar). ## What & why Fleet Hangar is a macOS-only, GUI-only dev tool built natively, but the Wails v3 project template left behind config for modes/platforms it never uses. None of it was referenced by CI, scripts, or the documented build flow (`dev` / `build` / `package` / `dist` / `sign`). Removed: - **Server-mode + Docker tasks** (`build:server`, `run:server`, `build:docker`, `run:docker`, `setup:docker`) in the root and common Taskfiles. They point at `build/docker/Dockerfile.{server,cross}`, which don't exist, and there is no `server` build tag anywhere in the Go code. - **Docker cross-compilation** in `build/darwin` (`build:docker`, `CROSS_IMAGE`, the `build:universal` `lipo:go` fallback). `build:` and `build:universal` now call the native macOS paths directly. - **iOS tasks** (`ios:device:list`, `ios:run:device`) — no iOS project exists. - **`frontend:vendor:puppertino`** — fetched CSS into `frontend/public/puppertino` and rewrote `index.html`; none of those targets exist and no task called it. - **`.gitignore`** lines for `build/linux` and `build/windows` (neither dir exists). - **`config.yml`** template placeholders (commented `ios` / `fileAssociations` blocks, the `My Other Data` `other` entry). The darwin signing vars (`SIGN_IDENTITY`, `KEYCHAIN_PROFILE`, `ENTITLEMENTS`) are now declared as empty strings instead of comments, so removing `CROSS_IMAGE` doesn't leave `vars:` as a null mapping (which the Taskfile schema rejects). Behavior is unchanged — the `sign:` preconditions still guard on non-empty values. Net: **11 insertions, 280 deletions** across 5 files. No change to the real build flow. ## Testing - Verified with `task build` — exit 0, produces `bin/fleet-hangar` (arm64 Mach-O). - `task --list-all` parses all three Taskfiles with no schema errors and no dangling task references. ## Checklist - [x] QA'd manually (`task build`) No changes file: `tools/hangar` is an internal dev tool, so this is not a user-visible change. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Simplified build configuration by removing Puppertino CSS integration and server/Docker/iOS build tasks. * Updated development task with improved process management to prevent orphaned processes. * Streamlined macOS build process to native-only implementation, removing cross-compilation support. * Cleaned up build configuration files and project ignore patterns. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Andrey KizimenkoandGeorge Karr
|
0f9af89a93 |
Add Hangar: Go/Wails desktop control panel for the Fleet dev environment (#46406)
## Summary Adds `tools/hangar` — a macOS desktop control panel for working on Fleet locally: branch management, `fleet serve` orchestration, log tail, dev MySQL backup/restore, `fleetctl`, GitOps, and `osquery-perf`, all in one window. Built with **Go + [Wails 3](https://v3alpha.wails.io)** — the backend is plain Go (`os/exec`, `syscall`, goroutines) so Fleet engineers can contribute to it; only the desktop shell is Wails. The `internal/` packages are pure and unit-tested. ### History note Hangar started as a Rust/Tauri app. It was ported to Go, and **the Go port is now the canonical `tools/hangar`**. The original Rust/Tauri implementation has been removed from the monorepo (preserved in a standalone repo) — so although this branch's earlier commits add and then replace the Rust app, the net diff is just the Go app at `tools/hangar`. The bundle identifier is `com.fleetdm.fleet-hangar`, matching the original app so existing settings carry over. # 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 > No `changes/` file: `tools/` is contributor tooling, not a user-visible Fleet change. No DB migrations, no Fleet config settings, no fleetd/orbit changes. ## Testing - [x] Added/updated automated tests (Go unit tests across `internal/`, including a path-traversal regression for backup deletion) - [x] QA'd all new/changed functionality manually ## Test plan - [x] `cd tools/hangar && task dev` launches the app (live-reload) - [x] `task build` produces `bin/fleet-hangar`; `go test ./...` is green - [x] First-run gate discovers a local Fleet clone and runs dep checks - [x] Server tab can run the build chain and start `fleet serve` - [x] Git tab branch search finds an older branch (e.g. a stale `qa-*`) by name <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Introduced Fleet Hangar, a comprehensive desktop application for Fleet development workflows, providing unified controls for server/database management, git operations, configuration, logging, and troubleshooting. * Added database backup management with metadata tracking. * Integrated process orchestration for development services (Docker, ngrok, Python). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: George Karr <georgekarrv@users.noreply.github.com> |