[MarcZX10]

What

Follow up to merged PR #5280. On Linux and macOS, the sandbox certificate provider reads the selected host SSL_CERT_FILE bundle and currently copies it wholesale to the guest-visible CA_LIST.cer. Such files can contain PEM metadata and other PEM objects, including private-key blocks.

Filter the host input to complete BEGIN CERTIFICATE / END CERTIFICATE blocks before writing the guest bundle. Preserve each certificate block's bytes and line endings; omit text outside those blocks. The regression fixture includes two certificate blocks with mixed LF/CRLF endings, surrounding metadata, and private-key blocks, and checks that only the certificates are exposed.

This does not change certificate selection or establish that the console's CA_LIST.cer format matches this host-derived PEM representation.

Tested

• Linux, GCC 12.2 Release: guest_sandbox_certificates_tests builds successfully.
• check_test_registration.py /tmp/AnyPS5-CA-filter-build: passes (928 test executables, none unregistered).
• check_conventions.py --base upstream/main and git diff --check: pass.
• The focused CTest aborts before its assertions because this runner's Xeon E5-1620 v2 lacks the project-required LZCNT, BMI1/2, MOVBE, AVX2 and FMA features. A standalone harness compiled from the changed provider source passes the certificate-only extraction case.
• Windows/macOS runs: not performed. GPUs: n/a.

Checklist

• Based on current main (07e741481); searched open and closed PRs for duplicate CA bundle filtering work
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw; no new stubs
• No notes, investigation .md files or images added to the repository
• No new third-party code
• Generic behavior, not title-specific
• Depends on: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[simonbbby]

Independent Linux provider-level check of exact head 800f045a730b99760cc655beb376da5f70670190, Ubuntu 24.04 x86-64 / GCC 13.3. This is not a guest_sandbox_certificates CTest result.

I compiled the complete unchanged SandboxCertificates.cpp with a small harness. Its only shims return a synthetic sandbox name and capture the AddPathProvider callback; extraction, input selection, cache writes, permissions and rename are the production implementation with actual filesystem I/O. SSL_CERT_FILE always names a generated fixture, never a host credential file. The key-looking text is explicitly synthetic.

10/10 fresh-process cases pass: mixed metadata/key/certificate blocks with LF and CRLF, LF-only, CRLF-only, an end marker without a final newline, empty input, key-only input, an unfinished certificate, an orphan end marker, a begin marker embedded in a larger line, and a new begin marker after an unfinished block. Expected certificate bytes and line endings match exactly. Empty extractions return no path and create no cache directory; nonempty outputs are mode 0444 and leave no temporary files. Every input stays unchanged.

The same harness with the parent's complete provider fails the mixed-bundle, unfinished-block, embedded-marker and restarted-block cases, while passing the unchanged controls. A negative control deleting only the CR trimming line also fails the CRLF case.

Two additional cache cases pass:

• A pre-existing, already filtered cache retains its inode and timestamp.
• A pre-existing, read-only unfiltered cache is replaced with the expected certificate-only bytes, remains mode 0444, and leaves no temporary file.

Remaining gap: the full libc/libkernel guest-path, stream, alias and stat integration test was not run; its separate runtime dependencies remain unavailable here. These synthetic marker tests do not validate X.509 contents, console ABI/format, Windows trusted roots or TLS handshakes.

[MarcZX10]

Thanks for the thorough independent check. The 10 fresh-process cases, cache-preservation/replacement cases, and negative controls add useful provider-level evidence for the extraction and cache behavior. I’ll keep the full guest-path integration test and Windows/TLS behavior marked as unverified; your report does not claim those were covered.

[MarcZX10]

Thanks for the provider-level check and the careful scope note. The 10 fresh-process cases and the two cache cases add useful Linux filesystem coverage; I have noted that the full guest-path/libc integration test and TLS handshake behavior remain untested.

[jotitadev]

First CTest run of guest_sandbox_certificates on a CPU that passes the host guard (the description notes the focused test stopped at the guard on the author's Xeon, and the provider-level check above did not run it).

Machine: Linux x86_64, i7-8700, Ubuntu 26.04, GCC 15.2, Release, BUILD_TESTING=ON, full build.
Head 800f045a7 merged onto main 40315fcf8 (clean merge; the branch is based on 07e741481).

• guest_sandbox_certificates passes with the PR, together with the other sandbox, SSL and HTTP tests (ctest -R "sandbox|certificate|ssl|http", 7 tests).
• Test file only, on main: the test aborts with Sandbox certificates check failed at line 93, so it catches the unfiltered bundle.
• Non-GPU suite (ctest -E "^agc|gpu|vulkan|video_out"): 682/682, same as main on this machine.

Written with AI assistance (Claude Code). I ran the builds and tests above on my machine.

[adriadam10]

Checked the filter against the Linux/macOS bundle path and the Windows CRYPT_STRING_BASE64HEADER output (CRLF lines still match), and that the new fixture (metadata plus two private-key blocks around two certificates, mixed LF/CRLF) would fail with the old wholesale copy. Also covered by the independent runs from @simonbbby (provider level) and @jotitadev (guest_sandbox_certificates CTest); merged.