[Snyk] Fix for 14 vulnerable dependencies

[ChristianMurphy]

Description

This PR fixes one or more vulnerable packages in the maven dependencies of this project. See the Snyk test report for more details.

Snyk Project: christianmurphy/uportal-home:web/pom.xml

Snyk Organization: ChristianMurphy

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • pom.xml

Vulnerabilities that will be fixed

With an upgrade:

• pom.xml
  • ch.qos.logback:logback-classic@1.0.12 > ch.qos.logback:logback-classic@1.2.0
    • Arbitrary Code Execution
    • Arbitrary Code Execution
  • edu.wisc.my.restproxy:rest-proxy-core@3.1.0 > edu.wisc.my.restproxy:rest-proxy-core@3.2.0
    • Denial of Service (DoS)
    • Deserialization of Untrusted Data
    • Deserialization of Untrusted Data
    • Deserialization of Untrusted Data
    • Deserialization of Untrusted Data
    • Deserialization of Untrusted Data
    • Denial of Service (DoS)
    • Denial of Service (DoS)
    • Reflected File Download
    • Reflected File Download
  • org.springframework:spring-core@4.1.5.RELEASE > org.springframework:spring-core@4.1.7.RELEASE
    • Denial of Service (DoS)
  • org.springframework:spring-web@4.1.5.RELEASE > org.springframework:spring-web@4.1.8.RELEASE
    • Reflected File Download
    • Denial of Service (DoS)
    • Denial of Service (DoS)
  • org.springframework:spring-webmvc@4.1.5.RELEASE > org.springframework:spring-webmvc@4.3.15.RELEASE
    • Directory Traversal
    • Multipart Content Pollution
    • Reflected File Download
    • Reflected File Download
    • Denial of Service (DoS)
    • Denial of Service (DoS)

You can read more about Snyk's upgrade and patch logic in Snyk's documentation.

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

Stay secure, The Snyk team

[ChristianMurphy]

Forwarded from https://github.com/ChristianMurphy/uportal-home/pull/1

[apetro]

I'm not entirely sure how to evaluate this Pull Request. If I pull down the branch and smoke test it locally, should we figure that's probably good enough, merge it, and see what happens?

[ChristianMurphy]

Basically, for uPortal core, we've checked:

1. that the code compiles
2. that the portal can start
3. that the module where the library is used can start

Breaking changes need most of the testing.

Here the riskiest change is the SemVer minor spring upgrade. If the software starts, the lion's share of risk has been mitigated.