Sync dev with master

[ucswift]

No description provided.

General approach: Avoid a single-pass multi-character regex that can leave partially stripped unsafe sequences. Either use a robust HTML/text extraction library or apply the regex replacement repeatedly until no tags remain. Since we are in a small Jest mock and should avoid adding heavy dependencies if possible, a looped replacement is an appropriate fix that preserves existing behavior (removing tags, leaving text).

Concrete best fix here:

• Keep the idea of stripping tags, but ensure that all occurrences of <...> patterns are removed, even if new ones are formed after a replacement.
• Replace the single call htmlContent.replace(/<[^>]*>/g, '') with a small loop that keeps replacing until the string no longer changes.
• This does not change public behavior of the tests (still removes tags and trims whitespace), but eliminates the incomplete sanitization pattern CodeQL is warning about.
• No new imports are required; we can implement the loop inline in the mock where textContent is defined.

Specific change:

• In src/components/contacts/__tests__/contact-notes-list.test.tsx, around line 27, replace:

  const textContent = htmlContent.replace(/<[^>]*>/g, '').trim();

  with:

  let textContent = htmlContent;
  let previous: string;
  do {
    previous = textContent;
    textContent = textContent.replace(/<[^>]*>/g, '');
  } while (textContent !== previous);
  textContent = textContent.trim();

This keeps the functionality (strip tags, then trim) but ensures all tags are removed even in pathological inputs.

In general, the fix is to avoid incomplete, home‑rolled regex stripping of HTML and instead rely on a well‑tested sanitization library or, at minimum, a more robust pattern that does not let <script or similar constructs survive. Since we are constrained to only edit this test file, the best approach is to change the mock implementation of stripHtmlTags so it uses a safer sanitization strategy.

Concretely, we will update the jest.mock('@/lib/utils', ...) block so that stripHtmlTags no longer uses the vulnerable html.replace(/<[^>]*>/g, ''). A minimal, safer approach within this context is to first remove any <script...>...</script> blocks with a script‑focused regex, then strip remaining tags. That addresses CodeQL’s specific concern about residual <script content while preserving the overall behavior (removing HTML tags for display in tests). We keep stripHtmlTags as a Jest mock (jest.fn) so existing tests that assert on mocking behavior continue to work.

Changes needed:

• In src/components/protocols/__tests__/protocol-card.test.tsx, replace the implementation of stripHtmlTags inside the jest.mock with a version that:
  • Returns '' for falsy input (same as before).
  • Removes <script> blocks using a reasonably standard script‑tag regex.
  • Removes remaining tags with a tag‑stripping regex.
    No new imports are required, as we only use built‑in string/regex operations inside the mock.

In general, to fix incomplete multi-character sanitization when stripping HTML, avoid ad‑hoc multi-character regexes like /\<[^>]*>/g and use a well-tested sanitization approach. For tests that just need to remove tags, a safer, character-based or looped replacement, or a battle-tested library such as sanitize-html, should be used instead of the fragile regex.

For this specific file, the simplest robust change is to replace the regex-based stripHtmlTags mock with an implementation that repeatedly removes any <...> tag-like construct until none remain. This directly addresses the “unsafe text reappearing” issue by looping until a fixpoint rather than relying on a single global replacement. Functionality from the test’s perspective stays the same—tags are stripped and plain text is returned—but the sanitization no longer suffers from the multi-character replacement weakness.

Concretely:

• In src/components/protocols/__tests__/protocol-details-sheet.test.tsx, in the Jest mock of '@/lib/utils', change the stripHtmlTags implementation.
• Replace html.replace(/<[^>]*>/g, '') with a small loop that keeps applying the same regex until the string stops changing. This avoids adding new dependencies and stays within the provided snippet.
• No new imports are required; the logic uses only built-in string and regex functionality.

To fix the issue, explicitly define permissions: for the workflow so that the GITHUB_TOKEN is restricted to the least privileges required. Since the shown jobs only need to read repository contents (checkout, install, test) and do not modify the repo (no pushes, no PR updates, no releases using GITHUB_TOKEN are evident), the minimal safe configuration is contents: read at the workflow root. Individual jobs can later override this if needed, but that’s outside the current change scope.

The single best change with minimal functional impact is:

• Add a top-level permissions: block right after the name: and before on: in .github/workflows/react-native-cicd.yml.
• Set contents: read there so all jobs (check-skip, test, build-and-deploy, etc.) inherit read-only repo access by default.

No imports or additional methods are needed—this is purely a YAML workflow configuration change in .github/workflows/react-native-cicd.yml.

To fix this, we should explicitly define minimal GITHUB_TOKEN permissions in the workflow. Since no job appears to require write access to repository contents, issues, or pull requests, we can set contents: read (and nothing else) at the workflow root. Defining permissions at the root applies to all jobs (check-skip, test, and build-and-deploy) unless they override it, satisfying CodeQL while following least privilege.

The best fix is to add a top-level permissions block right after the name: or on: section in .github/workflows/react-native-cicd.yml. This keeps existing behavior for the CI/CD pipeline (it only needs to read the repo) while constraining the GITHUB_TOKEN. No imports or additional methods are needed because this is a YAML workflow configuration change only. If a future job needs elevated permissions (for example, to push tags or create a GitHub Release), that specific job should define its own permissions block overriding the workflow default.

Concretely:

• In .github/workflows/react-native-cicd.yml, after the name: React Native CI/CD line (line 1), insert:

permissions:
  contents: read

This will address the CodeQL finding for the test job (and all other jobs) by explicitly limiting GITHUB_TOKEN to read-only repository contents.

To fix the issue, explicitly declare GITHUB_TOKEN permissions either at the workflow root or per job, granting only what each job needs. The check-skip and test jobs only require read access to repository contents to check out code, so they can use contents: read. The build-and-deploy job uploads artifacts and creates GitHub Releases via ncipollo/release-action@v1, which requires write access to repository contents/releases; the minimal appropriate scope is contents: write. Declaring these permissions removes reliance on the repository’s default token permissions and follows least-privilege principles.

Concretely, in .github/workflows/react-native-cicd.yml:

• Add a workflow-level permissions: contents: read near the top (after name: or after on:), so all jobs default to read-only.
• Override this in the build-and-deploy job by adding a permissions: block under that job with contents: write.
• We do not need additional scopes (pull-requests, issues, etc.) because nothing in the shown snippet writes to those resources.

No imports or additional methods are needed because this is a YAML workflow configuration change only.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

General approach: avoid relying on a multi-character, tag-shaped regex that can be susceptible to overlapping/malformed input. For a function whose purpose is to return plain text with no HTML semantics, the safest strategy is to (1) decode entities, (2) use a robust library to strip all tags, or if that is not available, (3) explicitly remove tag-like patterns and then remove any remaining </> characters so that no executable HTML can remain. This ensures that even if a crafted input defeats the tag regex, the remaining angle brackets needed to form <script> are removed.

Best fix within constraints: we should keep the existing behavior (decode then strip tags and trim whitespace) but strengthen the stripping step to avoid incomplete multi-character sanitization. Since adding a full HTML-sanitizer dependency may be heavy and we’re limited to the shown snippet, we can mitigate the CodeQL finding by:

1. Still decoding with he.decode.
2. First removing any sequences that look like tags with <[^>]*> (as today).
3. Then removing all remaining < and > characters in the intermediate string; this eliminates any chance that <script or any other HTML tag-like sequence remains executable.
4. Returning the result trimmed.

This keeps the function’s intention (“plain text with all HTML tags removed”) and only slightly changes behavior: previously, literal </> that were not part of tags might survive; now they will be removed, which is typically acceptable for a tag-stripping helper and is safer from an injection standpoint.

Concretely, in src/lib/utils.ts, lines 173–176 should be updated so that after decoded.replace(/<[^>]*>/g, ''), we also strip any residual < or > characters via a second .replace(/[<>]/g, ''). No new imports are required, and the rest of the file remains unchanged.

[ucswift]

Approve

[github-actions]

This PR is approved.