Rn main

[ucswift]

No description provided.

[coderabbitai]

Important

Review skipped

Too many files!

25 files out of 175 files are above the max files limit of 150.

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.}

In general, the fix is to explicitly declare permissions for the workflow (or per job) so that the GITHUB_TOKEN does not silently inherit overly broad repository defaults. Start from a minimal read-only configuration and only add more granular write permissions where a job truly needs them.

The best single change here, without altering existing functionality, is to add a permissions block at the top (root) level of .github/workflows/react-native-cicd.yml, just below the on: section (and before env:). From the visible snippet, none of the shown jobs push commits, create releases, modify issues/PRs, or otherwise write back to the repository via GITHUB_TOKEN; they mainly use checkout, caching, Node setup, dependency install, tests, and likely builds/deploys that rely on external secrets. All of these operations work with contents: read. Therefore, we can safely set:

permissions:
  contents: read

at the workflow root. This will apply to all jobs (check-skip, test, build-and-deploy, etc.) that do not override permissions. If any hidden portion of the workflow later requires write access to specific resources, an additional permissions block can be added for that specific job with the needed granular write scopes. No imports or extra definitions are required; this is purely a YAML configuration change.

In general, the fix is to explicitly set permissions: for the workflow or for each job so that the GITHUB_TOKEN only has the minimum scopes needed. For the test job (and the other jobs shown), the steps only read repository contents (via actions/checkout) and use external services/secrets; they do not need to write to the repo or to PRs. The simplest and safest choice is to define a workflow-level permissions: contents: read, which applies to all jobs (check-skip, test, build-and-deploy) and satisfies CodeQL’s recommendation.

Concretely, in .github/workflows/react-native-cicd.yml, add a root-level permissions: block right after the name: (line 1–2 area) and before the on: block starting at line 3. Set contents: read as a minimal default; if any job later needs more (e.g., pull-requests: write), it can override permissions at the job level without affecting this fix. No additional imports or methods are required because this is a YAML configuration change only.

In general, the fix is to explicitly define permissions: for the workflow or for individual jobs so that the GITHUB_TOKEN is scoped to the least privileges required. For CI-only jobs, contents: read is usually enough. For jobs that create releases or modify repository content, we add targeted write permissions like contents: write.

For this workflow, the simplest non-breaking change is to add a top-level permissions: block that applies to all jobs, setting contents: write. The build-and-deploy job needs contents: write so that ncipollo/release-action@v1 can create or update GitHub Releases. The check-skip and test jobs don’t need write access, but inheriting contents: write from the root is acceptable and keeps the edit small and clear. We will insert the permissions: block near the top of the file, after name: and before on:. No extra imports or dependencies are needed; this is purely a YAML configuration change.

Concretely, in .github/workflows/react-native-cicd.yml, between line 1 (name: React Native CI/CD) and line 3 (on:), we will add:

permissions:
  contents: write

This explicitly narrows the GITHUB_TOKEN to repository contents only, instead of potentially broader default permissions, and provides the write access required for creating releases.

In general, the fix is to avoid implementing ad‑hoc HTML “sanitization” with a single fragile regex that removes whole tags. Instead, either (a) use a real HTML parser / sanitization library, or (b) if we just need text content, parse HTML into a DOM-like structure and extract text nodes. This avoids the multi-character replacement issue (where replacing a long pattern lets a new instance of the pattern appear) and avoids the common pitfalls of regex-based HTML parsing.

For this specific test file, the intent is only to “extract text content from HTML (removing tags)” to feed into a Text component. We can most closely preserve existing behavior by using a small, well-known HTML parsing library to convert htmlContent to plain text. A simple and robust option is html-to-text, which is widely used to turn HTML into readable text. We will:

• Add an import for html-to-text at the top of this test file.
• Replace the line using htmlContent.replace(/<[^>]*>/g, '').trim(); with a call to htmlToText that converts the HTML into text, and trims it.

Concretely, in src/components/contacts/__tests__/contact-notes-list.test.tsx:

• Add import { htmlToText } from 'html-to-text'; after the existing imports.
• Change line 27 to: const textContent = htmlToText(htmlContent).trim();

This removes the fragile regex, uses a library designed for this transformation, and keeps the rest of the mock and tests unchanged.

In general, the problem is that /\<[^>]*>/g is a simplistic, custom HTML-stripper regex that can leave unsafe substrings (like parts of <script> tags) in the string and is susceptible to incomplete multi-character sanitization. The recommended approach is to avoid rolling a custom sanitizer and instead rely on a well-tested HTML sanitization/stripping library, or at least use a more robust pattern that better approximates what production code should do.

For this specific file, the best fix that does not change the intended test functionality is to update the Jest mock of stripHtmlTags to use a library that properly strips/sanitizes HTML, while keeping the same signature and behavior for non-string inputs. Since we can only modify code in this file, we can introduce an import of a known library such as sanitize-html and then implement stripHtmlTags as a thin wrapper around it, returning an empty string for falsy input (to preserve existing behavior). This addresses CodeQL’s “incomplete multi-character sanitization” complaint and makes the test mock more realistic. Concretely:

• Add import sanitizeHtml from 'sanitize-html'; at the top of src/components/protocols/__tests__/protocol-card.test.tsx alongside the existing imports.
• Change the stripHtmlTags mock implementation from:
  • stripHtmlTags: jest.fn((html) => html ? html.replace(/<[^>]*>/g, '') : ''),
    to:
  • stripHtmlTags: jest.fn((html) => html ? sanitizeHtml(html, { allowedTags: [], allowedAttributes: {} }) : ''),
• This keeps the same external interface while using a robust library internally.

In general, the right fix is to avoid hand‑written, brittle regex‑based HTML “sanitizers” and instead rely on a well‑tested library that correctly handles nested tags, edge cases, and multi‑character replacement issues. In Node/JS, a common choice is sanitize-html. Even though this is test code, we can update the mock stripHtmlTags to delegate to sanitize-html so that tests better match real‑world, safe sanitization behavior and eliminate the multi‑character replacement issue entirely.

Concretely, in src/components/protocols/__tests__/protocol-details-sheet.test.tsx, locate the jest.mock('@/lib/utils', ...) block around line 17. Replace the current stripHtmlTags mock implementation:

stripHtmlTags: jest.fn((html) => html ? html.replace(/<[^>]*>/g, '') : ''),

with an implementation that calls sanitize-html with a strict configuration that removes all tags and attributes, returning plain text. We will first require/import sanitize-html at the top of the file, then define stripHtmlTags to call sanitizeHtml(html, { allowedTags: [], allowedAttributes: {} }) when html is non‑empty, and return an empty string otherwise. This preserves the existing functional contract (string in, string out, empty string for falsy input) while eliminating the problematic regex and making the sanitization robust to multi‑character issues.

Because we are only allowed to modify this file, we will add a new import (or require) for sanitize-html at the top next to the existing imports and adjust only the stripHtmlTags line within the jest.mock call.

In general, the safest fix is to avoid hand-written regex-based HTML stripping and instead use a robust, battle-tested HTML sanitizer/stripping library. This reduces the risk of multi-character sanitization issues and other parsing edge cases that regexes cannot handle correctly. For this codebase, we should replace the current stripHtmlTags implementation with one that delegates HTML parsing/stripping to a library that knows how to handle broken tags, nested elements, and script/style content, and returns plain text.

The best targeted fix without changing external behavior too much is:

• Use a small, focused library to convert HTML to plain text (stripping all tags) and then perform the entity replacements/normalizations and trimming as before.
• string-strip-html is a well-known npm package that safely removes HTML tags and is designed for exactly this purpose.
  Concretely, in src/lib/utils.ts:

1. Add an import for stripHtml from string-strip-html.
2. Rewrite stripHtmlTags so that:
   • It first calls stripHtml(html).result to obtain HTML-stripped text.
   • Then runs the existing .replace chain and .trim() on that plain text (preserving current normalization behavior).
3. Keep the function signature and name unchanged so existing callers keep working.

No other regions of the file need changes.

In general, to avoid double-unescaping when manually decoding HTML entities, the escape character & must be decoded last. This ensures that any & appearing as part of an entity sequence (like <, ", etc.) is handled before & turns < into <, which would otherwise then be decoded again.

For this specific function, the minimal change that preserves existing behavior is to move the .replace(/&/g, '&') call to the end of the replacement chain, after all other entity replacements. This keeps all current mappings ( , <, >, ", ', ’, ‘, “, ”, —, –) but guarantees that & is only introduced after all other entity patterns have been processed, preventing subsequent unintended decodes. No new imports or helper methods are needed; only the order of the chained .replace() calls within stripHtmlTags in src/lib/utils.ts (lines 173–186) must be adjusted.