返回资讯中心
外部精选
软件工程
#开发者实时流

Python's binary wheels and supply chain attacks

Python is known for fast packages despite being a slow language.

Hacker News 最新lumpa2026/10/17 · 21 天前6 分钟阅读

以下正文同步自 Hacker News 最新,版权归原站所有,已转换为易读排版。

Python is known for fast packages despite being a slow language. The fastest Python packages are written in compiled languages such as C, C++, or Rust, with Python acting only as a glue.

Python users usually don't even notice that, because PyPI (Python's package index) provides precompiled binaries. They are called wheels, and when you run pip install, it prefers them over the source distribution. For example, each release of my packages ships up to 90 different wheels. You need a separate binary wheel for each Python version, platform, and architecture combination. The regular distribution only contains the source code.

Without Python wheels, the distribution would be much harder. When wheels are not available, a user has to compile the code when installing a package. That requires the correct compiler and system dependencies.

Since I've spent quite a while analyzing malicious packages on PyPI, this got me thinking about wheels. As it turns out, they are a weak spot in the security of the Python ecosystem.

Almost every day, malicious Python packages are uploaded to PyPI. Most of them are typo-squatting attempts, but sometimes legit packages get compromised too. There are a lot of scanners that constantly analyze newly published packages for malicious behavior (such as mine). They analyze the code and rely on AST analysis, sandboxing, and LLMs.

But there is a problem - you can upload binaries that don't match the source.

An attacker can publish clean code and malicious binaries at the same time. There is no proper way to make sure a package was compiled using the same source code when it was uploaded to PyPI. Binary attestation is not mandatory either.

It's much harder to automatically analyze binaries for malicious behavior, especially when they contain unseen malware. They have to be reverse engineered. An attacker can plant a small implant that would only trigger after some time, and this can go unnoticed for weeks because most of the scanners are not ready for that. Specific platforms can also be targeted, such as Linux, where security software on machines is uncommon.

From what I've seen, there is very little focus in analyzing the binaries. The majority of startups analyze the source code.

I think it's inevitable that such attacks will become common.

The only solution that I see right now is to compile all Python dependencies from scratch and never install the most recent version.

If you have any questions, feel free to ask them via e-mail displayed in the footer.

All articles on this website are written by a human.

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →