fix: merge main into blog feature branch

[whitep4nth3r]

No description provided.

In general, to fix clear-text logging of sensitive information, you should either remove the sensitive fields from logs entirely, or anonymize/obfuscate them (for example, hashing or truncating) so that they cannot easily be mapped back to a specific user, while still providing enough information for debugging. You should also avoid logging tokens, passwords, or full session objects.

For this specific case, the simplest fix that preserves functionality is to stop logging the full loggedInUsersDid and instead log either a redacted form (e.g., truncated DID) or no user information at all. Since the main purpose of the warning seems to be to record that an unlike was attempted for a package that is not liked, the package name alone is likely sufficient. If some correlation is still needed for operations, we can log a non-reversible hash of the DID. This requires a hashing function but does not change any control flow or business logic.

Concretely, in server/api/social/like.delete.ts, we will replace the console.warn call to avoid embedding loggedInUsersDid directly. A minimal change is to log only the package:

console.warn(`A user tried to unlike package ${body.packageName} but it was not liked by them.`);

This removes the sensitive identifier from the log while preserving the information about unexpected behavior. No new imports or external libraries are required for this change.

In general, the fix is to stop using substring checks on the full URL string to infer the host or origin, and instead parse the URL and validate its hostname and path structure explicitly. For GitLab builder IDs, we should confirm that the URL is actually on gitlab.com (or a well-defined set of allowed GitLab hosts) and that its path contains the expected /-/runners/ segment, rather than just checking for those substrings anywhere.

Concretely, in server/utils/provenance.ts, within getProviderInfo(builderId: string), replace the condition:

if (builderId.includes('gitlab.com') && builderId.includes('/runners/'))
  return { provider: 'gitlab', providerLabel: 'GitLab CI' }

with logic that:

1. Attempts to construct a URL object from builderId.
2. Checks that url.hostname is exactly gitlab.com (or potentially extendable to a small allowlist if needed in the future).
3. Checks that url.pathname contains the expected /-/runners/ segment (for example url.pathname.includes('/-/runners/')), since GitLab’s documented format is https://gitlab.com/<path>/-/runners/<id>.

If URL parsing fails (throws), we fall through to the 'unknown' provider case, preserving existing behavior for malformed IDs. We can use the built-in URL class available in modern Node/JS runtimes, so no extra imports are needed. This keeps existing functionality (legitimate GitLab builder IDs are still recognized) while closing the substring-sanitization issue.

In general, to fix incomplete URL substring sanitization, you should parse the URL and inspect its hostname instead of using string.includes on the full URL. This ensures that checks like “is this GitHub?” only succeed when the actual host is github.com (or a specific set of allowed hosts), not when github.com appears in the path, query string, or as part of another domain name.

For this code, the best fix is to change repoUrlToCommitUrl and repoUrlToBlobUrl so that they normalize the repository string as before, then try to parse it as a URL using Node’s built‑in URL class. If parsing succeeds, use url.hostname to decide whether it is github.com or gitlab.com. If parsing fails (e.g., repository is in some non‑URL format), fall back to the existing generic behavior that appends /commit/ or /blob/. This preserves behavior for well‑formed URLs while eliminating the substring host check. Concretely:

• Leave the initial normalization (replace(/\/$/, '').replace(/\.git$/, '')) in place.
• Introduce a small helper that safely parses a URL and returns its hostname, or inline that logic in each function using try { const u = new URL(normalized); ... } catch { ... }.
• Replace normalized.includes('github.com') with hostname === 'github.com'.
• Replace normalized.includes('gitlab.com') with hostname === 'gitlab.com'.
• Keep the default return ${normalized}/commit/${sha} and `return `${normalized}/blob/${ref}/${path} if the host is neither GitHub nor GitLab, or URL parsing fails.

No new external libraries are needed because URL is part of the standard library in modern Node.js and browsers.

In general terms, the fix is to stop using String.prototype.includes to infer whether a repository URL is hosted on GitHub or GitLab. Instead, parse the repository string as a URL (or, if that fails, fall back to a simple heuristic for non-URL forms like git@github.com:org/repo.git) and base the decision on the host/hostname (and maybe protocol) field. This ensures that github.com or gitlab.com must appear as the actual host (or an expected subdomain) rather than somewhere else in the string.

Concretely, within server/utils/provenance.ts, the changes are localized to repoUrlToCommitUrl and repoUrlToBlobUrl:

1. Introduce a small helper function, e.g. getRepoHost(repository: string): string | null, that:
   • Trims trailing / and .git as currently done.
   • Tries new URL(normalized) to parse web URLs.
   • If parsing fails, handles common git-style URLs like git@github.com:org/repo.git by detecting @ and : and mapping them to a host (e.g. for git@github.com:foo/bar.git, host is github.com).
   • Returns the host in a normalized form (e.g. lowercase), or null if it cannot be determined.
2. Update repoUrlToCommitUrl:
   • Compute normalized as before.
   • Compute const host = getRepoHost(normalized).
   • If host === 'github.com', return the GitHub commit URL pattern.
   • Else if host === 'gitlab.com', return the GitLab commit URL pattern.
   • Else fall back to the generic ${normalized}/commit/${sha}.
3. Update repoUrlToBlobUrl analogously, using the same getRepoHost helper and selecting the appropriate pattern based on the host.

No new external imports are strictly needed; TypeScript’s URL class is globally available in Node.js. This approach keeps existing behavior for valid GitHub/GitLab URLs, including .git suffix or trailing slash, while preventing misclassification based on mere substring matches.

In general, the fix is to stop using substring matches on the whole URL string to infer the hosting provider, and instead parse the URL and inspect its host (or hostname) explicitly. This ensures that github.com or gitlab.com only match when they are the actual host (and, if desired, its subdomains), and not when they appear in the path, query, or as part of an unrelated domain name.

Concretely, in server/utils/provenance.ts, we should change repoUrlToCommitUrl and repoUrlToBlobUrl so that:

1. They parse repository using the standard URL class.
2. They derive normalized from the parsed URL (origin + pathname with trailing slash and .git stripped) instead of blindly manipulating the raw string.
3. They check url.hostname for equality with github.com or gitlab.com (or allow appropriate subdomains, if needed).
4. On parse failure (invalid URL) they fall back to the existing behavior, to avoid breaking current functionality.

This requires importing Node’s built‑in url parser (URL is globally available in modern Node, so we can just use it directly without a new import). The behavior for valid GitHub/GitLab URLs remains identical: GitHub uses /commit/ and /blob/, GitLab uses /-/commit/ and /-/blob/, and any other host falls back to the generic /commit/ and /blob/ pattern. For malformed or non-absolute repository strings, we preserve the old substring-based fallback path by detecting and short‑circuiting when new URL throws.

In general, instead of using string.includes('gitlab.com') on an entire URL, parse the URL and compare the actual host (and optionally scheme) against a whitelist or well-defined patterns (e.g., exact match or checking hostname === 'gitlab.com' or ends-with .gitlab.com). This avoids cases where the substring appears in the path, query, or as part of another domain.

For this specific file, we should update repoUrlToCommitUrl and repoUrlToBlobUrl so that they determine whether a URL is GitHub or GitLab based on the parsed hostname, not a substring search. The behavior we want to preserve is: if the repository is hosted on GitHub, use /commit/ or /blob/; if on GitLab, use /-/commit/ or /-/blob/; otherwise, fall back to the GitHub-style paths. We can safely use the built‑in URL class available in Node.js/modern JS to parse the URL; if parsing fails (e.g., repository is just user/repo), we can fall back to the original substring behavior to avoid breaking existing functionality.

Concretely:

• Add a small helper, e.g. getHostFromUrl, that tries new URL(...) and returns the hostname or null if parsing fails.
• In both repoUrlToCommitUrl and repoUrlToBlobUrl, after normalizing, call this helper. If we get a hostname:
  • If it is exactly github.com or ends with .github.com, treat as GitHub.
  • If it is exactly gitlab.com or ends with .gitlab.com, treat as GitLab.
• If we cannot parse a hostname, retain the existing includes logic as a non‑URL fallback (handles SCP-like git@github.com:user/repo.git or bare github.com/user/repo strings).
  This keeps existing behavior for non-URL repo identifiers while making URL-based checks safe.

In general, the problem is that we're using a hand-written regex /\<[^>]*\>/g to remove HTML tags from a string derived from user-controlled Markdown. This is both brittle and an example of incomplete multi-character sanitization. The best fix is to avoid this regex altogether and either (a) use the already-imported sanitize-html library to strip all tags safely, or (b) leverage the marked token tree to build a plain-text heading directly. Since sanitize-html is already imported in this file, the simplest fix with minimal functional change is to feed text into sanitizeHtml with a configuration that removes all tags and returns only text.

Concretely, in server/utils/readme.ts, in the renderer.heading implementation around line 332, we should replace:

const plainText = text.replace(/<[^>]*>/g, '').trim()

with a call to sanitizeHtml configured to disallow all tags and attributes:

const plainText = sanitizeHtml(text, {
  allowedTags: [],
  allowedAttributes: {},
}).trim()

This uses a well-tested library instead of a fragile regex, eliminates multi-character sanitization issues, and should preserve existing behavior of “HTML stripped, text kept” for TOC entries. No new imports are needed, because sanitizeHtml is already imported at line 2. All other logic (slug creation, TOC pushing, heading rendering) can remain unchanged.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ignored		Feb 6, 2026 0:49am

[github-actions]

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File	Note
lunaria/files/ar-EG.json	Localization changed, will be marked as complete.
lunaria/files/az-AZ.json	Localization added, will be marked as complete.
lunaria/files/cs-CZ.json	Localization added, will be marked as complete.
lunaria/files/de-DE.json	Localization changed, will be marked as complete.
lunaria/files/en-GB.json	Localization added, will be marked as complete.
lunaria/files/en-US.json	Source changed, localizations will be marked as outdated.
lunaria/files/es-419.json	Localization changed, will be marked as complete.
lunaria/files/es-ES.json	Localization changed, will be marked as complete.
lunaria/files/fr-FR.json	Localization changed, will be marked as complete.
lunaria/files/hi-IN.json	Localization added, will be marked as complete.
lunaria/files/hu-HU.json	Localization changed, will be marked as complete.
lunaria/files/id-ID.json	Localization changed, will be marked as complete.
lunaria/files/it-IT.json	Localization changed, will be marked as complete.
lunaria/files/ja-JP.json	Localization changed, will be marked as complete.
lunaria/files/mr-IN.json	Localization added, will be marked as complete.
lunaria/files/ne-NP.json	Localization changed, will be marked as complete.
lunaria/files/pl-PL.json	Localization changed, will be marked as complete.
lunaria/files/pt-BR.json	Localization changed, will be marked as complete.
lunaria/files/ru-RU.json	Localization changed, will be marked as complete.
lunaria/files/uk-UA.json	Localization changed, will be marked as complete.
lunaria/files/zh-CN.json	Localization changed, will be marked as complete.
lunaria/files/zh-TW.json	Localization added, will be marked as complete.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.