RetireJS execution

[gbena]

This issue is between DC and DC Jenkins plugin. It is very related to both, hence I am not sure where to open this issue. Here vs DC Jenkins Github space. Opening the issue here nevertheless.

It appears that there is an inconsistency between DC core/cli and DC Jenkins plugin.
As far as I can see, RetireJS in DC core is still seen as experimental, using the DC Jenkins plugin however, this scanner will be executed as default. Please correct me if my observation is wrong.

The discrepancy is an issue because the DC core is not downloading/updating the jsrepository.json from the retirejs. When running this on a pure Jenkins (scan, update repo/ --updateonly), there wont be any jsrepository.json downloaded in the data directory. This will fail the build.

I couldnt find a way to update the jsrepository.json using the cli. I tried --disableRetireJS false and --enableExperimental. None of the options work.

Also, wouldnt it be a better option (or at least supported by the DC plugin) that user/admin can provide the RetireJS URL instead of reading this from an environment variable, as this needs to be injected to Jenkins.

[stevespringett]

All analyzers are enabled by default in the Jenkins plugin. There was a time (not sure if this is still true) that experimental analyzers had to be enabled in Maven, Cli, etc, however, the Jenkins plugin always took the approach to enable everything and let the Jenkins admin disable whatever they did not want. This approach is by design.

The Retire.js analyzer needs access to GitHub in order to download. The Jenkins plugin does not have a way to specify an alternative URL. Also, the Jenkins plugin relies on config supplied globally, via job config or pipeline. If config is supplied to the plugin in an alternative way, it's outside the scope of the plugin.

Also, 3.3.1 was pushed out earlier today which solves an issue downloading jsrepository.json that affected cli, maven, jenkins, etc.

[jeremylong]

By default, the Maven, Gradle, and CLI interfaces require that you enable the experimental analyzers. This is because I wanted folks to know that they were using something experimental and forcibly turn it on.

[jortkoopmans]

Today I updated to v3.3.1, in response to the fix on #1394

My builds still break.

This is the log from one of the build slave nodes (centos 7):
Here's the gist

[stevespringett]

@jortkoopmans please enable debug logging for ‘org.owasp’ in the Jenkins logging config and post the results.

[gbena]

@stevespringett according to the release notes https://github.com/jeremylong/DependencyCheck/blob/master/RELEASE_NOTES.md#version-330-2018-07-22 ,one can update the environment variable analyzer.retirejs.repo.js.ur I tried to inject this environment variable into the job config to point to a different URL, but it doesnt seem to work. It is still trying to get the URL from github.

I tried both parameters analyzer.retirejs.repo.js.url and analyzer.retirejs.repo.js.ur, as I believe there is a typo in that release notes (It should be analyzer.retirejs.repo.js.url (url instead of ur)), but none of them are working. @stevespringett when you mentioned Jenkin plugin relies on config supplied globally, do you have any best practice you would recommend how to overwrite the retirejs url from Jenkins?

@jeremylong I agreed to that approach. I think it would be a better approach too if Jenkins Plugin is having the same behavior so that

1. folks know too that they are using something experimental on Jenkins Plugin as well
2. the behavior is consistent all over the place (maven, gradle, CLI and Jenkins plugin)

[stevespringett]

The release notes in this repo only partially apply to the Jenkins plugin, which has it's own repo, build environment, and feature/defect management system. The Jenkins plugin does not have release notes, rather it uses a change log that is attached to the plugins public wiki.

I believe the release notes you're referring to are incorrect. Dependency-Check doesn't use environment variables, rather it uses system properties to override behavior that is typically configured in dependency-check.properties. Since the property file cannot be easily modified in a Jenkins environment, using system properties may provide a way to modify the behavior - although untested and unsupported in the Jenkins plugin.

Try setting -Danalyzer.retirejs.repo.js.url to the URL of the local mirror. For example: http://myhost/mirror/jsrepository.json.

I honestly have no idea where this would need to be added - Jenkins master startup, node initialization, job config, etc.

If none of that works, a workaround would be to extract the hpi, find and modify dependency-check.properties with the URL to the mirror, repackage the hpi, and reinstall on master servers.

[elrond30]

Hello,
I'm having the same problem with the RetireJS. My problem is because I have two job. With the first I'm doing an Update Only, but I have a database to update the Dependency-Check. This jobs create the file jsrepository.json i the workspace. The second job analyze the dependencies. This jobs goes to search the file jsrepository.json to its own workspace. If I specified a data directory, the update won't be maked in the database.
Is there any way to specify where the jsrepository.josn fil is, withouth loosing the database update?
Thanks in advance

[stevespringett]

A shared data directory and a dedicated dc update job that blocks all other dc jobs is recommended.

Are you using the embedded H2 database or an external one?

[gbena]

Just for a heads-up, it looks like it is not possible to pass System Properties using "-D" to the Job to change the URL.

The workaround provided is helpful, but shouldnt be used as a permanent solution, as everytime a Dependency Check Jenkins Plugin is updated, all the effort needs to be repeated again.

I created an improvement ticket for Dependency Check Plugin to provide a configuration for an alternative URL https://issues.jenkins-ci.org/browse/JENKINS-52992

[gbena]

Is it possible to enable retirejs analyzer only in CLI, without enabling the rest of the experimental ones?
Setting this property analyzer.retirejs.enabled=true doesnt seem to work.

In the log file, it sees the property, but then resetting it to false afterward:

...
analyzer.retirejs.repo.validforhours='24'
analyzer.retirejs.repo.js.url='https://raw.githubusercontent.com/Retirejs/retire.js/master/repository/jsrepository.json'
analyzer.retirejs.enabled='true'
analyzer.retired.enabled='false'
DEBUG - Setting: analyzer.retirejs.enabled='false'

[gbena]

The answer of my question could relate to #1440

[jeremylong]

@gbena you would have to enable the experimental analyzers and then explicitly disable the experimental analyzers you do not want enabled.

[gbena]

@jeremylong, thanks for the feedback. The reason I said why this issue could relate to #1440 is that, when I enable this option alone (note the typo)

analyzer.retired.enabled=true

retirejs analyzer will kick. I dont have to enable the experimental analyzer at all. What I need to do is to enable that only. This makes me think that it is probably sufficient to enable

analyzer.retirejs.enabled=true

to just have retirejs analyzer enabled without enabling the other experimental analyzer.

On the other hand, I think activating analyzer.retired.enabled=true could have enabled all the retired analyzer, but then retirejs is actually experimental, and not retired. Does it get confused with experimental vs retired??

[jeremylong]

the retired vs retirejs was fixed in a previous release.