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.

Sign up for GitHub

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

Jump to bottom

Update dependency sentry-sdk to v2 [SECURITY] #134

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update dependency sentry-sdk to v2 [SECURITY] #134

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Aug 14, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
sentry-sdk (changelog) 1.45.0 -> 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

v2.3.1

Compare Source

Various fixes & improvements

v2.3.0

Compare Source

Various fixes & improvements

v2.2.1

Compare Source

Various fixes & improvements

v2.2.0

Compare Source

New features
  • Celery integration now sends additional data to Sentry to enable new features to guage the health of your queues
  • Added a new integration for Cohere
  • Reintroduced the last_event_id function, which had been removed in 2.0.0
Other fixes & improvements

v2.1.1

Compare Source

v2.1.0

Compare Source

v2.0.1

Compare Source

Various fixes & improvements

v2.0.0

Compare Source

This is the first major update in a long time!

We dropped support for some ancient languages and frameworks (Yes, Python 2.7 is no longer supported). Additionally we refactored a big part of the foundation of the SDK (how data inside the SDK is handled).

We hope you like it!

For a shorter version of what you need to do, to upgrade to Sentry SDK 2.0 see: https://docs.sentry.io/platforms/python/migration/1.x-to-2.x

New Features
  • Additional integrations will now be activated automatically if the SDK detects the respective package is installed: Ariadne, ARQ, asyncpg, Chalice, clickhouse-driver, GQL, Graphene, huey, Loguru, PyMongo, Quart, Starlite, Strawberry.
  • Added new API for custom instrumentation: new_scope, isolation_scope. See the Deprecated section to see how they map to the existing APIs.
Changed

(These changes are all backwards-incompatible. Breaking Change (if you are just skimming for that phrase))

  • The Pyramid integration will not capture errors that might happen in authenticated_userid() in a custom AuthenticationPolicy class.
  • The method need_code_loation of the MetricsAggregator was renamed to need_code_location.
  • The BackgroundWorker thread used to process events was renamed from raven-sentry.BackgroundWorker to sentry-sdk.BackgroundWorker.
  • The reraise function was moved from sentry_sdk._compat to sentry_sdk.utils.
  • The _ScopeManager was moved from sentry_sdk.hub to sentry_sdk.scope.
  • Moved the contents of tracing_utils_py3.py to tracing_utils.py. The start_child_span_decorator is now in sentry_sdk.tracing_utils.
  • The actual implementation of get_current_span was moved to sentry_sdk.tracing_utils. sentry_sdk.get_current_span is still accessible as part of the top-level API.
  • sentry_sdk.tracing_utils.add_query_source(): Removed the hub parameter. It is not necessary anymore.
  • sentry_sdk.tracing_utils.record_sql_queries(): Removed the hub parameter. It is not necessary anymore.
  • sentry_sdk.tracing_utils.get_current_span() does now take a scope instead of a hub as parameter.
  • sentry_sdk.tracing_utils.should_propagate_trace() now takes a Client instead of a Hub as first parameter.
  • sentry_sdk.utils.is_sentry_url() now takes a Client instead of a Hub as first parameter.
  • sentry_sdk.utils._get_contextvars does not return a tuple with three values, but a tuple with two values. The copy_context was removed.
  • If you create a transaction manually and later mutate the transaction in a configure_scope block this does not work anymore. Here is a recipe on how to change your code to make it work:
    Your existing implementation: 
    transaction = sentry_sdk.transaction(...)

later in the code execution:

with sentry_sdk.configure_scope() as scope:
    scope.set_transaction_name("new-transaction-name")
```

needs to be changed to this:
```python
transaction = sentry_sdk.transaction(...)

later in the code execution:

scope = sentry_sdk.get_current_scope()
scope.set_transaction_name("new-transaction-name")
```

  • The classes listed in the table below are now abstract base classes. Therefore, they can no longer be instantiated. Subclasses can only be instantiated if they implement all of the abstract methods.

    Show table
    Class Abstract methods
    sentry_sdk.integrations.Integration setup_once
    sentry_sdk.metrics.Metric add, serialize_value, and weight
    sentry_sdk.profiler.Scheduler setup and teardown
    sentry_sdk.transport.Transport capture_envelope
Removed

(These changes are all backwards-incompatible. Breaking Change (if you are just skimming for that phrase))

  • Removed support for Python 2 and Python 3.5. The SDK now requires at least Python 3.6.
  • Removed support for Celery 3.*.
  • Removed support for Django 1.8, 1.9, 1.10.
  • Removed support for Flask 0.*.
  • Removed support for gRPC < 1.39.
  • Removed support for Tornado < 6.
  • Removed last_event_id() top level API. The last event ID is still returned by capture_event(), capture_exception() and capture_message() but the top level API sentry_sdk.last_event_id() has been removed.
  • Removed support for sending events to the /store endpoint. Everything is now sent to the /envelope endpoint. If you're on SaaS you don't have to worry about this, but if you're running Sentry yourself you'll need version 20.6.0 or higher of self-hosted Sentry.
  • The deprecated with_locals configuration option was removed. Use include_local_variables instead. See https://docs.sentry.io/platforms/python/configuration/options/#include-local-variables.
  • The deprecated request_bodies configuration option was removed. Use max_request_body_size. See https://docs.sentry.io/platforms/python/configuration/options/#max-request-body-size.
  • Removed support for user.segment. It was also removed from the trace header as well as from the dynamic sampling context.
  • Removed support for the install method for custom integrations. Please use setup_once instead.
  • Removed sentry_sdk.tracing.Span.new_span. Use sentry_sdk.tracing.Span.start_child instead.
  • Removed sentry_sdk.tracing.Transaction.new_span. Use sentry_sdk.tracing.Transaction.start_child instead.
  • Removed support for creating transactions via sentry_sdk.tracing.Span(transaction=...). To create a transaction, please use sentry_sdk.tracing.Transaction(name=...).
  • Removed sentry_sdk.utils.Auth.store_api_url.
  • sentry_sdk.utils.Auth.get_api_url's now accepts a sentry_sdk.consts.EndpointType enum instead of a string as its only parameter. We recommend omitting this argument when calling the function, since the parameter's default value is the only possible sentry_sdk.consts.EndpointType value. The parameter exists for future compatibility.
  • Removed tracing_utils_py2.py. The start_child_span_decorator is now in sentry_sdk.tracing_utils.
  • Removed the sentry_sdk.profiler.Scheduler.stop_profiling method. Any calls to this method can simply be removed, since this was a no-op method.
Deprecated

do something


After:

```python
import sentry_sdk

with sentry_sdk.start_span(...):

### do something

  • Hub cloning is deprecated.

    Before:

    with Hub(Hub.current) as hub:

do something with the cloned hub


After:

```python
import sentry_sdk

with sentry_sdk.isolation_scope() as scope:

### do something with the forked scope

  • configure_scope is deprecated. Use the new isolation scope directly via get_isolation_scope() instead.

    Before:

    with configure_scope() as scope:

do something with scope


After:

```python
from sentry_sdk import get_isolation_scope

scope = get_isolation_scope()

v1.45.1

Compare Source

This is a security backport release.

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 requested review from thorwolpert and deetz99 as code owners August 14, 2024 22:28
@renovate Renovate
Copy link
Contributor Author

renovate bot commented Aug 14, 2024 •
edited
Loading

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: api/poetry.lock
Updating dependencies
Resolving dependencies...

Creating virtualenv developer-connect-api-CGodQ25B-py3.13 in /home/ubuntu/.cache/pypoetry/virtualenvs

Because auth-api (0.0.0) @ git+https://github.com/bcgov/sbc-auth.git@c286045eb2cf9761cd57b59aa4c6e7b3146ea36c#subdirectory=auth-api depends on launchdarkly-server-sdk (8.2.1)
 and developer-connect-api depends on launchdarkly-server-sdk (^8.3.0), auth-api is forbidden.
So, because developer-connect-api depends on auth-api (0.0.0) @ git+https://github.com/bcgov/sbc-auth.git@c286045eb2cf9761cd57b59aa4c6e7b3146ea36c#subdirectory=auth-api, version solving failed.

@renovate renovate bot changed the title chore(deps): update dependency sentry-sdk to v2 [security] Update dependency sentry-sdk to v2 [SECURITY] Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@thorwolpert thorwolpert Awaiting requested review from thorwolpert thorwolpert is a code owner

@deetz99 deetz99 Awaiting requested review from deetz99 deetz99 is a code owner

@kris-daxiom kris-daxiom Awaiting requested review from kris-daxiom kris-daxiom is a code owner

@kialj876 kialj876 Awaiting requested review from kialj876 kialj876 is a code owner

@pwei1018 pwei1018 Awaiting requested review from pwei1018 pwei1018 is a code owner

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants