Env var: `FLEET_MDM_SSO_RATE_LIMIT_PER_MINUTE`. **Not** managed via
GitOps.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [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)
- For new Fleet configuration settings
- [x] Verified that the setting can be managed via GitOps, or confirmed
that the setting is explicitly being excluded from GitOps.
- [ ] Added/updated automated tests
- [ ] Manual QA for all new/changed functionality
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Manual QA for all new/changed functionality
## Closes#29613
- Previous changes intended to add `TooltipTruncatedText`-like
functionality accidentally broke existing functionality when pill
content was not truncated
- This restores the previous functionality when explicit tooltip content
is passed in, and adds fall back behavior to act like
`TooltipTruncatedText`, where when the element content is truncated, its
full content is rendered as a tooltip on hover.
### Tooltip content is explicitly passed in and rendered in the tooltip.
Notice the tooltip content differs from the underlying element content:
<img width="675" alt="Screenshot 2025-05-30 at 11 21 49 AM"
src="https://github.com/user-attachments/assets/b0f8e72e-9925-4844-80ca-672b6efeb443"
/>
### No tooltip content passed in, falls back to
`TooltipTruncatedText`-like behavior. Notice the truncated element
content is the prefix of the full content rendered in the tooltip:
<img width="675" alt="Screenshot 2025-05-30 at 11 21 25 AM"
src="https://github.com/user-attachments/assets/e5fe7d74-3674-478c-8e33-7e84006e7390"
/>
- [x] Manual QA for all new/changed functionality
Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
+ For `order_direction`, use consistent `"asc"` and `"desc"` instead of
'asc', `asc`, etc.
+ Add a missing comma in an example
+ Add missing quotes for a string value in an example
> closes#26403
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] If database migrations are included, checked table schema to
confirm autoupdate
- For database migrations:
- [x] Ensured the correct collation is explicitly set for character
columns (`COLLATE utf8mb4_unicode_ci`).
- [x] Added/updated automated tests
- [x] Manual QA for all new/changed functionality
I'm experiencing problems with the "Install the fleetctl command line
tool" step on https://fleetdm.com/try-fleet for trying out Fleet hosting
on Windows. The root cause seem to be a mismatch between the Windows
ZIP-file naming in the script vs. on
https://api.github.com/repos/fleetdm/fleet/releases/latest
I was able to overcome the problem by changing `_windows.zip` to
`_windows_amd64.zip` in the script.
NVD just added a v3 score for CVE-2025-3196.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [x] Added/updated automated tests
- [x] Manual QA for all new/changed functionality
Fixes#28261.
~~Of note, this logic will prefer a non-primary CVSSv3.1 score over a
primary CVSSv3.0 score if 3.1 doesn't have primary but 3.0 does. I
haven't seen any evidence of this in our dataset (looked at 2024
output).~~
Updated with logic that will prefer a primary CVSSv3.0 score over a
secondary CVSSv3.1 score for a given vulnerability. In the test dataset
(2023 vuln snapshot, ~20k vulns) there were no cases where this
situation presented itself, so output was identical to the prior
implementation.
Validated by comparing a vulns run from GitHub Actions to a local run
with the new code, and confirmed that existing v3 scores weren't
replaced when they already existed (just got adds of v2 when only v3
existed, and v2/v3 adds when no scoring existed).
Confirmed that all three CVEs mentioned in #28261 show up in feed data.
Added spot-checks for secondary CVSS scores to the feed validator tool.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [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/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)
- [x] Manual QA for all new/changed functionality
If the user has a software installed on their machine that happens to
match a vpp app in our catalog. When searching by vulnerable attributes
do not link that software to a vpp app. Just treat it like a non-fleet
installed application.
https://github.com/fleetdm/fleet/issues/29308
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [x] Added/updated automated tests
- [x] Manual QA for all new/changed functionality
- [x] For unreleased bug fixes in a release candidate, confirmed that
the fix is not expected to adversely impact load test results or alerted
the release DRI if additional load testing is needed.
Temporarily fixes#29570 test failures while we figure out what desired
behavior is and determine how to get that behavior.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Added/updated automated tests
> Closes#28259
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [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)
- [x] Added/updated automated tests
- [x] Manual QA for all new/changed functionality
Two new improvements for local TUF after feedback from @iansltx and QA
folks:
1. The static `42` was confusing when making or sharing several builds
of locally built fleetd. Locally TUF-built version of orbit will now be:
`YY.MM.XXXXX`, e.g. `25.5.56178` (patch version is a 16-bit number made
from day, hour and minute).
2. Also prompting user to delete `test_tuf` which is usually a source of
confusion/errors.
## For #28821
- Update UI-rendered references to `/(F|f)requency/` to refer to
`/(I|i)nterval/` instead
- More info: Note that this PR only changes copy actually rendered in
the UI (and an associated test), and is low-risk, so can be merged and
QAed quickly. [This
branch](https://github.com/fleetdm/fleet/tree/28821-add-on-update-code)
contains updates to variables, constants, and class names, more
error-prone changes that, if review and QA capacity allow, can be PRed
for consistency between the code and the copy, but is not critical for
the desired UI updates.
- [x] Changes file added for user-visible changes in `changes/`
- [x] Added/updated automated tests
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
