Merge branch 'main' into docs-v4.64.0

.github/ISSUE_TEMPLATE/story.md

@@ -39,7 +39,7 @@ What else should contributors [keep in mind](https://fleetdm.com/handbook/compan
 ## Changes
 
 ### Product
-- [ ] UI changes: TODO <!-- Insert the link to the relevant Figma cover page. Make sure  wireframes show the UI down to 320px (min screen width). Put "No changes" if there are no changes to the user interface. -->
+- [ ] UI changes: TODO <!-- Insert the link to the relevant Figma cover page. Make sure  wireframes show the UI down to 768px (min screen width). Put "No changes" if there are no changes to the user interface. -->
 - [ ] CLI (fleetctl) usage changes: TODO <!-- Insert the link to the relevant Figma cover page. Put "No changes" if there are no changes to the CLI. -->
 - [ ] YAML changes: TODO <!-- Specify changes in the YAML files doc page as a PR to the reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. -->
 - [ ] REST API changes: TODO <!-- Specify changes in the the REST API doc page as a PR to reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. Move this item to the engineering list below if engineering will design the API changes. -->

.github/scripts/dogfood-policy-updater-latest-macos.sh

@@ -103,6 +103,33 @@ if [ "$policy_version_number" != "$latest_macos_version" ]; then
     fi
 
     echo "Pull request created successfully."
+
+    # Extract the pull request number from the response
+    pr_number=$(echo "$pr_response" | jq -r '.number')
+    if [ -z "$pr_number" ] || [ "$pr_number" == "null" ]; then
+        echo "Error: Failed to retrieve pull request number."
+        exit 1
+    fi
+
+    echo "Adding reviewers to PR #$pr_number..."
+
+    # Prepare the reviewers data payload
+    reviewers_data=$(jq -n --arg r1 "harrisonravazzolo" '{reviewers: [$r1]}')
+
+    # Request reviewers for the pull request
+    review_response=$(curl -s -X POST \
+        -H "Authorization: token $DOGFOOD_AUTOMATION_TOKEN" \
+        -H "Accept: application/vnd.github.v3+json" \
+        -d "$reviewers_data" \
+        "https://api.github.com/repos/$REPO_OWNER/$REPO_NAME/pulls/$pr_number/requested_reviewers")
+
+
+    if echo "$review_response" | grep -q "errors"; then
+        echo "Error: Failed to add reviewers. Response: $review_response"
+        exit 1
+    fi
+
+    echo "Reviewers added successfully."
 else
     echo "No updates needed; the version is the same."
 fi

.github/workflows/generate-desktop-targets.yml

@@ -19,7 +19,7 @@ defaults:
     shell: bash
 
 env:
-  FLEET_DESKTOP_VERSION: 1.39.0
+  FLEET_DESKTOP_VERSION: 1.39.1
 
 permissions:
   contents: write

articles/articles/preventing-mistakes-with-gitops.md

@@ -0,0 +1,94 @@
+## Introduction
+
+All SysAdmins have been there. It’s Friday afternoon - you make a few wrong clicks in your MDM. All of a sudden, devices that were in a specific team granting users access to your internal network have a configuration profile revoked. Just as you’re ready to sign off for the weekend you start getting Slack messages and realize your mistake. 😳
+
+It’s a tough lesson to learn. 
+
+But, what if there was a way, through GitOps and change management best practices, you could avoid all this? A modern change management methodology typically reserved for developers has now arrived for your IT team. 🛬
+
+## What is “GitOps”?
+
+GitOps is an operational framework that takes best practices used for application development such as version control, collaboration, compliance, and continuous integration / development, and applies them to device management automation. Key attributes of this system:
+
+- Configurations are declaritively defined in a repo (such as GitHub or GitLab)
+- Configurations represent a single source of truth for system state
+- Automated synchronization between git and live infrastructure
+- Continuous reconciliation to maintain system state
+- Immutable configuration is managed through pull requests and code reviews
+
+The ultimate goals of this approach? Improve reliability, reduce errors, and enable consistent, auditable management of your device infrastructure. 
+
+## Getting Started 
+
+Fleet publishes a starter template that we recommend checking out (available for both GitHub and GitLab.) 
+
+> In this article we will be using GitHub but the general principles are the same. 
+
+Clone the starter repo: `https://github.com/fleetdm/fleet-gitops` and create your own repo to which you will push code. 
+
+> In a production environment, it is best to protect the `main` branch and only allow merging after a code review is conducted. It can be modified if needed, but, by default the apply action will run whenever code is committed to `main`.
+
+An important benefit of GitOps is the ability to store all your environment secrets in GitHub - encrypted and protected from view. With the correct configuration, this prevents tampering and leaks.
+
+Add the `FLEET_URL` and `FLEET_API_TOKEN` secrets to your new repository's secrets. If you’re working out of the template, also add `FLEET_GLOBAL_ENROLL_SECRET`, `FLEET_WORKSTATIONS_ENROLL_SECRET` and `FLEET_WORKSTATIONS_CANARY_ENROLL_SECRET`.
+
+This can be adjusted depending on how you want to leverage Teams and team names.
+
+## A Typical GitOps Workflow
+
+We will start with a traditional workflow to demonstrate the process used to commit changes to your Fleet instance. In this example we are adding a passcode policy for Macs by setting the minimum length to 12 characters. 
+
+> For all examples in this article we will be using the GitHub Desktop app to do commits. Using `git` in the terminal will of course also work. Use whatever you’re most comfortable with.
+
+![gif-1](../website/assets/images/articles/preventing-mistakes-1-1423x771@2x.gif)
+
+Here, after making changes to the `passcode.json` file, it has been added to the Team we are configuring under the `macos_settings` section.
+
+![gif-2](../website/assets/images/articles/preventing-mistakes-2-960x540@2x.gif)
+
+GitHub Desktop will automatically pick up changes. You can review each file and make commit comments. If all looks good, push your changes to the working branch.
+
+![gif-3](../website/assets/images/articles/preventing-mistakes-3-1423x771@2x.gif)
+
+We create a PR to bring this change into the `main` production branch. In this example, branch protections are off so I can merge right to `main` but further on in the article this will change. 
+
+## GitOps: The way it was meant to be
+
+Another benefit of a GitOps approach is the ability for members of a team to review changes before they are applied in production. This encourages collaboration while ensuring all modifications to state are following best practices and compliance. In addition, if something breaks (which is inevitable) you have a ‘snapshot’ or point in time with a known working state to which you can easily roll back.
+
+![gif-4](../website/assets/images/articles/preventing-mistakes-4-960x540@2x.gif)
+
+The newest version of macOS is released and an engineer on your team wants to push a change to require an update of all hosts in the Workstations team. The IT engineer creates a branch to work from and makes the necessary changes, including setting a new target version and deadline.
+
+```
+macos_updates:
+    deadline: "2025-02-15"
+    minimum_version: "15.4.1"
+```
+
+Merging is blocked until a member of the team reviews and approves the changes. 
+
+![gif-5](../website/assets/images/articles/preventing-mistakes-5-960x540@2x.gif)
+
+Our IT manager is listed as the approver for these changes. The approver is notified of a pending PR for review. Is there a problem with some of the changes? Our engineer accidentally put in a version string that is not yet available. This will cause issues for our users when they try to update. The fix? Tag the engineer with some feedback and request changes to be made and re-committed. 
+
+![Pr Approval](../website/assets/images/articles/pr-approval-921x475@2x.jpg)
+
+After our engineer has updated code from the review, the approver can do a final review, approve and let the engineer merge this branch into `main` to trigger the apply workflow. This will push the changes into the production environment. ✨
+
+![Pr Approval](../website/assets/images/articles/pr-approval-2-933x483@2x.jpg)
+
+## Conclusion
+
+By adopting GitOps for device management, your team's work becomes observable, reversible and repeatable while automating your device configurations. Instead of making changes manually and risking unintended consequences, you gain a reliable, auditable workflow where every modification is reviewed, approved, and tracked. 
+
+This approach reduces human error and fosters teamwork. Whether you're enforcing security policies, managing OS updates, or deploying configuration changes, GitOps ensures consistency and control helping you avoid those last-minute Friday afternoon mishaps. 😥
+
+Want to know more about Fleet's comprehensive MDM platform in code? Visit fleetdm.com and use the 'Talk to an engineer' [link](https://fleetdm.com/contact).
+
+<meta name="articleTitle" value="Preventing Mistakes with GitOps">
+<meta name="authorFullName" value="Harrison Ravazzolo">
+<meta name="authorGitHubUsername" value="harrisonravazzolo">
+<meta name="category" value="guides">
+<meta name="publishedOn" value="2025-02-12">
+<meta name="description" value="Use GitOps to manage your infrastructure in code and prevent mistakes">

articles/fleet-software-attestation.md

@@ -1,14 +1,34 @@
 # Fleet software attestation
 
-As of version 4.63.0 Fleet added [SLSA attestations](https://slsa.dev/) to our released binaries and container images.  This includes the `fleet` and `fleetctl` server software, the fleetd (Orbit, osquery, and Fleet Desktop) agent for hosts.
+As of version 4.63.0 Fleet added [SLSA attestations](https://slsa.dev/) to our released binaries and container images.  This includes the Fleet server, [fleetctl](https://fleetdm.com/docs/get-started/anatomy#fleetctl) command-line tool (CLI), and Fleet's agent (specifically the [Orbit](https://fleetdm.com/docs/get-started/anatomy#fleetd) component).
 
 ## What is software attestation?
 
 A software attestation is a cryptographically-signed statement provided by a software creator that certifies the build process and provenance of one or more software _artifacts_ (which might be files, container images, or other outputs). In other words, it's a promise to our users that the software we're providing was built by us, using a process that they can trust and verify. We utilize the SLSA framework for attestations which you can read more about [here](https://slsa.dev/).  After each release, attestations are added to https://github.com/fleetdm/fleet/attestations.
 
-## Verifying our release artifacts
+## Verifying a release
 
-Any product of a Fleet release can be _verified_ to prove that it was indeed created by Fleet, using the `gh` command line tool from Github.  See the [`gh attestation verify`](https://cli.github.com/manual/gh_attestation_verify) docs for more info.
+Any Fleet release can be _verified_ to prove that it was indeed created by Fleet, using the `gh` command line tool from Github.  See the [`gh attestation verify`](https://cli.github.com/manual/gh_attestation_verify) docs for more info.
+
+After downloading the [Fleet binary](https://github.com/fleetdm/fleet/releases), here's how to verify:
+
+```
+gh attestation verify --owner fleetdm /path/to/fleet
+```
+
+Verify the [fleetctl binary](https://github.com/fleetdm/fleet/releases) (CLI):
+
+```
+gh attestation verify --owner fleetdm fleetdm /path/to/fleetctl
+```
+
+After, installing Fleet's agent (fleetd) on a macOS host, run this command on the host to verify:
+
+```
+gh attestation verify --owner fleetdm /usr/local/bin/orbit
+```
+
+TODO: Filepath for Windows and Linux
 
 <meta name="authorGitHubUsername" value="sgress454">
 <meta name="authorFullName" value="Scott Gress">

articles/how-to-configure-logging-destinations.md

@@ -78,13 +78,7 @@ Sumo Logic supports data ingestion via HTTP, making it a reliable choice for log
 
 #### For Splunk
 
-Splunk is a powerful platform for searching, monitoring, and analyzing machine-generated big data. Here’s how to integrate it with Firehose:
-
-
-
-1. **Set up Firehose**: Use the AWS guide to configure your Firehose delivery stream for Splunk as a destination. The process involves specifying the Splunk endpoint and authentication details. Detailed instructions are available in the [AWS Firehose documentation](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html?icmpid=docs_console_unmapped#create-destination-splunk).
-2. **Configure Splunk**: Follow the [Splunk documentation](https://docs.splunk.com/Documentation/AddOns/released/Firehose/RequestFirehose) to ensure Splunk is set to receive data from Firehose. This step involves setting up the necessary inputs and configuring Splunk to handle incoming data.
-3. **Firehose to Splunk configuration**: Finalize the setup by configuring Firehose to send data to Splunk, following the guidelines in the [Splunk documentation](https://docs.splunk.com/Documentation/AddOns/released/Firehose/ConfigureFirehose).
+Splunk is a powerful platform for searching, monitoring, and analyzing machine-generated big data. Learn how to connect Fleet to Splunk [here](https://fleetdm.com/guides/log-destinations#splunk).
 
 
 ### Conclusion

articles/install-fleet-maintained-apps-on-macos-hosts.md

@@ -22,7 +22,7 @@ Fleet maintains these [celebrity apps](https://github.com/fleetdm/fleet/blob/mai
    - Post-install script
    - Uninstall scripts
 
-These scripts are auto-generated based on the app's Homebrew Cask formula, but you can modify them. Modifying these scripts allows you to tailor the app installation process to your organization's needs, such as automating additional setup tasks or custom configurations post-installation.
+If you find that a script doesn't work as expected, please file a [bug](https://github.com/fleetdm/fleet/issues/new?template=bug-report.md). When scripts are fixed, after upgrading Fleet, they are automatically updated for you unless you edited any of the scripts.
 
 ## Install the app
 

articles/lock-wipe-hosts.md

@@ -24,6 +24,8 @@ Currently, there's no **Lock** button for iOS and iPadOS. If an iOS or iPadOS ho
 3. Click the **Actions** dropdown, then click  **Wipe**.
 4. Confirm that you want to wipe the device in the dialog. The host will now be marked with a "Wipe pending" badge. Once the wipe command is acknowledged by the host, the badge will update to "Wiped".
 
+> When wiping and re-installing the operating system (OS) for a host, also delete it from Fleet before you re-enroll it. If you re-enroll without deleting, a new disk encryption key won’t be escrowed.
+
 ## Unlock a host
 
 1. Navigate to the **Hosts** page by clicking the "Hosts" tab in the main navigation header. Find the device you want to unlock. You can search by name, hostname, UUID, serial number, or private IP address in the search box in the upper right corner.

articles/log-destinations.md

@@ -53,13 +53,38 @@ Snowflake provides instructions on setting up the destination tables and IAM rol
 
 ## Splunk
 
-To send logs to Splunk, you must first configure Fleet to send logs to [Amazon Kinesis Data Firehose (Firehose)](#amazon-kinesis-data-firehose). This is because you'll enable Firehose to forward logs directly to Splunk.
-
-With Fleet configured to send logs to Firehose, you then want to load the data from Firehose into Splunk. AWS provides instructions on how to enable Firehose to forward directly to Splunk [here in the AWS documentation](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-splunk).
-
-If you're using Fleet's [terraform reference architecture](https://github.com/fleetdm/fleet/blob/main/infrastructure/dogfood/terraform/aws), you want to replace the S3 destination with a Splunk destination. Hashicorp provides instructions on how to send Firehose data to Splunk [here in the Terraform documentation](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/kinesis_firehose_delivery_stream#splunk-destination).
-
-Splunk provides instructions on how to prepare the Splunk platform for Firehose data [here in the Splunk documentation](https://docs.splunk.com/Documentation/AddOns/latest/Firehose/ConfigureFirehose).
+How to send logs to Splunk:
+
+1. Follow [Splunk's instructions](https://docs.splunk.com/Documentation/AddOns/latest/Firehose/ConfigureFirehose) to prepare the Splunk for Firehose data.
+
+2. Follow these [AWS instructions](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-splunk) on how to enable Firehose to forward directly to Splunk.
+
+3. In your [`main.tf` file](https://github.com/fleetdm/fleet-terraform/blob/main/addons/logging-destination-firehose/main.tf), replace your S3 destination (`aws_kinesis_firehose_delivery_stream`) with a Splunk destination:
+
+```hcl
+resource "aws_kinesis_firehose_delivery_stream" "test_stream" {
+  name        = "terraform-kinesis-firehose-test-stream"
+  destination = "splunk"
+
+  splunk_configuration {
+    hec_endpoint               = "https://http-inputs-mydomain.splunkcloud.com:443"
+    hec_token                  = "51D4DA16-C61B-4F5F-8EC7-ED4301342A4A"
+    hec_acknowledgment_timeout = 600
+    hec_endpoint_type          = "Event"
+    s3_backup_mode             = "FailedEventsOnly"
+
+    s3_configuration {
+      role_arn           = aws_iam_role.firehose.arn
+      bucket_arn         = aws_s3_bucket.bucket.arn
+      buffering_size     = 10
+      buffering_interval = 400
+      compression_format = "GZIP"
+    }
+  }
+}
+```
+
+For the latest configuration go to HashiCorp's Terraform docs [here](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/kinesis_firehose_delivery_stream#splunk-destination).
 
 ## Amazon Kinesis Data Streams
 

articles/vulnerability-processing.md

@@ -25,6 +25,8 @@ Currently, only software names with all ASCII characters are supported. Vulnerab
 
 For Ubuntu Linux, kernel vulnerabilities with known variants (ie. `-generic`) are detected using OVAL. Custom kernels (unknown variants) are detected using NVD.
 
+If you find that Fleet is incorrectly marking software as vulnerable (false positive) or missing a vulnerability (false negative), please file a [bug](https://github.com/fleetdm/fleet/issues/new?template=bug-report.md). When false positives are fixed, it may take an hour for the false positive to dissapear after upgrading Fleet. 
+
 ## Sources
 
 Fleet combines multiple sources to get accurate and up-to-date CVE information:

changes/24222-update-versions

@@ -0,0 +1,2 @@
+- Adds a daily job that keeps the App Store app version displayed in Fleet in sync with the actual
+  latest version.

changes/26177-max-conc

@@ -0,0 +1,2 @@
+- Prevented an invalid `FLEET_VULNERABILITIES_MAX_CONCURRENCY` value from causing deadlocks during
+  vulnerability processing.

changes/26178-fix-2

@@ -0,0 +1,2 @@
+- Fixed an issue with increased resource usage during vulnerabilities processing by adding a
+  database index.

changes/26283-software-stuck-pending

@@ -0,0 +1 @@
+- Fixed a bug where new fleetd could not install software from old fleet server

changes/issue-25656-change-host-modal-copy

@@ -0,0 +1,2 @@
+- changed the copy for the delete and transfer host modal to be more clear about the disk encryption
+  key behavior