Does poetry expose users of private package indexes to supply chain attacks via transitive dependencies?

[jneleo]

There have been many issues about explicit sources and transitive dependencies, e.g. #8416 or #8102.

Goal:

My goal is to make sure that poetry does not search other indexes but source="private-index", even for transitive dependencies. For other packages, I also need access to PyPI.

Problem:

This doesn't seem to be possible though and leaves me vulnerable to malicious code introduced from packages that have the same name as the ones that I publish in my private-index .

Example:

I have created packages A, B, and C, where B and C are published in "private-index" so I've added an explicit source for private-index in each of the packages.:

[[tool.poetry.source]]
name = "private-index"
url = "..."
priority = "explicit"

If I try to poetry add B --source private-index, there is no source information available for C leading the command to fail. But the actual problem is that poetry will look whether C exists in PyPI, which makes me vulnerable to malicious code.

Failed Solutions:

I know two options:

1. poetry add C --source private-index to A. The problem is, you usually only realize this after you have already tried to poetry add B --source private-index and seeing it fail, so PyPI will already have been checked.
2. define "private-index" as a supplemental source in A. This will let the poetry add command succeed but actually means that the problem will persists because now PyPI will be checked every time I install package A.

Question:

So option 1 seems to be the least vulnerable alternative but still kind of sub-optimal. Am I missing something or is all of this by design and not going to change?

[dimbleby]

the usual way to take control of such things is to set up your own repository, mirroring from pypi the things that you want to mirror from pypi, and use only that

if you want to make your private repository the default and pypi an "explicit" repository then you can do that

[jneleo]

Hey, thanks for your suggestions!

Mirroring PyPI
I think this might be the best solution. However, I'm not sure how much work and maintenance this will take. I'm not sure if I have the resources to do this. Needs some more research and contemplation from my side.

"explicit" PyPI
This is similar to Option 1 in my original post. Your suggestion is safe but unfortunately involves a lot of overhead because: I need to set the source key to pypi for every dependency and all transitive dependencies that are not in "private-index". Even for small organization this seems to be impractical.

"supplemental" PyPI
If instead I set pypi as "supplemental" I don't have to add the source keys. The biiig downside though is that my private-index will be checked for every package but most of the packages are not even in there. Dependency solving time goes through the roof (15s to almost 500s for a simple example that I ran)!

Going Forward I'll assess the PyPI mirror and if setting it up and maintaining it is too much work I will probably go with Option 1 from my original post. In the meantime, if someone else wants to share there experiences with this topic, I'd highly appreciate it.

Have a nice weekend!