[bug] `transitive_headers` leaks across different dependency chains through `Requirement.aggregate()`

[gnaloaixey]

Describe the bug

When a package has both a direct dependency on A and also reaches A transitively through another dependency B (where B has transitive_headers=True), the transitive_headers trait leaks from B's dependency chain into A via the aggregate() method.

Dependency structure

pkg_d (shared-library)
  └─ pkg_c (shared-library)
       ├─ pkg_a (shared-library)              # direct dependency, also reached via pkg_b
       ├─ pkg_a_2 (shared-library)            # direct dependency (control group, single path)
       └─ pkg_b (shared-library, transitive_headers=True)
            └─ pkg_a (shared-library)         # same as above, transitively

Expected behavior

For a shared-library chain, pkg_d's info.requires should ideally contain only its direct dependency:

"requires": ["pkg_c/0.1.Z"]

Since pkg_c uses transitive_headers=True on pkg_b, the following is also reasonable:

"requires": ["pkg_c/0.1.Z", "pkg_b/0.1.Z"]

The extra package pkg_a is the bug. It appears only because it has two paths (direct + via pkg_b). The control pkg_a_2 (single path) is correctly excluded, proving shared->shared propagation works for non-duplicated dependencies.

Actual behavior

{
    "Local Cache": {
        "pkg_d/0.1": {
            "revisions": {
                "3cc42339c1dd276a6ce348de034db0a7": {
                    "timestamp": 1781075212.285881,
                    "packages": {
                        "deb3e52ab812c47e795d7b0cdff374997c83ce89": {
                            "info": {
                                "settings": {
                                    "arch": "x86_64",
                                    "build_type": "Release",
                                    "compiler": "msvc",
                                    "compiler.cppstd": "14",
                                    "compiler.runtime": "dynamic",
                                    "compiler.runtime_type": "Release",
                                    "compiler.version": "190",
                                    "os": "Windows"
                                },
                                "requires": [
                                    "pkg_a/0.1.Z",
                                    "pkg_b/0.1.Z",
                                    "pkg_c/0.1.Z"
                                ]
                            }
                        }
                    }
                }
            }
        }
    }
}

• pkg_c — expected (direct dependency)
• pkg_b — reaches pkg_d via transitive_headers=True (arguably intended)
• pkg_a — incorrectly appears (bug)
• pkg_a_2 — correctly excluded (proof that single-path packages work fine)

Root cause analysis

Three interactions in conan/internal/model/requires.py chain together to produce this behavior:

Step 1 — transform_downstream() L329-L330

if self.transitive_headers is not None:
    downstream_require.transitive_headers = self.transitive_headers

When pkg_c's dependency on pkg_b (transitive_headers=True) propagates pkg_b -> pkg_a downstream, the downstream_require for pkg_a inherits transitive_headers=True — a trait belonging to a different relationship (pkg_c -> pkg_b, not pkg_a's).

Step 2 — aggregate() L255

self.transitive_headers = self.transitive_headers or other.transitive_headers

When this propagated pkg_a (with leaked transitive_headers=True) arrives at pkg_c, it aggregates with pkg_c's existing direct require on pkg_a (transitive_headers=None). The OR merges them to transitive_headers=True.

Step 3 — transform_downstream() L327-L328

if require.transitive_headers is not None:
    downstream_require.headers = require.headers and require.transitive_headers

When pkg_c propagates the aggregated pkg_a (now transitive_headers=True) to pkg_d, line 328 overrides the headers=False (set by shared->shared rules at L299) back to True, making pkg_a visible to pkg_d.

Cascade flow

pkg_c -> pkg_b (transitive_headers=True)
  +-> pkg_b -> pkg_a
       +-> transform_downstream L330: downstream_require.transitive_headers = True
            +-> propagates to pkg_c
                 +-> aggregate L255: transitive_headers = True or None = True
                      +-> transform_downstream L328: headers = True
                           +-> pkg_d sees pkg_a as a dependency (INCORRECT)

Possible fix (needs discussion)

The most straightforward fix is removing the transitive_headers/transitive_libs merge in aggregate() (L255-256):

# Remove these two lines:
# self.transitive_headers = self.transitive_headers or other.transitive_headers
# self.transitive_libs = self.transitive_libs or other.transitive_libs

However, it is unclear whether this is a bug or by design. The transitive_headers propagation through aggregate() may be intentional for loop-closing scenarios. Discussion with maintainers is needed on:

• Whether transitive_headers should be aggregated across paths at all
• If so, which path should take precedence
• Whether transform_downstream() L327-328 should check transitive_headers in shared->shared propagation

How to reproduce it

A conan_transitive_header.zip archive is attached with the full project.

Environment

• Conan version: 2.21, 2.29 (both affected)
• OS: Windows

Export and inspect

conan export-pkg pkg_a -pr default
conan export-pkg pkg_a_2 -pr default
conan export-pkg pkg_b -pr default
conan export-pkg pkg_c -pr default
conan export-pkg pkg_d -pr default
conan list pkg_d/0.1:* --format=json

conan export-pkg pkg_c_2 -pr default
conan export-pkg pkg_d_2 -pr default
conan list pkg_d_2/0.1:* --format=json

[AbrilRBS]

Hi @gnaloaixey thanks a lot for taking the time to report this and come up with a reproduction case, we truly appreciate it.

You're right in that the header visibility of a from from d is unexpected. We will be investigating possible fixes for it in the linked PR #20073, and we will update you once we have a clear solution :)

[AbrilRBS]

@gnaloaixey we have identified a proper fix and will most likely publish it in Conan 2.30.

Note that as this bugfix would cause grat amounts of missing binaries, we're opting to guard this under a version-based policy.

This means that the fix will only apply if either:

• libc has a required_conan_version>=2.30 or greater
• Your globa.conf contains core:policies=["required_conan_version>=2.30"] or greater

The idea here is for the new behaviour to be opt-in based either of the user's global config, or per-recipe. Note that this means that libd consumers can't selectively choose their package id, it's libc's job to do so, as libc is the package that was erronously propagating the trait.