Bump crypto-js from 4.1.1 to 4.2.0 in /research-hub-web

[dependabot]

Bumps crypto-js from 4.1.1 to 4.2.0.

Commits

• 808f499 Merge branch 'release/4.2.0'
• d5af3ae Update release notes.
• 9496e07 Bump version.
• 421dd53 Change default hash algorithm and iteration's for PBKDF2 to prevent weak secu...
• d1f4f4d Update grunt.
• c755289 Discontinued
• 1da3dab Discontinued
• 4dcaa7a Merge pull request #380 from Alanscut/dev
• 762feb2 chore: rename BF to Blowfish
• fb81418 feat: blowfish support
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[dependabot]

Dependabot tried to add @Trombach, @cakr322 and @eric-el-tan as reviewers to this PR, but received the following error from GitHub:

POST https://api.github.com/repos/UoA-eResearch/hub-stack/pulls/415/requested_reviewers: 422 - Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the UoA-eResearch/hub-stack repository. // See: https://docs.github.com/rest/pulls/review-requests#request-reviewers-for-a-pull-request

In general, the problem is fixed by explicitly setting permissions for the GITHUB_TOKEN either at the workflow root (applies to all jobs) or inside each job, granting only the minimal required scopes, typically contents: read for a pure linting job.

For this specific workflow, the simplest, least intrusive fix is to add a permissions: block at the top level (next to name: and on:), setting contents: read. This documents and enforces that the workflow only needs read access to repository contents, matching its actual behavior (checkout and lint) without changing existing functionality. No imports or external methods are involved because this is purely a YAML configuration change.

Concretely, in .github/workflows/linting.yml, insert:

permissions:
  contents: read

between the name: Lint line and the on: block. No other changes are needed.

In general, the problem is fixed by adding an explicit permissions block to the workflow or to the specific job, restricting the GITHUB_TOKEN to the minimal required scopes (typically contents: read for workflows that only need to read the repository). This both documents the intended privileges and prevents accidental privilege escalation if org/repo defaults change.

For this specific workflow, the sentry-release job checks out the repository and invokes getsentry/action-release with Sentry credentials. From the snippet, it does not modify GitHub issues, pull requests, or releases directly. The minimal safe permissions are therefore contents: read. The cleanest fix is to add a permissions: block under the sentry-release job definition (after runs-on: ubuntu-latest), setting contents: read. This will not change existing functionality, because read access to repository contents is already implied by current defaults and needed for actions/checkout@v2 to work.

No additional methods, imports, or definitions are necessary—only the new YAML keys within .github/workflows/sentry.yml.

In general, the fix is to sanitize untrusted data (here, event.body) before including it in log messages. For text logs, the main concern is line breaks and other control characters that can alter the structure of the log output. We should therefore create a sanitized version of event.body with \r and \n removed (and optionally other control characters), and log that instead. This preserves the content for debugging while preventing attackers from injecting extra log lines.

The best minimal fix in this file is to introduce a sanitized local variable right before logging, using String.prototype.replace with a regular expression that strips carriage returns and newlines from event.body, and then use that variable in the console.log call. For example, on line 53 we can change from logging event.body directly to: compute const sanitizedBody = String(event.body).replace(/[\r\n]/g, ''); and log sanitizedBody. Using String(...) guarantees that even if event.body is not a string, the code won’t throw. No new imports are needed; this uses only built-in JavaScript functionality.

Concretely, in hub-search-proxy/handler.js within the module.exports.search function, we will replace the existing console.log line with two lines: one to sanitize the body and one to log the sanitized value. All other behavior in the function remains unchanged.