Skip to content

fix(libSceSsl): follow the codes and defaults measured on a PS5 (13.40) - #7756

Open
frankea wants to merge 1 commit into
boykopovar:mainfrom
frankea:ssl-ps5-measured
Open

frankea wants to merge 1 commit into
boykopovar:mainfrom
frankea:ssl-ps5-measured

Conversation

@frankea

@frankea frankea commented Oct 19, 2026

Copy link
Copy Markdown
Contributor

What

Every "unverified" and "unknown" sentence #7626 left in docs/dev/debt/libSceSsl.md was measured on a PS5 on system software 13.40 with a ps5-payload-dev payload against a TLS 1.2 test server presenting certificates issued by the test fixture root (the measurement log is the first comment below; the payload, the test server and the raw console logs are attached as files by the author). The code follows the console where it differed:

  • Initial verify options are SERVER_VERIFY | CN_CHECK | KNOWN_CA_CHECK (0x25): the console accepts expired and not-yet-valid certificates until NOT_AFTER_CHECK/NOT_BEFORE_CHECK is enabled. Bits outside 0x3F return SSL_ERROR_INVALID_VALUE from sceSslEnableVerifyOption/sceSslDisableVerifyOption.
  • The verify callback gets the context id (not the connection id) and the bitmask of the enabled checks that failed (0x4, 0x20, ...) instead of an error code, with the chain as received including the root. After a negative return the console runs the callback again from every later sceSslConnect, sceSslRead and sceSslWrite, each returning SSL_ERROR_APPLICATION_VERIFICATION_CALLBACK_CHECK while it refuses.
  • sceSslRead with flags 0 reads until the requested length or the end of the stream; MsgFlagPartialRead returns what is available. A stream that ends without close_notify reads as 0 like a close_notify; a reset returns SCE_NET_ERROR_ECONNRESET (0x80410136) from read and close and SCE_NET_ERROR_EPIPE (0x80410120) from write; a blocking socket's receive timeout returns SSL_ERROR_WANT_POLLIN, so SSL_ERROR_READ_TIMEOUT is gone; a record that fails its MAC returns 0x80951D55.
  • A fatal alert during the handshake returns SSL_ERROR_FATAL_ALERT and ends the transport: later connects return 0, reads 0, writes SSL_ERROR_SOCKET_CLOSED.
  • sceSslClose before the handshake is a no-op, the connection stays usable for sceSslConnect (0) and sceSslRead (0) after a close, a close_notify that would block returns SSL_ERROR_WANT_POLLOUT. sceSslRead/sceSslWrite before sceSslConnect run the handshake. sceSslWrite with flags other than 0 returns SSL_ERROR_INVALID_VALUE.
  • Unknown or deleted connection ids and connections of a terminated context return SSL_ERROR_INVALID_ID from every connection call; sceSslTerm of an unknown context too; sceSslInit(0) returns SCE_KERNEL_ERROR_EINVAL; a null host returns SSL_ERROR_INVALID_VALUE; a descriptor that is not a socket fails sceSslConnect with SCE_NET_ERROR_EBADF.
  • sceSslSetMinSslVersion accepts 2..5 only (SSL_ERROR_INVALID_VALUE otherwise; the console has no TLS 1.3 value and offers TLS 1.2 only, which this build already matches). sceSslSetAlpn splits on commas, measured on the wire; an empty list returns SSL_ERROR_BAD_LENGTH.
  • sceSslGetNameEntryInfo writes long attribute names (commonName); sceSslGetSerialNumber leaves *sboLen alone when the buffer is large enough.
  • Debt entries rewritten around the measured values and the method; what stays unmeasured is listed and throws (a title process, SSL_ERROR_INVALID_CERT and what the callback gets for it, read/write after a plain verification failure, write after sceSslClose, client certificates, the callback using its own connection). Disabling 0x1, 0x4 or 0x20 stopped the payload process through the kernel's debug exception path; the emulator keeps clearing them because titles import the call, and the entry records it.

Tested

PS5, system software 13.40, ps5-payload-dev elfldr v0.26, payload built from the attached main.c (ps5-sslprobe) with the SDK built from source on macOS; server server.py with OpenSSL 4.0.3; the attached logs are the console's output.

Emulator: Ubuntu 24.04 x86-64 container (GCC 13, Release, BUILD_TESTING=ON) on 2dcc941 + this commit: guest_ssl, guest_ssl_load, guest_ssl_transport_kernel, guest_ssl_transport_net, guest_ssl_ps5_readers pass, 3 runs each, with the host CPU check of 83a268a bypassed locally for the run because the container runs under Rosetta without AVX2 (the bypass is not in the commit); python3 tools/check_conventions.py --base origin/main passes. Not tested: Windows and macOS, a title.

Checklist

Every unverified point of the libSceSsl debt entry was measured on a PS5 on
system software 13.40 with a ps5-payload-dev payload against a TLS 1.2 test
server presenting leaves issued by the test fixture root. The code follows the
console where it differed: initial verify options 0x25 with the date checks
off, bits outside 0x3F rejected, the verify callback called with the context
id and the bitmask of failed checks and re-run from every later call after a
negative return, sceSslRead flags 0 reading until the requested length,
streams that end without close_notify reading as 0, resets reported with the
libSceNet codes, receive timeouts as SSL_ERROR_WANT_POLLIN, a fatal alert
ending the transport, sceSslClose as a repeatable no-op before the handshake,
read and write before connect running the handshake, SSL_ERROR_INVALID_ID for
unknown or deleted handles and terminated contexts, sceSslSetMinSslVersion
accepting 2 to 5, an empty ALPN list rejected, long attribute names from
sceSslGetNameEntryInfo and sceSslGetSerialNumber leaving the caller's length.
The debt entries record the measured values and what stays unmeasured.
@github-actions github-actions Bot added the unblocks title Names a title ID on the Unblocks line label Oct 19, 2026
@frankea

frankea commented Oct 19, 2026

Copy link
Copy Markdown
Contributor Author

libSceSsl measured on a PS5, system software 13.40 (2026-10-19)

Every number in this file is console output. Nothing here is inferred from an emulator, SharpProspero or KytyPS5; the only inferences are marked as such.

Method

  • Console: PS5, system software 13.40 (kernel_get_fw_version() = 0x13400002, the SDK version libSceLibcInternal reports), no hardware modification, PLK Payload Manager 0.6.1, ps5-payload-dev elfldr v0.26 listening on port 9021. elfldr runs each payload as a child of its own process (parent SceRedisServer, AuthId 480000001000000e, uid 0, payload.elf in ps), so this is not a title process: a result that depends on the caller's process type is flagged below.
  • Payload: main.c of the attached ps5-sslprobe folder, built with the ps5-payload-dev SDK compiled from source on macOS with Homebrew llvm@18 (make DESTDIR=~/ps5-payload-dev/ps5-payload-sdk install, no sudo). The SDK's libSceSsl.so stub makes the loader resolve every sceSsl* import by NID in the console's libSceSsl.sprx (NIDs computed with the repository's algorithm, the attached nids.txt: sceSslInit hdpVEUDFW3s, sceSslConnect zXvd6iNyfgc, sceSslRead jltWpVKtetg, sceSslWrite iNjkt9Poblw, sceSslClose viRXSHZYd0c, sceSslSetVerifyCallback E4a-ahM57QQ, sceSslEnableVerifyOption po1X86mgHDU, sceSslDisableVerifyOption PwsHbErG+e8, sceSslSetMinSslVersion QWSxBzf6lAg, sceSslSetAlpn TL86glUrmUw, sceSslGetAlpnSelected 4O7+bRkRUe8, sceSslGetSslError 0XcZknp7-Wc). sceKernelLoadStartModule("libSceSsl.sprx") returned handle 34 and sceKernelDlsym(34, "sceSslInit") returned 0x80020003 (ENOENT): the console resolves these exports by NID only.
  • Output: the payload prints every call with its arguments and the return as hex over the elfldr socket (nc 192.168.1.125 9021 < sslprobe.elf); raw logs are the attached run1.log, run2.log, run3.log, run-opt.log, klog-dis1.log (kernel log) and server.log (the Mac side).
  • Server: the attached server.py on this Mac (192.168.1.176, Python 3.15, OpenSSL 4.0.3), one TLS scenario per port, every port TLS 1.2 only unless stated, server certificates issued by the repository's fixture root (core/libs/tests/SslCertificateFixture.hpp, attached gen_certs.py): good (CN and SAN mac.anyps5.test, SAN IP 192.168.1.176, valid 2026-10-18..2036-10-16), cnmismatch (CN/SAN other.anyps5.test), expired (valid 2025-09-14..2026-09-19), notyet (valid 2027-11-23..2028-12-27). The server sends leaf + root. Each accepted connection has its ClientHello decoded before the handshake.
  • Sockets: libSceNet (sceNetSocket("sslprobe", AF_INET, SOCK_STREAM, IPPROTO_TCP), sceNetConnect, sceNetSetsockopt), host string mac.anyps5.test, two sceSslInit(256 KiB) contexts: ctx 1 with no CA, ctx 2 with the fixture root loaded by sceSslLoadCert(2, 1, [PEM, 680 bytes], NULL, NULL) = 0.

What the console sends

ClientHello (144 bytes, every connection): record version 0x0301, client version 0x0303, cipher suites c030 c02c cca9 cca8 c02f c02b 003d 003c 0035 002f 000a 00ff, groups 001d 0017 0018 0019 (x25519, P-256, P-384, P-521), signature algorithms 0401 0501 0601 0403 0503 0603 0804 0805 0806 0201, extensions 0 11 10 13 only (SNI, ec_point_formats, supported_groups, signature_algorithms) plus 16 (ALPN) when sceSslSetAlpn was called. No supported_versions, no extended_master_secret, no session ticket: the library speaks TLS 1.2 at most (a TLS 1.3-only server makes sceSslConnect return 0x8095F010, see below). The library identifies itself in its own out-of-memory message as [libssl2] libressl_calloc(...), i.e. a LibreSSL build. The negotiated cipher with the ECDSA fixture chain was ECDHE-ECDSA-AES256-GCM-SHA384.

SNI is the host string as given (MAC.ANYPS5.TEST is sent upper-case and still verifies), an empty host sends an empty SNI name, an IP-literal host sends no SNI extension.

The first sceSslConnect of the process took 23.8 s before the ClientHello left the console (the server then completed the handshake in 15 ms); every later connection handshakes in 20-30 ms. Later payload runs in the same elfldr session did not repeat the delay.

Handles and pool

Call Result
sceSslInit(256 KiB) twice 1, 2 (context ids count from 1); a third sceSslInit(64 KiB) = 3, sceSslInit(16 KiB) = 4, sceSslInit(1) = 5
sceSslInit(0) 0x80020016 (SCE_KERNEL_ERROR_EINVAL)
sceSslCreateConnection 0x10000001, 0x10000002, ... (never reused within a context, 0x10000001 restarts with a new process)
sceSslGetMemoryPoolStats(2) after init pool 262144, maxInuse 5568, current 5568
after sceSslLoadCert of the 680-byte root maxInuse 12000, current 6816
after one successful connect (two-certificate chain) maxInuse 80544, current 47776
after ~45 connections maxInuse 83552 (ctx 2), 79680 (ctx 1)
sceSslGetMemoryPoolStats(4) after a failed connect on the 16 KiB pool pool 16384, maxInuse 15392, current 15328
sceSslConnect on the 16 KiB pool (root loaded, good cert) 0x809517D5 (SSL_ERROR_OUT_OF_MEMORY); the library printed [libssl2] libressl_calloc(8807d8020, 6144, 1) out of memory on stdout first
sceSslGetMemoryPoolStats(99999) 0x8095F006

Initial verify options and sceSsl{Enable,Disable}VerifyOption

Fresh connections, no option call unless stated (default), blocking socket.

Context Server Options sceSslConnect
no CA good default 0x8095F00C UNKNOWN_CA
root cnmismatch default 0x8095F00B CN_CHECK
root expired default 0 (accepted, data read)
root notyet default 0 (accepted)
root expired enable 0x8 0x8095F00D NOT_AFTER_CHECK
root expired enable 0x10 0
root notyet enable 0x10 0x8095F00E NOT_BEFORE_CHECK
root notyet enable 0x8 0
root expired enable 0x8 then disable 0x8 0
root expired disable 0x8 0
root expired disable 0x10 0
root notyet disable 0x10 0
root notyet disable 0x8 0
no CA good disable 0x2 0x8095F00C
root good enable 0x3F 0
root good enable 0x1000, disable 0x1000 (both return 0x8095F007), enable 0 (0) 0

So the initial options are SERVER_VERIFY 0x1, CN_CHECK 0x4 and KNOWN_CA_CHECK 0x20 on, NOT_AFTER_CHECK 0x8 and NOT_BEFORE_CHECK 0x10 off (the 0x1/0x4/0x20 part is inferred from the failures above plus the disable results below; it was not read back, there is no getter). Whether 0x2 (CLIENT_VERIFY in SharpProspero) starts on or off was not determined.

Return codes of the option calls themselves:

Call Return
sceSslEnableVerifyOption(c, 0x4 / 0x8 / 0x10 / 0x3F / 0) 0
sceSslEnableVerifyOption(c, 0x1000), sceSslDisableVerifyOption(c, 0x40 / 0x100 / 0x1000) 0x8095F007 INVALID_VALUE (bits outside 0x3F are rejected)
sceSslDisableVerifyOption(c, 0x2 / 0x8 / 0x10) 0
sceSslDisableVerifyOption(c, 0x1), (c, 0x4), (c, 0x20) no return: the process is stopped. Kernel log: mDBG: Sending signal(pid: N, tid: T, signo: 0xa0020101); ps then shows the payload in state STOP, kill(pid, SIGKILL) returns 0 and does not remove it. Reproduced 6/6 (runs 1, opt, dis-0x1, dis-0x4, dis-0x20 and the klog run), each as the first disable of that bit on a fresh connection before sceSslConnect; disabling 0x4 after enabling 0x4 on the same connection stops the process too.
sceSsl{Enable,Disable}VerifyOption(99999, ...) 0x8095F006 INVALID_ID

The stop is from an elfldr payload (SceRedisServer lineage). Titles import sceSslDisableVerifyOption; whether a title process is allowed to clear 0x1/0x4/0x20 was not measured (it needs the homebrew-as-app route). Signal number 0xa0020101 is the console's debug-exception path, not a POSIX signal: a sigaction handler installed for SIGSEGV/SIGBUS/SIGILL/SIGABRT/SIGTRAP/SIGFPE/SIGSYS never ran.

Verify callback

int cb(int id, unsigned int err, void** certs, int num, void* userArg) set with sceSslSetVerifyCallback(c, cb, &arg) = 0.

Case Callback arguments sceSslConnect Notes
root, good id = 2 (the context id, not the connection id 0x1000001c), err = 0, num = 2, userArg as given 0 called once; a second sceSslConnect returns 0 without calling it again
root, cnmismatch, cb returns 0 id 2, err = 0x4 0 (accepted, data read) the callback's return overrides the failure
root, cnmismatch, cb returns 1 err 0x4 0
no CA, good, cb returns 0 id 1, err = 0x20 0
root, expired, 0x8 disabled, cb returns 0 err 0 0
root, good, cb returns -1 err 0 0x8095F0FD APPLICATION_VERIFICATION_CALLBACK_CHECK the callback was then called again by every following call: second sceSslConnect (-> 0x8095F0FD), sceSslRead (0x8095F0FD, 5 ms), sceSslConnect again, sceSslRead, sceSslWrite (0x8095F0FD each, 5 callbacks in total); sceSslClose 0, twice 0
callback set then cleared with sceSslSetVerifyCallback(c, NULL, NULL) = 0, cnmismatch not called 0x8095F00B

err is the bitmask of the verify options that failed (0x4 = CN_CHECK, 0x20 = KNOWN_CA_CHECK, 0 when the chain passed), not an SSL_ERROR_* code. The same pair comes back from sceSslGetSslError.

certs[0] is the leaf, certs[1] the root the server sent (num 2 = the chain as received). The elements are certificate handles for the context's readers: sceSslGetSerialNumber(ctx, certs[0], buf[32], &len=32) = 0 writes the serial left-aligned (10 01 for serial 0x1001, 80 a1 for the root) and leaves len at 32; sceSslGetSubjectName/sceSslGetIssuerName(ctx, cert) return name handles; sceSslGetNameEntryCount = 3; sceSslGetNameEntryInfo(ctx, name, i, oid[64], 64, value[128], 128, &valueLen) = 0 with oid = countryName, organizationName, commonName (long names) and valueLen = exact length (2, 12, 15/17/19); sceSslFreeSslCertName = 0. The first 24 bytes at a handle are three pointers (a struct with a vtable-like layout, not DER). The handles stay valid after sceSslConnect returns (re-read successfully) and are freed by sceSslDeleteConnection: the memory read back as zeros and sceSslGetSerialNumber on the stale handle crashed the payload (SIGSEGV at the handle's first pointer), so they must not be used after the delete.

Error codes by situation

Root loaded, good certificate unless stated. "read" is sceSslRead(c, buf, 64, flags).

Situation Call Return
server sends 10 bytes, 0.6 s later 10 more, waits 3 s, close_notify read flags 0 20 after 3605 ms (`piece-one
same read flags 1 10 after 108 ms, then 10 after 498 ms: flags 1 returns what is available (MsgFlagPartialRead)
same, exact lengths read 5 flags 0 -> 5 (piece) after 126 ms; read 5 flags 1 -> 5 (`-one ); read 64 flags 2 -> 10 after 475 ms (piece-two
peer close_notify received read (0 or 1) 0, every later read 0 (never 0x8095177C SSL_ERROR_EOF)
peer close_notify received write 15 bytes 15 (the server logged APPLICATION_DATA_AFTER_CLOSE_NOTIFY)
server closed TCP without close_notify (FIN) read flags 1 14 (`before-abrupt
same write 13, 15, 14 (accepted by the kernel)
same sceSslConnect again 0; sceSslClose 0, again 0
server reset (SO_LINGER 0) read flags 1 13 (`before-reset
same write 0x80410120 (SCE_NET_ERROR_EPIPE) each time
same sceSslConnect again 0; sceSslClose -> 0x80410136, second close 0x80410136
blocking socket, SO_RCVTIMEO = 2 s (16-byte timeval; a 4-byte int returns 0x80410116 EINVAL), silent server read flags 1 / 0 0x8095F013 WANT_POLLIN after 2001 ms each (never 0x80951710 READ_TIMEOUT); write afterwards 14, sceSslConnect 0, sceSslClose 0, read after close 0
non-blocking socket (SO_NBIO 0x1200 = 1), nothing pending read flags 0 / 1 0x8095F013 immediately; write 9 -> 9
non-blocking handshake sceSslConnect 0x8095F013, poll(POLLIN) readable after 11 ms, 0x8095F013, poll readable after 9 ms, 0 (three calls); read before data 0x8095F013, after poll 10
non-blocking, server never reads write 64 KiB 32768 (short write), then 0x8095F014 WANT_POLLOUT on each further write; poll(POLLOUT) says writable (kernel buffer) while the library still returns 0x8095F014; sceSslClose -> 0x8095F014
non-blocking, cnmismatch sceSslConnect 0x8095F013, then 0x8095F00B; again 0x8095F00B; sceSslClose 0
server sends a plaintext fatal alert 40 (handshake_failure) after the ClientHello and closes sceSslConnect 0x8095F010 FATAL_ALERT; sceSslConnect again -> 0 after 500 ms; read 0; write -> 0x8095170D SOCKET_CLOSED; sceSslClose 0, 0
same with alert 70 (protocol_version) identical: 0x8095F010, 0, read 0, write 0x8095170D, close 0, 0
TLS 1.3-only server (sends protocol_version alert) sceSslConnect 0x8095F010, read 0
server sends an undecryptable application record after the handshake read flags 1 17 (`before-badrecord
same sceSslConnect again 0; read 0; write 14; close 0, 0
verification failed (cnmismatch, default options) sceSslConnect again 0x8095F00B again (also non-blocking)
sceSslConnect after success 0 (no second handshake, callback not re-run)
sceSslClose before any connect 0, and sceSslConnect afterwards -> 0 with data readable (close before connect is a no-op)
sceSslClose after success, twice 0, 0; then sceSslConnect 0, read 0
sceSslRead before any sceSslConnect read flags 0 the handshake runs inside the read (server logged a normal handshake): 20 bytes after 3640 ms; sceSslWrite before connect 15; sceSslConnect afterwards 0
sceSslWrite(c, buf, 1, flags=1) 0x8095F007 INVALID_VALUE (write accepts flags 0 only)

sceSslGetSslError(c, &a, &b) (signature guessed as int, int*, int*) after a CN failure returned 0 with a = 0x8095F00A (INVALID_CERT) and b = 0x4 (the failed option bit).

ALPN

Server offers h2 and http/1.1 unless stated.

sceSslSetAlpn(c, s) Return ClientHello ALPN names as the server decoded them sceSslGetAlpnSelected
not called no ALPN extension NULL before and after
"h2,http/1.1" 0 h2, http/1.1 (two names: the string is split on commas) NULL before connect, "h2" after, still "h2" after sceSslClose
"\x02h2\x08http/1.1" (wire format) 0 one name \x02h2\x08http/1.1 NULL (no match)
"http/1.1" 0 http/1.1 "http/1.1"
"h2,http/1.1" against a server offering http/1.1 only 0 "http/1.1"
"h2,http/1.1" against a server without ALPN 0 NULL
"h2, http/1.1" then "spdy/3,h2" 0, 0 spdy/3, h2 (the second call replaces the list) "h2"
"" 0x80951773 BAD_LENGTH no ALPN extension NULL
sceSslSetAlpn(99999, "h2") 0x8095F006

sceSslSetMinSslVersion

version Return sceSslConnect to the TLS 1.2 server to the TLS 1.3-only server
-1, 0, 1 0x8095F007 INVALID_VALUE 0 (the rejected call changed nothing)
2 (SSL 3.0), 3 (TLS 1.0), 4 (TLS 1.1), 5 (TLS 1.2) 0 0 (version 3 took 361 ms instead of ~20 ms once; same ClientHello)
6, 7, 8, 9 0x8095F007 0 0x8095F010
default 0 0x8095F010

There is no TLS 1.3 value: 6 and above are rejected and the library never offers 1.3.

Handles, ordering, invalid arguments

Call Return
sceSslClose, sceSslConnect, sceSslRead, sceSslDeleteConnection, sceSslSetAlpn, sceSslEnableVerifyOption, sceSslSetMinSslVersion, sceSslSetVerifyCallback on connection 99999 0x8095F006 INVALID_ID
sceSslCreateConnection(99999, sock, host) 0x8095F006
sceSslCreateConnection(ctx, -1, host), (ctx, 0, host), (ctx, 1234567, host) 0x1000001e / 0x10000020 / 0x1000001f (the socket is not checked)
sceSslConnect on the 1234567 one 0x80410109 (SCE_NET_ERROR_EBADF)
sceSslCreateConnection(ctx, sock, "") a handle; sceSslConnect -> 0x8095F00B (empty SNI sent, server alerted bad certificate)
sceSslCreateConnection(ctx, sock, NULL) 0x8095F007 INVALID_VALUE
sceSslCreateConnection(ctx, sock, "192.168.1.176") handle; connect 0 (no SNI sent, matched the IP SAN)
sceSslCreateConnection(ctx, sock, "MAC.ANYPS5.TEST") handle; connect 0 (case-insensitive)
sceSslDeleteConnection without close after a successful connect 0 (the server saw EOF without close_notify)
second sceSslDeleteConnection, then sceSslClose, sceSslConnect on it 0x8095F006 each
sceSslTerm(ctx3) with a live connection 0; then sceSslClose, sceSslConnect, sceSslDeleteConnection on that connection 0x8095F006
sceSslTerm(ctx3) again, sceSslTerm(99999) 0x8095F006
sceSslSetVerifyCallback(c, NULL, NULL) 0

Not measured

  • Whether a title process survives sceSslDisableVerifyOption of 0x1/0x4/0x20 (needs a game-type process).
  • SSL_ERROR_READ_TIMEOUT, SSL_ERROR_EOF, SSL_ERROR_INTERNAL were never produced; a situation that returns 0x8095F00A INVALID_CERT from sceSslConnect was not found (a chain problem other than CA, CN and dates was not set up).
  • The default of option 0x2, client certificates, sceSslSetSslVersion, sceSslGetPeerCert, sceSslCheckRecvPending, sceSslRecv/sceSslSend, sceSslReuseConnection, sceSslLoadRootCACert (all exported, not called).
  • The verify callback's behaviour when it calls into the same connection, and threads.

AI-assisted: yes (Claude Code).

@github-actions

Copy link
Copy Markdown

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request Shared files not compared
PR 6039 docs/dev/debt/libSceSsl.md
PR 6044 core/libs/tests/GuestSsl.cpp
core/libs/tests/GuestSslLoad.cpp
core/libs/tests/SslCertificateFixture.hpp

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs prx unblocks title Names a title ID on the Unblocks line

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants