Feynmanix

As long as they run `pip install` locally at any point in their process before pushing to the repo, they should get the opportunity to see the pipask report.

Have a look at the diagram in the accompanying blog post https://medium.com/data-science-collective/pipask-know-what-... , it explains how the process works.

In short, you can get metadata from pyproject.toml, but (a) it can still involve executing code due to PEP 517 hooks, and (b) a malicious package would use the legacy setup.py to get their code executed.

But before committing requirements.txt to git, they still run install locally, right?

Thanks, I'll have a look, possibly add a link to it

I'll have a look at that

Yes, I can! Will be in the next release

Do you have a link where I can learn more about PAPER?

It's not visible on the screenshot for some reason, but if you run the latest version, you'll notice a little underline under the CVE mention. It's actually a hyperlink (Cmd+click in iTerm2) that leads to https://osv.dev/vulnerability/CVE-2024-24762 where you can find out more.

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 ?

Yes, the reason I had to fork pip was that the dependency resolution logic is too complex and I couldn't recreate it from scratch with fidelity.

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.

Ideally, you should use lockfiles for your CI/CD or docker. To create or update the lockfile, a developer needs to install dependencies manually first (as in `pip install X` -> `pip freeze`), at which point the checks would be executed and the user would consent.

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?

Thanks! Good question. I think the main downsides are:

- 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.

Great point! If you alias pip to pipask in your .*rc file, than this should already work out of the box for some tools, but there may be problems such as the need for non-interactive flows and configuring failure thresholds.

I'll think about this use case more!

Perhaps it's not clear from my description above, but I'm afraid the flaw is in the Python package ecosystem itself rather than pip. I'm not very familiar with uv, but from what I can tell from the documentation, it needs to execute the same steps as pip to resolve metadata, as this is required by various PEPs. (You can have a look at the diagram in the linked blog post https://medium.com/data-science-collective/pipask-know-what-...).

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?