Skip to content

Conversation

avara1986
Copy link
Member

backport #12102 to 2.19


Depending of the timing, libddwaf loading process could create triggers that would create loops in our instrumentation.
From what I investigated:

  • if loaded too early, it could have bad interactions with gevent.
  • if loaded too late, it could be self instrumented by the tracer, creating a loop, as ctypes is using Popen and subprocess.

while keeping the late loading introduced by 2 previous PRs

  • chore(asm): improve dependency for api security #11987

  • ci(appsec): fix ddwaf circular import #12013 this PR introduced a mechanism to bypass tracer instrumentation during ctypes loading, to avoid a possible loop that would prevent the WAF to be loaded.

  • PR author has checked that all the criteria below are met

  • The PR description includes an overview of the change

  • The PR description articulates the motivation for the change

  • The change includes tests OR the PR description describes a testing strategy

  • The PR description notes risks associated with the change, if any

  • Newly-added code is easy to change

  • The change follows the library release note guidelines

  • The change includes or references documentation updates if necessary

  • Backport labels are set (if applicable)

  • Reviewer has checked that all the criteria below are met

  • Title is accurate

  • All changes are related to the pull request's stated goal

  • Avoids breaking API changes

  • Testing strategy adequately addresses listed risks

  • Newly-added code is easy to change

  • Release note makes sense to a user of the library

  • If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment

  • Backport labels are set in a manner that is consistent with the release branch maintenance
    policy

(cherry picked from commit 4f0bcb5)

Checklist

  • PR author has checked that all the criteria below are met
  • The PR description includes an overview of the change
  • The PR description articulates the motivation for the change
  • The change includes tests OR the PR description describes a testing strategy
  • The PR description notes risks associated with the change, if any
  • Newly-added code is easy to change
  • The change follows the library release note guidelines
  • The change includes or references documentation updates if necessary
  • Backport labels are set (if applicable)

Reviewer Checklist

  • Reviewer has checked that all the criteria below are met
  • Title is accurate
  • All changes are related to the pull request's stated goal
  • Avoids breaking API changes
  • Testing strategy adequately addresses listed risks
  • Newly-added code is easy to change
  • Release note makes sense to a user of the library
  • If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
  • Backport labels are set in a manner that is consistent with the release branch maintenance policy

Depending of the timing, libddwaf loading process could create triggers
that would create loops in our instrumentation.
From what I investigated:
- if loaded too early, it could have bad interactions with gevent.
- if loaded too late, it could be self instrumented by the tracer,
creating a loop, as ctypes is using Popen and subprocess.

while keeping the late loading introduced by 2 previous PRs
- #11987
- #12013
this PR introduced a mechanism to bypass tracer instrumentation during
ctypes loading, to avoid a possible loop that would prevent the WAF to
be loaded.

- [x] PR author has checked that all the criteria below are met
- The PR description includes an overview of the change
- The PR description articulates the motivation for the change
- The change includes tests OR the PR description describes a testing
strategy
- The PR description notes risks associated with the change, if any
- Newly-added code is easy to change
- The change follows the [library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html)
- The change includes or references documentation updates if necessary
- Backport labels are set (if
[applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting))

- [x] Reviewer has checked that all the criteria below are met
- Title is accurate
- All changes are related to the pull request's stated goal
- Avoids breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes
- Testing strategy adequately addresses listed risks
- Newly-added code is easy to change
- Release note makes sense to a user of the library
- If necessary, author has acknowledged and discussed the performance
implications of this PR as reported in the benchmarks PR comment
- Backport labels are set in a manner that is consistent with the
[release branch maintenance
policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)

(cherry picked from commit 4f0bcb5)
@avara1986 avara1986 added the ASM Application Security Monitoring label Feb 13, 2025
Copy link
Contributor

CODEOWNERS have been resolved as:

ddtrace/appsec/_constants.py                                            @DataDog/asm-python
ddtrace/appsec/_ddwaf/ddwaf_types.py                                    @DataDog/asm-python
ddtrace/appsec/_processor.py                                            @DataDog/asm-python
ddtrace/contrib/internal/subprocess/patch.py                            @DataDog/apm-core-python @DataDog/apm-idm-python
ddtrace/settings/asm.py                                                 @DataDog/asm-python

@avara1986 avara1986 closed this Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ASM Application Security Monitoring
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants