HabrJuly 24, 2026🇷🇺Translated from Russian

Should Python Libraries Raise Minimum Dependency Versions to Block Vulnerable Releases?

Seth Larson of the Python Software Foundation has advised against automatically raising the minimum version of a dependency in a library’s metadata when a vulnerability is found. He argues that such metadata should describe only compatibility, leaving security control of the final build to the application.

The discussion began after a proposed pull request for an example library changed its urllib3 requirement from urllib3>=2 to urllib3>=2.6.3 following disclosure of a vulnerability affecting versions up to 2.6.2. Larson maintains that dependency ranges exist to express compatibility, not to enforce security fixes that the library does not ship itself.

According to the article, adopting this practice at scale would create unsustainable workload. More than 10,000 packages on the Python Package Index list urllib3 as a direct dependency. Similar numbers apply to numpy (approximately 80,000 dependents), requests (72,000), and pandas (55,000). Releasing new versions of every affected project after each published CVE would be impractical.

The recommended approach places responsibility on application owners. They should maintain a lockfile (requirements.txt with hashes, pylock.toml, or uv.lock) that records exact versions used in a build. Tools such as pip-audit or composition analysis solutions can then compare the resolved dependency graph against known vulnerabilities.

Exceptions are acknowledged. When a security fix removes functionality or breaks backward compatibility, adjusting the allowed range may be justified. Likewise, if an existing constraint prevents users from reaching a patched version, maintainers should consider widening or shifting the range to enable the secure update.

CodeScoring concludes that version bounds may reflect security requirements, yet they do not replace proper vulnerability management of the final product. Maintainers should publish affected and fixed version data, verify compatibility, and avoid blocking users from safe versions, while application owners retain control over the concrete dependency tree.

Related articles

HabrSupply Chain & Open Source

Unicode Tricks Let Malicious Python Code Bypass Code Review

A detailed analysis shows how subtle Unicode manipulations allow code to pass human review while executing entirely different logic. The first technique replaces Latin characters with visually identical Cyrillic or other script letters inside identifiers, such as using Ukrainian 'і' instead of Latin 'i' in an is_admin variable. Python treats these as distinct names because NFKC normalization does not map Cyrillic to Latin. The second technique inserts bidirectional override characters that reorder text for the compiler while the editor displays the intended order. The third hides zero-width characters inside string literals to break comparisons and searches. A compact Python auditor using the tokenize module and explicit character sets detects all three classes of characters. The article recommends adding such checks to CI pipelines and configuring linters including ruff and flake8 to reject suspicious commits.

HabrSupply Chain & Open Source

redb 3.7.2 Released with Custom gRPC Protocol, Dependency Vulnerability Fixes and .NET 10 Migration

The redb ecosystem released versions 3.7.0, 3.7.1 and 3.7.2 in quick succession after 3.7.0 was withdrawn due to high-severity vulnerabilities in its .NET 9 build artifacts. NuGet audit detected issues only on full rebuilds, leading to updates for SSH.NET, Microsoft.Data.Sqlite, System.Security.Cryptography.Xml and Microsoft.Bcl.Memory across redb.Route, redb.Core, redb.Export and redb.Identity. The release introduces a native GrpcWire implementation that registers individual gRPC methods as routes on a shared Kestrel host, supports bidirectional streaming, real gRPC status codes and mTLS with pinned client certificates. redb.Route also gained a dedicated SOAP connector, Control Bus messaging for route lifecycle management and a corrected Claim Check pattern. File transports received critical fixes that prevent silent data loss when readLock and idempotency options are combined. All libraries now target net8.0;net9.0;net10.0 while host applications require .NET 10, aligning with Microsoft’s shortened support timeline for .NET 8 and 9.

安全客Supply Chain & Open Source

Poisoned Rust Crates Execute Malware at Build Time: 245 Million Downloads Hit in Supply-Chain Attack

Three widely used Rust crates on crates.io were poisoned on August 20 with malicious versions that execute automatically during cargo build. The attack leveraged a typosquatted proc-macro1 dependency containing a build script that downloads payloads and establishes persistence. arrayref alone has accumulated 245 million downloads and is pulled automatically through caret ranges in many dependency trees. Attack infrastructure overlaps with prior campaigns attributed to Sapphire Sleet and MIDNIGHT NEPTUNE. Rust security teams yanked the malicious releases within 86-107 minutes, but the incident highlights missing publish-age controls and weak maintainer-account protections in the Cargo ecosystem.

HabrSupply Chain & Open Source

PyPI Explores Prefix Reservation for Organizations Under PEP 752 to Prevent Name Squatting

PEP 752 proposes reserving package name prefixes for organizations on PyPI, allowing control over entire families of related package names rather than individual entries. The change addresses dependency confusion and name squatting risks where attackers register packages with familiar prefixes like google-cloud- or opentelemetry- to exploit user trust. Analysis of over 800,000 PyPI projects by CodeScoring shows that prefixes are rarely controlled by a single owner, with ecosystems like aws- managed by hundreds of accounts. The proposal introduces implicit namespaces and new metadata for clients and proxies while preserving the flat namespace model familiar to Python developers. PEP 755 will define the governance process for granting prefix rights, limiting applications to organizations and requiring clear justification. Existing packages receive backward compatibility exceptions, and the mechanism does not transfer across repositories.