code-server/4.107.0 package update

[octo-sts]

Commit: ac7322ce566a5dc99c60d92180375329f0bbd759

Note: If you need to make manual changes to this PR, apply the skip:staging-update-bot label so the reconciler won't overwrite them.

[octo-sts]

🩹 Build Failed: Patch Application Failed

patch unexpectedly ends in middle of line
Hunk #1 FAILED at 32.
1 out of 1 hunk FAILED -- saving rejects to file lib/vscode/package.json.rej

Build Details

Category	Details
Build System	Wolfi Linux package build system
Failure Point	patch command failed while applying patch to lib/vscode/package.json

Root Cause Analysis 🔍

The patch file appears to be corrupted or incomplete, ending unexpectedly in the middle of a line. This caused the patch application to fail when trying to modify lib/vscode/package.json at line 32. The patch system created a reject file indicating the hunk could not be applied.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Suggested Changes

File: code-server YAML file

• check_patch_file (patch files directory)
  Original:

Current patch file ending unexpectedly

Replacement:

Properly formatted patch file with complete content and proper line endings

Content:

First, examine the patch file that targets lib/vscode/package.json to identify if it's truncated or has missing newlines

• fix_patch_content (specific patch file targeting lib/vscode/package.json)
  Original:

Patch file missing final newline or truncated content

Replacement:

Complete patch file with proper Unix line endings (\n) and trailing newline

Content:

Ensure the patch file has a trailing newline and all hunks are complete

• alternative_remove_patch (pipeline section with patch application)
  Original:

patches: |
  node-memory.patch
  GHSA-pq67-2wwv-3xjx.patch
  fix-CVE-2025-47279.patch
  GHSA-76c9-3jph-rj3q.patch
  GHSA-mh29-5h37-fv8m.patch

Replacement:

patches: |
  node-memory.patch
  GHSA-pq67-2wwv-3xjx.patch
  GHSA-76c9-3jph-rj3q.patch
  GHSA-mh29-5h37-fv8m.patch

Content:

If the patch is no longer needed due to version update, remove it from the patches list

Click to expand fix analysis

Analysis

The similar fixes show a consistent pattern: all three cases involved patch files that were malformed, truncated, or incompatible with their target files, causing "patch unexpectedly ends in middle of line" errors. The fixes involved either: 1) Fixing the patch file itself by ensuring proper line endings and complete content (as in the vllm-remove-cmake.patch fix), or 2) Removing problematic patches entirely when they were no longer needed due to version updates (as in the opensearch cases where patches became obsolete). All fixes also involved version updates which often made existing patches incompatible.

Click to expand fix explanation

Explanation

The current build failure is identical to the pattern seen in all three similar fixes: a patch file is malformed or truncated, causing it to "unexpectedly end in middle of line". Based on the fixes, there are two main approaches: 1) Fix the corrupted patch file by ensuring it has proper Unix line endings and a trailing newline, which is often the cause of this specific error, or 2) Remove the problematic patch if it's no longer needed due to the version update from the previous code-server version. The fix-CVE-2025-47279.patch targeting lib/vscode/package.json is likely the culprit since it matches the error location. The pattern from similar fixes shows that version updates often make existing patches incompatible or unnecessary, requiring either patch updates or removal.

Click to expand alternative approaches

Alternative Approaches

• Regenerate the patch file from scratch against the current version of the target file to ensure compatibility
• Check if the CVE mentioned in fix-CVE-2025-47279.patch has been fixed upstream in the new version, making the patch obsolete
• Use git apply instead of patch command if the patch was created with git format-patch
• Convert the patch to use different context lines if the target file structure has changed significantly

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[OddBloke]

OK, this one is going to be complicated to resolve. code-server has updated to use vscode 1.107.0 (coder/code-server@ea9a3a5) which includes a series of commits to the microsoft-authenticator extension which I don't fully understand, but which seem to remove the option of a Node-native authentication method in favour of msal-node: this pulls in msal-node-runtime (npm) which ships libmsalruntime.so: this is pre-compiled (that's a problem) and causes SCA to generate dependencies on several libraries we don't have packaged (including so:libwebkit2gtk-4.1.so.0, suggesting it includes a whole browser stack). Further complicating matters, I don't believe we could build this ourselves: https://www.npmjs.com/package/@azure/msal-node-runtime points at https://github.com/AzureAD/microsoft-authentication-library-for-cpp as its upstream, which no longer exists.

This problem does only surface on x86_64: it doesn't look like msal-node-runtime ships a .so for any architecture but x86_64, so it's possible that (a) aarch64 is simply broken due to this absence, or (b) aarch64 isn't broken and we could maybe hack at x86_64 to get it to behave the same as aarch64. microsoft/vscode#278689 looks like the relevant change we would need to potentially revert or modify.