Pipask retrieves metadata through PyPI's JSON API first, then checks repository popularity, download counts, package age, and known vulnerabilities before allowing installation. It presents you with a pretty report and asks for you consent with installation, giving you control over what code runs on your system.
More details in the intro blog post: https://medium.com/data-science-collective/pipask-know-what-...
https://www.techradar.com/pro/security/ai-hallucinated-names...
I'll think about this use case more!
If you are willing to use a third-party package tool (big leap), I think it's a small step to use one that fixes all of pip's limitations, vice a single one.
Pip is nominally developed by separate people and isn't part of the standard library. However, it does ship with Python by default (Debian-based Linux distributions go out of their way to remove it), in the form of a wheel vendored within the standard library folders. The standard library module `ensurepip` is used to install that wheel - it bootstraps Pip's own code from within that wheel. This is also used indirectly by default when you create a new venv with the standard library `venv`.
(The reason uv can create environments quickly is that it skips that part, while otherwise following nominally the same logic. You can get the same effect by passing `--without-pip` to the `python -m venv` invocation, and it's actually faster (on my machine at least) than using uv. However, you then need to understand how to use pip cross-environment (it wasn't designed for that from the start, but modern pip offers support that's only a little bit buggy). I discuss this on my blog in https://zahlman.github.io/posts/2025/01/07/python-packaging-... .)
But I also get your point - advanced users who care about security may not be using pip. Implementing the functionality as a plugin for uv or poetry is actually the next step I'm considering, if people find the concept of pipask useful. What do you think?
What pip isn't is a workflow tool for developers, or "project manager" (terminology uv uses in its marketing; "package manager" seems to be not well enough defined to argue about). Pip doesn't install Python, create or manage virtual environments (or real ones for the separately installed Python versions), upload your packages to PyPI, view a lockfile as a way to keep track of an environment (although they have just added experimental support for creating PEP 751 lockfiles and are planning support for installing from them), do one-off runs of Python applications (by installing them in an ephemeral environment, possibly installing PEP 723 inline-specified dependencies), define or manage "workspaces", have its own `[tool.pip]` section in pyproject.toml, or possibly other things I forgot.
But it absolutely does determine the dependencies of the packages you're currently asking to install, transitively, attempt to figure out a compatible set of versions, and figure out which actual build artifacts to use (i.e., "resolve dependencies"). Its logic for doing so has even been extracted and made available as the `resolvelib` package (https://pypi.org/project/resolvelib/).
My own project, PAPER, is scoped to fix pip's problems and also do basic environment management (so as to install applications or do temporary runs). The point is to satisfy the needs of Python users, while not explicitly catering to developers. (I'll probably separately offer some useful developer scripts that leverage the functionality.)
I also, incidentally, intend to allow for this sort of prompt during the install procedure. (Although the planned default is to refuse sdists entirely.)
The project is still in quite early development stages, and not yet really usable for anything - I've been struggling to make myself sit down and implement even simple things, just personal issues. But the repository is at https://github.com/zahlman/paper and I am planning a Show HN when it seems appropriate. Hopefully the existing code at least gives an idea of the top-level design. I also described it a bit in https://news.ycombinator.com/item?id=43825508 .
I've also written a few posts on my blog (https://zahlman.github.io) about design problems with pip, and going forward I'll be continuing that, along with giving a basic overview of the PAPER design and explaining how it addresses the problems I've identified.
That said, it's pretty uncommon to use lockfiles with pip, so I'm considering creating something like a plugin for poetry or uv, if there is demand?
You're right I don't vendor dependencies, and I hope to get away with it exactly because I don't have the bootstrapping problem. In practice, you want to install pipask with pipx so that the dependencies don't mess with your local environment.
Using the fastapi example, it points to CVE-2024-24762 which, if you're looking at the NIST or CVE pages for it, doesn't give the clearest info for how to resolve.
Maybe consider linking to advisories in the Python Packaging Advisory Database when possible, like pip-audit does. https://osv.dev/vulnerability/PYSEC-2024-38 is a lot clearer that fastapi is affected and which version fixed the vulnerability.
Or are you saying you'd rather it leads to https://osv.dev/vulnerability/PYSEC-2024-38 rather than https://osv.dev/vulnerability/CVE-2024-24762 ?
Packj uses static+dynamic code/behavioral analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect impersonating packages (typo squatting).
omneity•13h ago
As in what’s the tradeoff that is being made when relying on pipask?
Feynmanix•10h ago
- installation takes a few more seconds to do the checks
- you need to trust me, a random person from the internet
- if there are any subtle differences between pip versions, the checks may be done for different versions than will be actually installed (I've done my best to prevent this for pip versions 22.2 to current latest), or if I missed any bugs, you may get an error you wouldn't get with pip
The current version is also interactive only - requires user confirmation, though I'm open to adding a non-interactive mode in the future.
omneity•8h ago
I'll give it a try!