feat(agent-config): make TLS provider opt-in for transitive libdd deps#136
Merged
Conversation
libdd-trace-obfuscation and libdd-trace-utils default to their "https"
feature which pulls hyper-rustls with ring crypto. When a consumer needs
FIPS compliance, this default leaks into the dependency graph and
defeats consumer-side fips features (cargo unions features additively,
so default+fips ends up linking both ring and aws-lc-rs).
Switch the libdd deps to default-features = false and expose two new
crate features so consumers pick explicitly:
https = libdd-trace-{utils,obfuscation}/https # ring-backed HTTPS
fips = libdd-trace-{utils,obfuscation}/fips # aws-lc-rs HTTPS
The default feature set is empty - the crate itself never needs TLS,
only its libdd transitives can. Existing consumers that relied on
the implicit "https" pull now opt in by setting
`datadog-agent-config = { ..., features = ["https"] }` (or "fips").
Also flips `dogstatsd = { path = "../dogstatsd" }` to
default-features = false for the same reason - dogstatsd's default
features include HTTP send paths that we don't use from agent-config,
and they similarly leak ring/rustls feature flags downstream.
Verified:
cargo check -p datadog-agent-config # clean
cargo test -p datadog-agent-config # 71 passed
duncanista
requested review from
duncanpharvey and
shreyamalpani
and removed request for
a team
Contributor
There was a problem hiding this comment.
Pull request overview
This PR makes datadog-agent-config crypto/TLS-provider agnostic by disabling default features on transitive libdatadog dependencies and exposing explicit crate features for selecting a TLS provider when needed.
Changes:
- Disable
default-featuresforlibdd-trace-utilsandlibdd-trace-obfuscationto avoid implicitly pulling a TLS provider into downstream consumers. - Add opt-in crate features
httpsandfipsthat forward to the correspondinglibdd-trace-{utils,obfuscation}features. - Disable default features for the workspace
dogstatsddependency since only a small utility function is used.
duncanista
added a commit
to DataDog/datadog-lambda-extension
that referenced
this pull request
Jun 10, 2026
Bumps datadog-agent-config to the upstream PR branch SHA carrying DataDog/serverless-components#136 (which switches the libdd deps to default-features = false and exposes new https/fips features), and plumbs them through bottlecap's default/fips feature spec so the right TLS provider is selected per build. Without this, datadog-agent-config's libdd transitive dependencies implicitly enabled `https` (ring-backed hyper-rustls) on top of the fips path that bottlecap activates, leaving both providers in the dependency graph. The datadog-fips build script then rejected the build because ring v0.17 was reachable via: ring v0.17 -> libdd-common feature "https" -> hyper-rustls feature "ring" -> rustls-webpki feature "ring" With agent-config now opting in via consumer features instead of defaults, the FIPS dep tree is clean again. Also regenerated LICENSE-3rdparty.csv to include the new datadog-agent-config package, per the dd-rust-license-tool check. TODO: re-pin to the merge SHA once DataDog/serverless-components#136 lands.
Per copilot review on #136 — Cargo doesn't enforce mutual exclusivity. Reword the doc comment to spell out that both features can technically be enabled (e.g. via --all-features) but that doing so defeats the purpose by re-adding ring alongside aws-lc-rs in the dep graph.
duncanista
added a commit
to DataDog/datadog-lambda-extension
that referenced
this pull request
Jun 10, 2026
Picks up the doc-comment clarification from the copilot review on DataDog/serverless-components#136 (https/fips features aren't Cargo-enforced).
Lewis-E
approved these changes
Jun 10, 2026
duncanista
added a commit
to DataDog/datadog-lambda-extension
that referenced
this pull request
Jun 10, 2026
DataDog/serverless-components#136 merged at bb4dedeee20b949db3143c05e5a779b843a8a484. The previous pin was the pre-merge branch SHA used during development.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Switch `libdd-trace-utils` and `libdd-trace-obfuscation` deps inside `datadog-agent-config` to `default-features = false`, and expose two new crate features so consumers pick the TLS provider explicitly:
The default feature set is now empty.
Motivation
The crate itself never reaches for TLS — it only ever uses `parse_rules_from_string` from `libdd-trace-obfuscation` and a couple of URL helpers from `libdd-trace-utils`. But by depending on those crates with their `default` features (which include `https` and pull `hyper-rustls` + `ring`), the choice of crypto provider leaked into every downstream consumer.
This bit `datadog-lambda-extension` (bottlecap), which builds a FIPS-compliant variant of its binary. Bottlecap activates `libdd-/fips` via its own `fips` feature, but because Cargo feature unification is additive, the implicit `libdd-/default` pulled in via `datadog-agent-config` re-enabled the `https` (ring) path alongside, breaking FIPS dependency-graph validation (`ring v0.17 → libdd-common feature "https" → hyper-rustls feature "ring" → rustls-webpki feature "ring"`).
By making the TLS provider opt-in, `datadog-agent-config` becomes crypto-agnostic again. Consumers either enable `https` or `fips` depending on their build, and the FIPS branch is no longer poisoned by an implicit default.
Same treatment applied to the `dogstatsd` workspace dep — it's used only for `parse_metric_namespace`, so default features are disabled.
Additional Notes
Existing consumers that relied on the implicit `https` pull from `datadog-agent-config` need to opt in:
```toml
datadog-agent-config = { ..., features = ["https"] } # or ["fips"]
```
Describe how to test/QA your changes