updated for CSP compatibility: eval call in datasource-{min,debug}.js

[pyther-hub]

See JENKINS-71519. The code was modified where eval was utilized because it's discouraged to utilize eval for interpreting a string as JavaScript code.

Testing done

Proposed changelog entries

• JENKINS-XXXXX, human-readable text

Proposed upgrade guidelines

N/A

### Submitter checklist
- [x] The Jira issue, if it exists, is well-described.
- [x] The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see [examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)). Fill in the **Proposed upgrade guidelines** section only if there are breaking changes or changes that may require extra steps from users during upgrade.
- [ ] There is automated testing or an explanation as to why this change has no tests.
- [x] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadocs, as appropriate.
- [x] New deprecations are annotated with `@Deprecated(since = "TODO")` or `@Deprecated(forRemoval = true, since = "TODO")`, if applicable.
- [x] New or substantially changed JavaScript is not defined inline and does not call `eval` to ease future introduction of Content Security Policy (CSP) directives (see [documentation](https://www.jenkins.io/doc/developer/security/csp/)).
- [ ] For dependency updates, there are links to external changelogs and, if possible, full differentials.
- [ ] For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

### Maintainer checklist
- [ ] There are at least two (2) approvals for the pull request and no outstanding requests for change.
- [ ] Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
- [ ] Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood.
- [ ] Proper changelog labels are set so that the changelog can be generated automatically.
- [ ] If the change needs additional upgrade steps from users, the `upgrade-guide-needed` label is set and there is a **Proposed upgrade guidelines** section in the pull request title (see [example](https://github.com/jenkinsci/jenkins/pull/4387)).
- [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins.io/issues/?filter=12146)).

[welcome[bot]]

Yay, your first pull request towards Jenkins core was created successfully! Thank you so much!

A contributor will provide feedback soon. Meanwhile, you can join the chats and community forums to connect with other Jenkins users, developers, and maintainers.

[daniel-beck]

@pyther-hub Thanks for your PR. Are you aware of current uses of this code and if so, could you provide links to them or instructions how to test them? eval is more permissive than JSON#parse, so this may break existing uses.

[pyther-hub]

I attempted to locate some tests, but unfortunately, I was unable to find any as in the issue it was clearly mentioned of not using eval so made the changes according and even in the documentation I personally do not believe that there would be any issue with it, I would definitely try to find some test for this

[mawinter69]

Is the code with the eval ever reached with modern browser? I think we will always go into this if block else if(window.JSON && JSON.parse) { (lines 1064 resp. 1112)

[pyther-hub]

@mawinter69 could you explain it a more

[mawinter69]

See https://www.jenkins.io/doc/book/platform-information/support-policy-web-browsers/ for which browsers Jenkins supports. Now according to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON all browsers that Jenkins supports have a global JSON object and the parse method. So for them if(window.JSON && JSON.parse) will evaluate to true and we will never reach the eval code.

[pyther-hub]

Yes, I understand and agree with you. However, I believe it's important to address this for future considerations. If there are any changes, we should consider removing the 'eval'.

[zbynek]

@pyther-hub your code now is basically

if (window.JSON && JSON.parse) {
JSON.parse(stuff):
} else {
JSON.parse(stuff);
}

If we want to merge this PR I'd suggest to simplify this to

JSON.parse(stuff)

That being said, I think we're pretty close to removing all usages of YUI framework from core and then we don't have to care about the files changed in this PR.

• https://github.com/jenkinsci/jenkins/pull/9453 removes one of two usages of datasource in Jenkins core
• the other one can be safely moved from core after https://github.com/jenkinsci/jenkins/pull/7569

[mawinter69]

I started an epic to remote YUI from Jenkins: https://issues.jenkins.io/browse/JENKINS-73539 The last usage of YUI in core is then addressed by https://github.com/jenkinsci/jenkins/pull/9511

Besides core, I found 38 plugins that make direct usage of YUI, I opened corresponding issues for them. Some plugins are abandoned and haven't been released since years, but I'm confident we can get almost all plugins with more than 1000 installations to remove YUI. For several there are already PRs open that will remove YUI or I created PRs.

The complete list of plugins is here: https://docs.google.com/spreadsheets/d/1UjvtFmNmEdjMN5DUoFxJfBryA8q-E5_HwOzVKbVG9b0/edit?usp=sharing