Override URL for pypi service

[MichelEdkrantz]

Hi,
it would be very nice to be able to override the pypi vulnerability service url. There are multiple reasons:

• We would like to be able to do audit of our private packages as well using this tool, it seems like it should be possible if we can just supply the corresponding json response
• We don't like the idea of sending away our private package names to the public server
• We don't like when it reports private packages missing.

The url hard coded in the query method in the class PyPIService in https://github.com/pypa/pip-audit/blob/main/pip_audit/_service/pypi.py like

url = f"https://pypi.org/pypi/{spec.canonical_name}/{str(spec.version)}/json"

making it hard to override.

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Add an config flag or env variable (whatever you prefer) to make to be able to use a custom service for PYPI_SERVER_URL
url = f"{PYPI_SERVER_URL}/{spec.canonical_name}/{str(spec.version)}/json"

Describe alternatives you've considered

• Making a private fork
• Monkey patching, but would need to override the whole query method
• Request interception and replacing the outgoing url, also hacky.

Additional context

Would be happy to submit a PR if you think this is a good idea 😄 Thanks!

[di]

Hi @MichelEdkrantz, thanks for the issue. I'm struggling to understand the goal here, though: do you issue vulnerability advisories for your internal, private packages? Would a method to suppress checks for a set of internal package names be sufficient here instead?

[MichelEdkrantz]

Hi, thanks for the quick feedback :)
it might not be strictly "vulnerability advisories", but could also be for other auditing reasons, that we for some reason want to fail a package in the build if it uses old versions of internal dependencies that we know has some defect/issue.

When pip-audit fails, it will output the issue and an additional table of all our internal package that it could not find. This has been confusing for some of our developers, that are getting this feedback as part of our CI flow.

Being able to suppress checks for packages that we know won't be in public PyPI would be good also, and would take us a long way. But this is harder for us in reality since we don't have a list readily available of all my orgs public packages. For reference, we have an internal pypi proxy that we point pip install to, and have this either serve a private package or fallback to the public PyPI.

Makes sense?

[woodruffw]

it might not be strictly "vulnerability advisories", but could also be for other auditing reasons, that we for some reason want to fail a package in the build if it uses old versions of internal dependencies that we know has some defect/issue.

I understand this use case, but I think it probably implies a public stability contract that pip-audit currently doesn't make: we don't guarantee that the "vulnerability service" we contact responds with any particular format, since we may need to upgrade it behind the scenes to accomodate changes to PyPI (or OSV, or whatever else).

In other words: I think that allowing users to customize the vulnerability URL here would make other changes more burdensome for us down the line.

Taking a step back: have you considered refactoring your pip-audit use to be something like this?

• Collect/resolve the set of pinned dependencies you'd like to audit
• Filter them against your private index, leaving just the public ones
• Pass that set into pip-audit manually (e.g. pip-audit --no-deps -r reqs.txt)

This would effectively avoid leaking any of your private package names to the public index, would avoid the confusing messages you're currently seeing, and wouldn't require any upstream changes to pip-audit 🙂

[MichelEdkrantz]

Hi,
that makes a lot of sense. Thanks for your input on how to solve this, that should really do the trick and it's a much better approach for both of us :)

[woodruffw]

Glad to hear it!