general: update dd-trace-go to v2 (don't merge until v2 release)

[darccio]

Description

Motivation

Workflow

1. ⚠️⚠️ Create your PR as draft
2. Follow the style guidelines of this project (See how to easily lint the code)
3. Work on you PR until the CI passes (if something not related to your task is failing, you can ignore it)
4. Mark it as ready for review

Once your PR is reviewed, you can merge it! ❤️

Reviewer checklist

• Check what scenarios are modified. If needed, add the relevant label (run-parametric-scenario, run-profiling-scenario...). If this PR modifies any system-tests internal, then add the run-all-scenarios label (more info).
• CI is green
  • If not, failing jobs are not related to this change (and you are 100% sure about this statement)
• if any of build-some-image label is present
  1. is the image labl have been updated ?
  2. just before merging, locally build and push the image to hub.docker.com
• if a scenario is added (or removed), add (or remove) it in system-test-dasboard nightly

[darccio]

Don't merge until v2 is released.

[cbeauchesne]

Hi @darccio, do you still plan to work on this ?

[darccio]

@cbeauchesne Yes, it's still work in progress. I was testing this right now because some Appsec RASP tests are failing.

[datadog-datadog-prod-us1]

🟡 Library Vulnerability

google.golang.org/grpc → 1.64.0

Private tokens could appear in logs if context containing gRPC metadata is logged in github.com/grpc/grpc-go (...read more)

Impact

This issue represents a potential PII concern. If applications were printing or logging a context containing gRPC metadata, the affected versions will contain all the metadata, which may include private information.

Patches

The issue first appeared in 1.64.0 and is patched in 1.64.1 and 1.65.0

Workarounds

If using an affected version and upgrading is not possible, ensuring you do not log or print contexts will avoid the problem.

    

[datadog-datadog-prod-us1]

🟠 Library Vulnerability

golang.org/x/net → 0.22.0

net/http, x/net/http2: close connections when receiving too many headers (...read more)

An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.

    

[datadog-datadog-prod-us1]

🟠 Library Vulnerability

golang.org/x/net → 0.22.0

net/http, x/net/http2: close connections when receiving too many headers (...read more)

An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.