Skip to content
This repository has been archived by the owner on Dec 3, 2024. It is now read-only.

[Snyk] Security upgrade urllib3 from 1.23 to 1.26.18 #246

Open
wants to merge 540 commits into
base: master
Choose a base branch
from

Conversation

sscottgvit
Copy link
Contributor

This PR was automatically created by Snyk using the credentials of a real user.


Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.

Changes included in this PR

  • Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
    • requirements.txt
⚠️ Warning
flake8 5.0.4 has requirement importlib-metadata<4.3,>=1.1.0; python_version < "3.8", but you have importlib-metadata 6.7.0.

Vulnerabilities that will be fixed

By pinning:
Severity Issue Upgrade Breaking Change Exploit Maturity
high severity HTTP Header Injection
SNYK-PYTHON-URLLIB3-1014645
urllib3:
1.23 -> 1.26.18
No No Known Exploit
medium severity Regular Expression Denial of Service (ReDoS)
SNYK-PYTHON-URLLIB3-1533435
urllib3:
1.23 -> 1.26.18
No No Known Exploit
high severity CRLF injection
SNYK-PYTHON-URLLIB3-174323
urllib3:
1.23 -> 1.26.18
No Mature
high severity Improper Certificate Validation
SNYK-PYTHON-URLLIB3-174464
urllib3:
1.23 -> 1.26.18
No No Known Exploit
medium severity Information Exposure Through Sent Data
SNYK-PYTHON-URLLIB3-5926907
urllib3:
1.23 -> 1.26.18
No No Known Exploit
high severity Information Exposure Through Sent Data
SNYK-PYTHON-URLLIB3-5969479
urllib3:
1.23 -> 1.26.18
No No Known Exploit
medium severity Information Exposure Through Sent Data
SNYK-PYTHON-URLLIB3-6002459
urllib3:
1.23 -> 1.26.18
No No Known Exploit

Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the affected dependencies could be upgraded.

Check the changes in this PR to ensure they won't cause issues with your project.


Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic


Learn how to fix vulnerabilities with free interactive lessons:

🦉 Regular Expression Denial of Service (ReDoS)
🦉 CRLF injection

sscottgvit and others added 30 commits June 13, 2019 01:23
Changed links to govanguard.com, added Keybase team link.
- Addresses github issue #18
Update README typos and line wrapping
- Ran ui/eventfilter.py through CodeClimate CLI and is no longer showing any cognitive complexity issues in the logic
- The file was not loaded correctly by Legion on startup due to an error with a trailing single quote
- GitHub issue #19
- Introduce concept of Shell - which should abstract all operations pertaining to lower level OS calls, e.g. creating/removing directories, etc.
- This commit does not close issue #19 but is part of a series of commits to spend down the technical debt surrounding `logic.py` file
- This commit is the 2nd iteration on reducing complexity of `logic.py`
- Introduces the concept of a repository. A repository is an abstraction on a data store. In the case of Legion, the underlying data store is based on SQLite, and so the repository implementations should contain all SQL code within the app.
- There is a repository for each concept within the app, such as a Process, a Service, a Host, a Port, etc. (e.g. ProcessRepository, HostRepository, etc.)
- This commit does not complete the full refactoring of all SQL related code to a repository. Further commits will be added to complete the work.
- All new code added was driven by an underlying unit test. In order to gain confidence in proper refactoring of existing logic, a backporting of unit tests was needed.
t3chn0t3s and others added 27 commits June 16, 2022 20:18
Adding instructions to modify scan configurations
Added Cutycapt --insecure flag to ignore SSL/TLS certificate errors
…sh-1

Fix updateProgress to always use an integer
fix bad interpreter: /bin/bash^M: no such file or directory
Removed old dead links.
@sscottgvit sscottgvit force-pushed the master branch 3 times, most recently from 35e18d0 to ea40ce5 Compare November 4, 2024 18:10
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.