Make new release to address CVE-2020-15250

[josephjthomas]

The JUnit version this project uses, 4.10, is subject to a security vulnerability, this one: CVE-2020-15250.
This pull request #141 bumps JUnit to 4.13.2 which is no longer subject to the security vulnerability. Versions from 4.7 to 4.13.1 are affected.

I would kindly ask you @fangyidong to publish a new release, that is not subject to any security vulnerabilities. That would help me out a lot!

[manojTest]

Hi, Please address CVE-2020-15250 with updating the JUnit dependencies to 4.13.2.
Thanks

[srnyx]

@fangyidong Any plans on doing this?

[xehpuk]

Just exclude it in your pom.xml:

<dependency>
    <groupId>com.googlecode.json-simple</groupId>
    <artifactId>json-simple</artifactId>
    <version>1.1.1</version>
    <exclusions>
        <exclusion>
            <artifactId>junit</artifactId>
            <groupId>junit</groupId>
        </exclusion>
    </exclusions>
</dependency>

It was meant to be <scope>test</scope> anyway.

• MAVEN, json-simple 1.1.1 depends on Junit #91
• Request: New Maven release for Junit dependency scope change #131

[josephjthomas]

Just exclude it in your pom.xml:

Excluding the dependency is no solution, if you are working with security scanners.

[xehpuk]

Excluding the dependency is no solution, if you are working with security scanners.

Why? If it's not included, there's no vulnerability to report.

[josephjthomas]

Excluding the dependency is no solution, if you are working with security scanners.

Why? If it's not included, there's no vulnerability to report.

You failed to understand that different kinds of security scanners exist. Not every tool works on a repository basis or reads build files only. As I stated before, excluding a vulnerable dependency is no option.

Given the author is either unwilling or not interested to fix the issue, I initiated a fork & deploy process, to distribute builds unaffected by a vulnerability.

Thanks for your time.

[xehpuk]

You failed to understand that different kinds of security scanners exist. Not every tool works on a repository basis or reads build files only. As I stated before, excluding a vulnerable dependency is no option.

What does your tool work on if the vulnerability is literally non-existent? How does it detect the vulnerability?

[josephjthomas]

You failed to understand that different kinds of security scanners exist. Not every tool works on a repository basis or reads build files only. As I stated before, excluding a vulnerable dependency is no option.

What does your tool work on if the vulnerability is literally non-existent? How does it detect the vulnerability?

We iterate over public CVE lists. If a CVE posted affects a dependency we consume, regardless the underlaying issue is of concern or not, we evaluate a whole bunch of topics internally, finished up by evaluating whether we want to wait until a public fix is published and distributed, or if we want to initiate a fork and deploy process. The latter is the case if the affected project is a low-tier one and doesn't need immediate mitigation.
However, a fork and deploy process is an internal solution only our company and its subsidiaries can benefit from, and is generally the least step to take, followed up by updating all references from this project pointing to our own fork.

Your solution of excluding a dependency is not applicable, because I'm not a commiter of this project, https://github.com/fangyidong/json-simple, and I am not able to publish a fix under this project's namespace or update its version, which is flagged with a CVE.

Excluding the affected dependency on a local repository is no solution, because the local repository doesn't matter at all in this process, see the paragraph above.