seregonwar
a9d4e1e666
tools/fetch_pacbrew_ps4.sh unpacks the pinned PacBrew portlibs (libcurl, mbedTLS, zlib) with a Mozilla CA bundle; the Makefile detects that prefix and enables ENABLE_LIBCURL for PS4, bridging the three libc symbols the OpenOrbis build expects. Console payloads now always link as PIE (GoldHEN's payloader rejects ET_EXEC), which is what made the plain `make deploy` flow work, and the release workflow installs the same portlibs for PS4 zhttp artifacts.
4.7 KiB
External dependencies
zftpd keeps protocol implementations outside the project when a mature, maintained library already exists. Console builds use the ports shipped by the PacBrew ecosystem rather than local compatibility shims.
PS4 zhttp transfer stack
| Component | Purpose | Source |
|---|---|---|
| libcurl 7.80.0 | HTTP, HTTPS, FTP and FTPS transfers | PacBrew ps4-openorbis-libcurl (static, links -lSceNet) |
| mbedTLS 2.16.6 | TLS used by libcurl | PacBrew ps4-openorbis-mbedtls |
| zlib 1.3.1 | libcurl transfer dependency | PacBrew ps4-openorbis-zlib |
| Mozilla CA bundle | HTTPS trust store | downloaded by the fetch script and embedded at build time |
tools/fetch_pacbrew_ps4.sh installs the pinned PacBrew packages into
external/pacbrew/ps4/openorbis (versions and SHA-256 are pinned in the
script, and the packages come from the public PacBrew repository). No pacman
and no OpenOrbis toolchain are needed: the payload keeps being built with
PS4_PAYLOAD_SDK, and only the headers and the static libraries are used —
the curl-config wrapper inside the package emits the OpenOrbis toolchain's
own link flags (its linker script, -nostdlib, -lSceLibcInternal), which
must not leak into a payload link. The Makefile picks the prefix up
automatically (PS4_PACBREW_ROOT, defaulting to the path above and to
/opt/pacbrew/ps4/openorbis), and the release workflow installs the same set
for the published PS4 artifacts.
The OpenOrbis build of libcurl reaches errno through musl's
__errno_location() and uses fnmatch()/execl(), none of which the payload
libc exports; src/platform/ps4/ps4_pacbrew_compat.c bridges the three.
With no prefix installed the URL downloader is simply disabled at build time.
A toolchain-provided orbis-pkg-config / orbis-curl-config is still probed
as a fallback, and PS4_PKG_CONFIG, PS4_CURL_CONFIG and PS4_CA_BUNDLE
override the detection. The build never falls back to the host's libcurl,
which would link code built for the wrong OS.
PS5 zhttp transfer stack
| Component | Purpose | Source |
|---|---|---|
| libcurl 8.18.0 | HTTP, HTTPS, FTP and FTPS transfers | ps5-payload-dev/pacbrew-repo (ps5-payload-curl) |
| OpenSSL | TLS used by libcurl | PacBrew dependency of ps5-payload-curl |
| zlib / zstd / libpsl | libcurl transfer dependencies | PacBrew |
| libnfs 5.0.3 | Userspace NFS client | ps5-payload-dev/pacbrew-repo (ps5-payload-libnfs) |
| libtorrent-rasterbar 2.1.2 | Native BitTorrent magnet downloads | Cross-built from the pinned upstream source by tools/build_ps5_libtorrent.sh |
| libarchive (optional) | Non-ZIP archive extraction with ENABLE_LIBARCHIVE=1 |
ps5-payload-dev/pacbrew-repo (ps5-payload-libarchive) |
| Mozilla CA bundle | HTTPS trust store | generated by the PacBrew curl package and embedded at build time |
The release workflow pins PacBrew v0.40.2 and verifies the published
ps5-payload-dev.tar.gz SHA-256 before using it. The SDK bundle is not
committed to this repository.
Transfer architecture
src/transfer/ owns network-to-file transfers. The HTTP API only validates
requests and destination paths, then delegates to the transfer manager.
Backends are selected by URL scheme:
http://,https://,ftp://,ftps://-> libcurlnfs://-> libnfsmagnet:?-> libtorrent-rasterbar in PS5 builds withENABLE_LIBTORRENT=1
HTTP/FTP/NFS downloads are written to <name>.zftpd.part, support resume
where the remote protocol permits it, and are renamed after the transfer and
fsync() succeed. Magnet downloads use a partial directory with the same
suffix and store resume data in /data/zftpd (or /tmp/zftpd fallback).
The directory becomes visible under its final name only after libtorrent
verifies all pieces.
For new HTTP/HTTPS downloads of at least 128 MiB, libcurl first checks byte-range support and a strong ETag, then measures one 32 MiB range. If that connection is below 16 MB/s, four range requests run concurrently in 8 MiB chunks. Each wave is verified and appended in order, so the partial file stays contiguous and can still resume after interruption. An existing partial file can also use four connections: before fetching its suffix, zftpd compares small regions at the start, middle and end of the local prefix with the current remote file. A mismatch stops the download without changing the partial file. This sampling does not prove every byte of a legacy partial matches; new suffix ranges are checked against the same strong ETag. Servers without range support or a strong ETag continue with one connection.
NFS URLs use libnfs syntax, for example:
nfs://192.168.1.20/export/games/game.pkg
The NAS must expose an NFS share reachable from the console. No kernel NFS mount, FUSE layer or firmware-specific mount patch is required.