Switch IP matcher implementation - #701
Conversation
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 Open source vulnerabilities detected - high severity
Aikido detected 2 vulnerabilities across 1 package, it includes 1 high and 1 medium vulnerabilities.
Details
Remediation:
setuptools— 2 CVEs (high) — fixed in 83.0.0
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
1a68b99 to
85987be
Compare
| assert matcher.has("::ffff:0.0.0.0") == True | ||
| assert matcher.has("::ffff:127.0.0.1") == True | ||
| assert matcher.has("::ffff:123") == True | ||
| assert matcher.has("::ffff:123") == False |
There was a problem hiding this comment.
This was actually wrong before (the test is also False in Node.js).
| packaging = "^24.1" | ||
| wrapt = "^1.17.2" | ||
| pytricia = { version = "^1.3.0", markers = "sys_platform != 'win32'" } | ||
| ipset_c = "0.2.1" |
There was a problem hiding this comment.
Locked dependency because it is not really popular and has single maintainer.
| [package.extras] | ||
| crt = ["botocore[crt] (>=1.37.4,<2.0a0)"] | ||
|
|
||
| [[package]] |
There was a problem hiding this comment.
Created issue in upstream as I think it shouldn't pull this in as runtime dependency.
| packaging = "^24.1" | ||
| wrapt = "^1.17.2" | ||
| pytricia = { version = "^1.3.0", markers = "sys_platform != 'win32'" } | ||
| ipset_c = "0.2.1" |
There was a problem hiding this comment.
🟡 Medium - Mandatory ipset_c dependency breaks installs on supported platforms without matching wheels
This unconditional runtime dependency is only published with CPython wheels for macOS 15 ARM64, manylinux_2_39 x86_64, and Windows amd64; the lock has no wheel for the repository's Linux ARM CI target, macOS x86_64, musllinux, or Linux systems with older glibc. Poetry/pip therefore falls back to the sdist and must compile the native extension, so ordinary production images without a C toolchain fail during dependency installation before the package can import, while the in-code fallback cannot help because resolution already requires this package. This regresses the documented Windows/Linux/macOS and Python 3.8-3.14 support rather than merely reducing performance on those environments.
Show fix
Either publish compatible ipset_c wheels for every supported interpreter/platform (including the minimum glibc and ARM/macOS targets), or make it an optional/platform-scoped dependency and arrange installation so unsupported environments can omit it and select the pure-Python matcher without a mandatory native build.
More info - Reply on this comment to give feedback or ignore the issue.
There was a problem hiding this comment.
Yes, but that is better than before? So it fallbacks to manual build on some systems but before it had to manually build on all systems as pytricia does not publish any prebuilt wheel?
| version = "75.3.4" | ||
| description = "Easily download, build, install, upgrade, and uninstall Python packages" | ||
| optional = false | ||
| python-versions = ">=3.8" | ||
| groups = ["main"] | ||
| markers = "python_version == \"3.8\"" |
There was a problem hiding this comment.
🟠 High - ipset_c adds vulnerable setuptools versions to Python 3.8 and 3.9 installs
The new ipset_c dependency declares unconstrained setuptools, and the lock consequently adds setuptools as a main dependency at 75.3.4 for Python 3.8 and 82.0.1 for Python 3.9, while the security scan identifies two setuptools CVEs fixed in 83.0.0. These versions are therefore installed into production environments that resolve the supported older Python interpreters, exposing package-build or installation paths to the known vulnerabilities even though setuptools was not previously a runtime dependency. The issue is distinct from the native-wheel coverage problem because it also affects otherwise successful installations.
Show fix
Do not ship setuptools as an unconstrained runtime dependency of ipset_c; fix the upstream package metadata to keep it in the build-system requirements, or constrain it to a security-fixed release compatible with each supported Python version and regenerate poetry.lock. Verify that the selected fixed release is actually supported on Python 3.8 and 3.9 before publishing.
More info - Reply on this comment to give feedback or ignore the issue.
There was a problem hiding this comment.
Created a issue in upstream
1 participant
No description provided.