You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The version constraint == will introduce the risk of dependency conflicts because the scope of dependencies is too strict.
The version constraint No Upper Bound and * will introduce the risk of the missing API Error because the latest version of the dependencies may remove some APIs.
After further analysis, in this project,
The version constraint of dependency beautifulsoup4 can be changed to >=4.10.0,<=4.11.1.
The version constraint of dependency pyOpenSSL can be changed to >=0.14,<=22.0.0.
The version constraint of dependency python-dateutil can be changed to >=2.5.0,<=2.6.1.
The version constraint of dependency requests can be changed to >=0.2.1,<=0.2.3.
The version constraint of dependency requests can be changed to >=0.7.0,<=2.24.0.
The version constraint of dependency requests can be changed to ==2.26.0.
The version constraint of dependency pyasn1 can be changed to >=0.4.1,<=0.4.8.
The version constraint of dependency pyasn1-modules can be changed to >=0.0.3,<=0.2.8.
The above modification suggestions can reduce the dependency conflicts as much as possible,
and introduce the latest version as much as possible without calling Error in the projects.
The invocation of the current project includes all the following methods.
Sure, if you want to make a pull-request. I'm just wondering about the No Upper Bound rule. IMHO, security wise I prefer to not have any upper bound to ensure that people are running the latest version which might include security fixes. API breaking versus security vulnerability in this project, it's clearly the security fixes which are more important are the generator scripts are only to generate the JSON available in this repository.
Hi, In misp-warninglists, inappropriate dependency versioning constraints can cause risks.
Below are the dependencies and version constraints that the project is using
The version constraint == will introduce the risk of dependency conflicts because the scope of dependencies is too strict.
The version constraint No Upper Bound and * will introduce the risk of the missing API Error because the latest version of the dependencies may remove some APIs.
After further analysis, in this project,
The version constraint of dependency beautifulsoup4 can be changed to >=4.10.0,<=4.11.1.
The version constraint of dependency pyOpenSSL can be changed to >=0.14,<=22.0.0.
The version constraint of dependency python-dateutil can be changed to >=2.5.0,<=2.6.1.
The version constraint of dependency requests can be changed to >=0.2.1,<=0.2.3.
The version constraint of dependency requests can be changed to >=0.7.0,<=2.24.0.
The version constraint of dependency requests can be changed to ==2.26.0.
The version constraint of dependency pyasn1 can be changed to >=0.4.1,<=0.4.8.
The version constraint of dependency pyasn1-modules can be changed to >=0.0.3,<=0.2.8.
The above modification suggestions can reduce the dependency conflicts as much as possible,
and introduce the latest version as much as possible without calling Error in the projects.
The invocation of the current project includes all the following methods.
The calling methods from the beautifulsoup4
The calling methods from the pyOpenSSL
The calling methods from the python-dateutil
The calling methods from the requests
The calling methods from the pyasn1
The calling methods from the pyasn1-modules
The calling methods from the all methods
@developer
Could please help me check this issue?
May I pull a request to fix it?
Thank you very much.
The text was updated successfully, but these errors were encountered: