Skip to content

build(deps): bump urllib3 from 2.6.3 to 2.7.0#5

Open
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/uv/urllib3-2.7.0
Open

build(deps): bump urllib3 from 2.6.3 to 2.7.0#5
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/uv/urllib3-2.7.0

Conversation

@dependabot
Copy link
Copy Markdown

@dependabot dependabot Bot commented on behalf of github May 11, 2026

Bumps urllib3 from 2.6.3 to 2.7.0.

Release notes

Sourced from urllib3's releases.

2.7.0

🚀 urllib3 is fundraising for HTTP/2 support

urllib3 is raising ~$40,000 USD to release HTTP/2 support and ensure long-term sustainable maintenance of the project after a sharp decline in financial support. If your company or organization uses Python and would benefit from HTTP/2 support in Requests, pip, cloud SDKs, and thousands of other projects please consider contributing financially to ensure HTTP/2 support is developed sustainably and maintained for the long-haul.

Thank you for your support.

Security

Addressed high-severity security issues. Impact was limited to specific use cases detailed in the accompanying advisories; overall user exposure was estimated to be marginal.

  • Decompression-bomb safeguards of the streaming API were bypassed:

    1. When HTTPResponse.drain_conn() was called after the response had been read and decompressed partially. (Reported by @​Cycloctane)
    2. During the second HTTPResponse.read(amt=N) or HTTPResponse.stream(amt=N) call when the response was decompressed using the official Brotli library. (Reported by @​kimkou2024)

    See GHSA-mf9v-mfxr-j63j for details.

  • HTTP pools created using ProxyManager.connection_from_url did not strip sensitive headers specified in Retry.remove_headers_on_redirect when redirecting to a different host. (GHSA-qccp-gfcp-xxvc reported by @​christos-spearbit)

Deprecations and Removals

  • Used FutureWarning instead of DeprecationWarning for better visibility of existing deprecation notices. Rescheduled the removal of deprecated features to version 3.0. (urllib3/urllib3#3763)
  • Removed support for end-of-life Python 3.9. (urllib3/urllib3#3720)
  • Removed support for end-of-life PyPy3.10. (urllib3/urllib3#4979)
  • Bumped the minimum supported pyOpenSSL version to 19.0.0. (urllib3/urllib3#3777)

Bugfixes

  • Fixed a bug where HTTPResponse.read(amt=None) was ignoring decompressed data buffered from previous partial reads. (urllib3/urllib3#3636)
  • Fixed a bug where HTTPResponse.read() could cache only part of the response after a partial read when cache_content=True. (urllib3/urllib3#4967)
  • Fixed HTTPResponse.stream() and HTTPResponse.read_chunked() to handle amt=0. (urllib3/urllib3#3793)
  • Updated _TYPE_BODY type alias to include missing Iterable[str], matching the documented and runtime behavior of chunked request bodies. (urllib3/urllib3#3798)
  • Fixed LocationParseError when paths resembling schemeless URIs were passed to HTTPConnectionPool.urlopen(). (urllib3/urllib3#3352)
  • Fixed BaseHTTPResponse.readinto() type annotation to accept memoryview in addition to bytearray, matching the io.RawIOBase.readinto contract and enabling use with io.BufferedReader without type errors. (urllib3/urllib3#3764)
Changelog

Sourced from urllib3's changelog.

2.7.0 (2026-05-07)

Security

Addressed high-severity security issues. Impact was limited to specific use cases detailed in the accompanying advisories; overall user exposure was estimated to be marginal.

  • Decompression-bomb safeguards of the streaming API were bypassed:

    1. When HTTPResponse.drain_conn() was called after the response had been read and decompressed partially.
    2. During the second HTTPResponse.read(amt=N) or HTTPResponse.stream(amt=N) call when the response was decompressed using the official Brotli <https://pypi.org/project/brotli/>__ library.

    See GHSA-mf9v-mfxr-j63j <https://github.com/urllib3/urllib3/security/advisories/GHSA-mf9v-mfxr-j63j>__ for details.

  • HTTP pools created using ProxyManager.connection_from_url did not strip sensitive headers specified in Retry.remove_headers_on_redirect when redirecting to a different host. (GHSA-qccp-gfcp-xxvc <https://github.com/urllib3/urllib3/security/advisories/GHSA-qccp-gfcp-xxvc>__)

Deprecations and Removals

  • Used FutureWarning instead of DeprecationWarning for better visibility of existing deprecation notices. Rescheduled the removal of deprecated features to version 3.0. ([#3763](https://github.com/urllib3/urllib3/issues/3763) <https://github.com/urllib3/urllib3/issues/3763>__)
  • Removed support for end-of-life Python 3.9. ([#3720](https://github.com/urllib3/urllib3/issues/3720) <https://github.com/urllib3/urllib3/issues/3720>__)
  • Removed support for end-of-life PyPy3.10. ([#4979](https://github.com/urllib3/urllib3/issues/4979) <https://github.com/urllib3/urllib3/issues/4979>__)
  • Bumped the minimum supported pyOpenSSL version to 19.0.0. ([#3777](https://github.com/urllib3/urllib3/issues/3777) <https://github.com/urllib3/urllib3/issues/3777>__)

Bugfixes

  • Fixed a bug where HTTPResponse.read(amt=None) was ignoring decompressed data buffered from previous partial reads. ([#3636](https://github.com/urllib3/urllib3/issues/3636) <https://github.com/urllib3/urllib3/issues/3636>__)
  • Fixed a bug where HTTPResponse.read() could cache only part of the response after a partial read when cache_content=True.

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Bumps [urllib3](https://github.com/urllib3/urllib3) from 2.6.3 to 2.7.0.
- [Release notes](https://github.com/urllib3/urllib3/releases)
- [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst)
- [Commits](urllib3/urllib3@2.6.3...2.7.0)

---
updated-dependencies:
- dependency-name: urllib3
  dependency-version: 2.7.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code labels May 11, 2026
dangyajun pushed a commit to dangyajun/lib-common that referenced this pull request May 13, 2026
Because our el_wake API didn't use explicit memory barriers between the
read/write synchronizations points TSAN reported data race such as the
one below:

WARNING: ThreadSanitizer: data race
  Write of size 8 by main thread:
    #0 close <null>
    Intersec#1 el_fd_unregister ./src/core/el-epoll.in.c:109:13
    Intersec#2 el_wake_unregister ./src/core/el.blk:1645:9
    Intersec#3 el_unregister ./src/core/el.blk:1894:36
    Intersec#4 dns_resolv_ctx_wipe ./src/net/addr.blk:239:5
    Intersec#5 dns_resolv_ctx_delete ./src/net/addr.blk:245:1
    #6 ____addr_info_async_block_invoke ./src/net/addr.blk:297:9
    #7 el_wake_on_event ./src/core/el.blk:1607:9
    #8 el_fd_fire ./src/core/el.blk:1307:13
    #9 el_fds_loop ./src/core/el.blk:1461:17
    #10 z_connect_ics_from_addr_and_wait ./tests/zchk-iop-rpc.c:316:13
    #11 __z_iop_rpc_block_invoke_6 ./tests/zchk-iop-rpc.c:608:9
    #12 z_iop_rpc ./tests/zchk-iop-rpc.c:640:7
    #13 z_run ./src/core/z.blk:1545:9
    #14 main ./tests/zchk.c:1206:12

  Previous read of size 8 by thread T8:
    #0 write <null>
    Intersec#1 el_wake_fire ./src/core/el.blk:1660:5
    Intersec#2 ____addr_info_async_block_invoke_2 ./src/net/addr.blk:331:9
    Intersec#3 job_run ./src/core/thr-job.blk:281:9
    Intersec#4 thr_run_deque_entry ./src/core/thr-job.blk:381:12
    Intersec#5 thr_job_try_steal ./src/core/thr-job.blk:473:20
    #6 thr_job_steal ./src/core/thr-job.blk:513:15
    #7 thr_job_main ./src/core/thr-job.blk:874:13
    #8 thr_hooks_wrapper ./src/core/thr.c:89:11

Indeed even if the eventfd() API ensures the thread safety of the
write/read sequence we still have to ensure no more usage of the fd
itself is possible before closing it.

Thus we add an explicit memory barrier in the form of an atomic counter.

Change-Id: I519147361d912e155341eec76f1fb4018699235c
Priv-Id: b1aef4b55b87f433f478950e7b79207846a0f623
dangyajun pushed a commit to dangyajun/lib-common that referenced this pull request May 13, 2026
thr_queue_drain() seemed to assume that no other thread is running the
queue when used and thus started with an `atomic_store(&q->running_on,
id)` without taking care of the current `running_on` value.

But when destroying a queue (`thr_queue_destroy`) TSAN reported this
race:

WARNING: ThreadSanitizer: data race
  Write of size 8  by main thread:
    #0 free <null>
    Intersec#1 libc_free ./src/core/mem.blk:140:9
    Intersec#2 mp_ifree ./src/core/mem.blk:351:5
    Intersec#3 thr_queue_delete ./src/core/thr-job.blk:574:1
    Intersec#4 thr_queue_drain ./src/core/thr-job.blk:618:9
    Intersec#5 thr_queue_sync ./src/core/thr-job.blk:705:13
    #6 thr_queue_destroy ./src/core/thr-job.blk:730:9
    #7 test_queue ./tests/zchk-thrjob.blk:381:9
    #8 __z_thrjobs_block_invoke_4 ./tests/zchk-thrjob.blk:647:9
    #9 z_thrjobs ./tests/zchk-thrjob.blk:648:7
    #10 z_run ./src/core/z.blk:1545:9
    #11 main ./tests/zchk.c:1206:12

  Previous atomic write of size 8 at 0x7210000001e0 by thread T28:
    #0 thr_queue_drain ./src/core/thr-job.blk:614:5
    Intersec#1 thr_queue_run ./src/core/thr-job.blk:624:5
    Intersec#2 job_run ./src/core/thr-job.blk:285:9
    Intersec#3 thr_run_deque_entry ./src/core/thr-job.blk:381:12
    Intersec#4 thr_job_try_steal ./src/core/thr-job.blk:473:20
    Intersec#5 thr_job_steal ./src/core/thr-job.blk:513:15
    #6 thr_job_main ./src/core/thr-job.blk:884:25
    #7 thr_hooks_wrapper ./src/core/thr.c:89:11

Indeed when finishing to drain the queue, another would finished by:

    do {
        […]
    } while (!mpsc_queue_drain_end(&it, &thr_qnode_destroy));
    atomic_compare_exchange_strong(&q->running_on, &id,
                                   THR_QUEUE_NOT_RUNNING);

So after removing the last element of the queue (`mpsc_queue_drain_end`)
the queue's `running_on` is reset to THR_QUEUE_NOT_RUNNING.

But when destroying, the sole condition to immediately drain the queue
is:

    if (mpsc_queue_push(&q->q, &n->qnode)) {
        thr_queue_drain(q);

So the race is obvious here, as soon as the queued is emptied, the
destroying thread could already be freeing the queue while the previous
thread could still be trying to reset `q->running_on`.

To fix we now actually wait for the queue to be release before draining
it again.

Change-Id: I159d6426ec7ace01d0e7aaf685a7e32a6bf31749
Priv-Id: 07021192cda3217760c2ba85fc0fa12af17ef20f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants