Secures content-app headers consistently.

[ggainey]

Addresses CVE-2026-84232.

[gerrod3]

Put this all on one line. Multi-line changelogs break our rendering, e.g. https://pulpproject.org/pulpcore/changes/#3.115.0

[gerrod3]

Don't we have the same issue still on stream_remote_artiifact? This fix is only for content that is immediately synced/uploaded.

[ggainey]

Good catch, let me dig - the initial report was only for uploaded-content.

[ggainey]

@gerrod3 My goal with this would be to "guarantee" this set of headers as early in the response-process as possible, and preferably Just Once (ie before we make the stream-vs-return decision). We need either the Response, or the/a list of headers we're planning to add to a Response, and Content-Disposition needs/wants the "filename". Do you have any thoughts on the best place to do this setup?

[gerrod3]

I don't know. _match_and_stream typically calls two methods to generate the response _serve_content_artifact(ca, headers, request) or _stream_content_artifact(request, StreamResponse(headers=headers), ca). In both cases we get the original headers dict from the handler's response_headers(original_rel_path, distro), but when we call this method we don't know the final ContentArtifact that is going to be used (if we are serving a CA at all) for the request. Both of the serving methods update the headers dict with extra things they set before returning the final response, so maybe the best we can do is create a small helper and have both methods call it to update the dict.

[ggainey]

Hugely helpful, thank you