-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(PIP) Filter out packages from Python's std library #14
Comments
Hi! First of all, thanks for the tool. We should filter out the packages from the std library from the output. For example, sqlite3 is displayed as "takeovereable" but it's obviously not. This is because there is no package named sqlite3 on pypi, but pypi won't let you register it as it's part of the standard library. |
Here's a list for Python 3.9 for example (The same can be done for every version using https://pypi.org/project/stdlib-list/)
|
Hi, thanks for your kind words! In what kind of scenario do the stdlib packages end up in I would like to avoid adding such complexity if possible, but am willing to do so if I understand the actual use case. My initial thoughts are that the user might be better off by removing stdlib module entries from the In case we end up adding it, it should be possible to merge stdlib module names for python 2.6 - 3.9. I would imagine the PyPI blocklist applies to all of them regardless of the Python version. |
It does happen. in the last few days I've been researching this for a couple of big customers and found ~15 occurrences. Obviously, I can filter out them manually pretty easily but it wouldn't hurt to remove them automatically from the output. https://github.com/search?q=filename%3Arequirements.txt+sqlite3 |
Hmm. I looked into it, and correct me if I'm wrong but I think that this is a non-issue, reasoning below:
Please let me know if I'm missing something, as I'd like the tool to do the right thing :) |
Hmm I think I don't understand (this damn language barrier). I'm not saying that these represent a vulnerability or they are exploitable in any way. It's the opposite, these are not exploitable so we should hide them from the output. Obviously, no one is going to be able to takeover a std library name but it can create noise for people who are creating internal jira tickets based on the output of this tool. |
What I'm trying to communicate here, is that those entries should never be in the A typical way of using pip & Creating the requirements.txt
When the dependencies are reinstalled on a new dev environment, deployment etc:
Now if the stdlib packages are present in the |
Searching github for While it's definitely possible to filter for these types of things the trade-off is that the occurance of these non-standard Additionally, cloning one of the search results from Github which contained
This is further proof to the point that @lean0x2F could you provide insight into whether or not the projects you are researching do in fact use |
@n0ncetonic i haven’t tested this to confirm, but I’m betting that the Python projects that have stdlib package names in requirements.txt, setup.py, etc. are expecting/configured to fetch their dependencies from an internal Python package registry (e.g. corporate artifactory) where they’ve published a modified version of the stdlib package(s). Possible reasons for this might be to patch a bug or add some feature in sqlite3 or whatever. If internal/stdlib package names area being blocked by |
No description provided.
The text was updated successfully, but these errors were encountered: