-
Notifications
You must be signed in to change notification settings - Fork 479
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
fix: Timeout Error with CVE-Bin-Tool Database Update/Download #4083
Comments
Darn, I was hoping that workaround will work. Fixing this should just involve fixing it so we don't get a stack trace if there's a timeout error, but we might want to also double-check that there's nothing weird with the link we're using for epss data. |
I've tried a couple of things but I can't seem to duplicate this myself easily even with an empty database. As tempting as it is to start messing with my routing table to see if I can make it happen, I think it probably makes more sense to just catch the timeout and hope we can work around it with me going in a bit blind? So I'm going to try to do that instead of bashing my head against it trying to figure out why it's happening. |
So it turns out the reason |
This will make it so that `-d EPSS` will actually disable the EPSS data source, and should make it fail more gracefully when the source is not working for any reason. Note that the EPSS source may not be working correctly even when not disabled; I'll file a separate issue. * fixes intel#4083 Signed-off-by: Terri Oda <[email protected]>
I've got a tentative fix in #4125 that may work for you. It should at least allow the EPSS data source to be disabled correctly as a workaround, as well as allow it to fail more gracefully. I haven't run it against the full test suite yet so it may need a bit of work still. |
This will make it so that `-d EPSS` will actually disable the EPSS data source, and should make it fail more gracefully when the source is not working for any reason. Note that the EPSS source may not be working correctly even when not disabled; I'll file a separate issue. * fixes intel#4083 Signed-off-by: Terri Oda <[email protected]>
This will make it so that `-d EPSS` will actually disable the EPSS data source, and should make it fail more gracefully when the source is not working for any reason. Note that the EPSS source may not be working correctly even when not disabled; I'll file a separate issue. * fixes intel#4083 Signed-off-by: Terri Oda <[email protected]>
This will make it so that `-d EPSS` will actually disable the EPSS data source, and should make it fail more gracefully when the source is not working for any reason. Note that the EPSS source may not be working correctly even when not disabled; I'll file a separate issue. * fixes intel#4083 Signed-off-by: Terri Oda <[email protected]>
@tvyavaha, did you by any chance run your original attempts behind a proxy? You mentioned switching between networks, but just in case - was there one where HTTPS connections are not/need not be proxied? I'm facing a similar timeout, and for me it's definitely the proxy, and the reason seems to be that EPSS data source code doesn't seem to support proxies (lines 72 and 92 need to be adjusted in the same way #923 did for #4125 is focusing on making it possible to properly disable this data source, but that is a separate story and I wonder if the actual root cause is the same for the issue I observe, and the one you did. If so, I think there's no point in submitting yet another issue on this, and otherwise I'd do that. |
@alext-w I reran the command without using a proxy, but it still fails at different points due to 'network unreachable' errors.
[10:39:18] DEBUG cve_bin_tool - Error while fetching GitLab Advisory Database CVEs : Cannot connect to host gitlab.com:443 ssl:default [Network is unreachable] gad_source.py:345 OSError: [Errno 101] Network is unreachable The above exception was the direct cause of the following exception: The above exception was the direct cause of the following exception: ________________________________ Traceback (most recent call last) _________________________________ ClientConnectorError: Cannot connect to host mirror.cveb.in:443 ssl:default [Network is unreachable] `` |
Let me see if I understand this correctly. By "reran the command without using a proxy", do you mean that you've used a network with direct Internet connection, where no proxy needs to be used? Alternatively, do you mean that the network does have a proxy, but you've deconfigured it before running the More specifically, can you maybe try with all but EPSS and NVD data sources disabled to limit the number of network connections it tries to establsh and see using e.g., Something like this: $ cve-bin-tool -l debug -d CURL,GAD,OSV,REDHAT,RSD -u now <...rest of the command line...> To illustrate, what I see is the following (with v3.3, the latest release, the network does have a proxy): $ cve-bin-tool -l debug -d CURL,GAD,OSV,REDHAT,RSD -u now --report --detailed <...>
<...>
[15:04:30] DEBUG cve_bin_tool.CVEDB - Year 2022 has 24754 CVEs in dataset nvd_source.py:505
[15:04:34] DEBUG cve_bin_tool.CVEDB - Year 2023 has 28085 CVEs in dataset nvd_source.py:505
[15:04:36] DEBUG cve_bin_tool.CVEDB - Year 2024 has 12313 CVEs in dataset nvd_source.py:505
[15:04:37] DEBUG cve_bin_tool.CVEDB - Check database is using latest schema cvedb.py:323
DEBUG cve_bin_tool.CVEDB - Check database is using latest schema cvedb.py:323
DEBUG cve_bin_tool.CVEDB - Check database is using latest schema cvedb.py:323
DEBUG cve_bin_tool.CVEDB - Check database is using latest schema cvedb.py:323
DEBUG cve_bin_tool.CVEDB - Check database is using latest schema cvedb.py:323
<HERE IT STALLS FOR ABOUT 5 MINUTES, WITH NETSTAT INDICATING A DIRECT CONNECTION ATTEMPT, THEN FAILS WITH TimeoutError> The $ netstat -aeptn |grep SYN
tcp 0 1 <my IP>:47948 18.66.233.97:443 SYN_SENT 1000 113280 14591/python After adding |
@alext-w In my scenario, I discovered that a proxy setup was necessary for internet connectivity. cve-bin-tool --nvd json-mirror -l debug -d CURL,GAD,OSV,REDHAT,RSD -u now -i installed_packages.txt I encountered a
By changing the aiohttp.ClientSession initialization to include |
Ok, thank you. Indeed then it looks like we have a common root cause here and that is the lack of proxy support for the EPSS source, which should be a two-line fix. |
That is great news! That said, I do want to make EPSS a source one can disable correctly, so I"ll finish up #4125 too even though it sounds like it won't be necessary to fix this issue. |
Thanks to @alext-w for finding this one. Needed to add trust_env=True to the aiohttp connections in the epss data source because otherwise it ignores proxy settings (and thus won't work at all for users behind a proxy) * fixes intel#4083 Signed-off-by: Terri Oda <[email protected]>
Thank you and yes, I think there's certainly value in being able to disable the EPSS source, so that other fix is much appreciated as well! |
Thanks to @alext-w for finding this one. Needed to add trust_env=True to the aiohttp connections in the epss data source because otherwise it ignores proxy settings (and thus won't work at all for users behind a proxy) * fixes #4083 Signed-off-by: Terri Oda <[email protected]>
Description
I'm experiencing a timeout error when updating/downloading the database using
cve-bin-tool --nvd api2
, even with thenvd_key
option and--nvd json-mirror
. This issue persists across different networks and has prevented me from using the tool effectively.Also I tried
--disable-data-source EPSS
option, but still getting the same timed out error.To reproduce
Steps to reproduce the behaviour:
Expected behaviour: No time out error.
Actual behaviour:
Version/platform info
Version of CVE-bin-tool( e.g. output of
cve-bin-tool --version
): 3.3.1dev0Installed from pypi or github? pypi
Operating system: Linux/Windows (other platforms are unsupported but feel free to report issues anyhow)
uname -a
x: ~>uname -a
Linux x 6.9.0-rc1+ SMP PREEMPT_DYNAMIC Fri Mar 29 08:33:41 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Python version (e.g.
python3 --version
): Python 3.11.6Running in any particular CI environment we should know about? (e.g. Github Actions) No.
The text was updated successfully, but these errors were encountered: