Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update dependency sentry-sdk to v2.8.0 [security] - autoclosed #2733

Merged
merged 1 commit into from
Sep 26, 2024

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jul 18, 2024

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
sentry-sdk (changelog) ==2.3.1 -> ==2.8.0 age adoption passing confidence

GitHub Vulnerability Alerts

CVE-2024-40647

Impact

The bug in Sentry's Python SDK <2.8.0 results in the unintentional exposure of environment variables to subprocesses despite the env={} setting.

Details

In Python's subprocess calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use env argument in subprocess calls, like in this example:

>>> subprocess.check_output(["env"], env={"TEST":"1"})
b'TEST=1\n'

If you'd want to not pass any variables, you can set an empty dict:

>>> subprocess.check_output(["env"], env={})
b''

However, the bug in Sentry SDK <2.8.0 causes all environment variables to be passed to the subprocesses when env={} is set, unless the Sentry SDK's Stdlib integration is disabled. The Stdlib integration is enabled by default.

Patches

The issue has been patched in https://github.com/getsentry/sentry-python/pull/3251 and the fix released in sentry-sdk==2.8.0. The fix was also backported to sentry-sdk==1.45.1.

Workarounds

We strongly recommend upgrading to the latest SDK version. However, if it's not possible, and if passing environment variables to child processes poses a security risk for you, there are two options:

  1. In your application, replace env={} with the minimal dict env={"EMPTY_ENV":"1"} or similar.

OR

  1. Disable Stdlib integration:
import sentry_sdk

# Should go before sentry_sdk.init
sentry_sdk.integrations._DEFAULT_INTEGRATIONS.remove("sentry_sdk.integrations.stdlib.StdlibIntegration")

sentry_sdk.init(...)

References


Release Notes

getsentry/sentry-python (sentry-sdk)

v2.8.0

Compare Source

Various fixes & improvements

v2.7.1

Compare Source

Various fixes & improvements

v2.7.0

Compare Source

v2.6.0

Compare Source

v2.5.1

Compare Source

This change fixes a regression in our cron monitoring feature, which caused cron checkins not to be sent. The regression appears to have been introduced in version 2.4.0.

We recommend that all users, who use Cron monitoring and are currently running sentry-python ≥2.4.0, upgrade to this release as soon as possible!

Other fixes & improvements

v2.5.0

Compare Source

Various fixes & improvements
  • Allow to configure status codes to report to Sentry in Starlette and FastAPI (#​3008) by @​sentrivana

    By passing a new option to the FastAPI and Starlette integrations, you're now able to configure what
    status codes should be sent as events to Sentry. Here's how it works:

    from sentry_sdk.integrations.starlette import StarletteIntegration
    from sentry_sdk.integrations.fastapi import FastApiIntegration
    
    sentry_sdk.init(

...

  integrations=[
      StarletteIntegration(
          failed_request_status_codes=[403, range(500, 599)],
      ),
      FastApiIntegration(
          failed_request_status_codes=[403, range(500, 599)],
      ),
  ]

)


`failed_request_status_codes` expects a list of integers or containers (objects that allow membership checks via `in`)
of integers. Examples of valid `failed_request_status_codes`:

- `[500]` will only send events on HTTP 500.
- `[400, range(500, 599)]` will send events on HTTP 400 as well as the 500-599 range.
- `[500, 503]` will send events on HTTP 500 and 503.

The default is `[range(500, 599)]`.

See the [FastAPI](https://docs.sentry.io/platforms/python/integrations/fastapi/) and [Starlette](https://docs.sentry.io/platforms/python/integrations/starlette/) integration docs for more details.

- Support multiple keys with `cache_prefixes` (#&#8203;3136) by @&#8203;sentrivana
- Support integer Redis keys (#&#8203;3132) by @&#8203;sentrivana
- Update SDK version in CONTRIBUTING.md (#&#8203;3129) by @&#8203;sentrivana
- Bump actions/checkout from 4.1.4 to 4.1.5 (#&#8203;3067) by @&#8203;dependabot

v2.4.0

Compare Source

Various fixes & improvements

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added the renovate label Jul 18, 2024
@renovate renovate bot force-pushed the renovate/pypi-sentry-sdk-vulnerability branch from 10c3ae9 to 98a76e3 Compare September 3, 2024 12:47
@renovate renovate bot force-pushed the renovate/pypi-sentry-sdk-vulnerability branch from 98a76e3 to 2afb24a Compare September 26, 2024 12:29
@renovate renovate bot force-pushed the renovate/pypi-sentry-sdk-vulnerability branch from 2afb24a to 69ecc89 Compare September 26, 2024 12:31
@goapunk goapunk enabled auto-merge (rebase) September 26, 2024 12:31
@goapunk goapunk merged commit 6c93bf5 into main Sep 26, 2024
3 checks passed
@goapunk goapunk deleted the renovate/pypi-sentry-sdk-vulnerability branch September 26, 2024 12:41
@renovate renovate bot changed the title chore(deps): update dependency sentry-sdk to v2.8.0 [security] chore(deps): update dependency sentry-sdk to v2.8.0 [security] - autoclosed Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant