Downloading an HTTPS file on AROS should be as straightforward as running a command. I ported BebboGet 1.11 to three AROS architectures: i386, x86_64 and aarch64 for Raspberry Pi. Stefan “Bebbo” Franke wrote the original program; the AROS port and its changes are my work, published as a GPLv3-or-later fork.
Three downloads, two tools
Each archive contains bebboget, the HTTP/HTTPS client, and installcerts, which installs root certificates from a PEM bundle. Networking requires bsdsocket.library; the cryptographic code is built in. Pick the archive for your machine:
The release pages include the LHA archive and instructions. On the Raspberry Pi AROS setup described in the release, LhA is unavailable, so unpack the archive on another computer and copy the drawer to the SD card. The source is in the port repository.
What changed in the port
BebboGet handles TLS 1.2 and TLS 1.3, redirects and certificate checks against installed roots. Certificates live in SYS:Prefs/Env-Archive/certs. Set the date on the Raspberry Pi before checking certificates: without a configured clock, valid certificates may appear outside their validity period.
The AROS-specific layer connects bsdsocket.library network calls to the C++ code. On x86_64 I reused the minimal runtime from my BebboSSH port to follow the library-base convention in r12. On aarch64 the build avoids posixc.library, associated with memory left allocated on exit in the documented AROS environment.
While porting I also fixed shared-code issues and sent them to the original author, including certificate date handling, some RSA signatures and ECDSA curves, the default HTTP port and detection of truncated transfers.
Tests and limits
The release notes document tests on AROS One i386 and x86_64 in QEMU, including certificate checks and downloads compared with published hashes up to 18.7 MB. On a real Raspberry Pi 400 they report verified transfers up to 26.5 MB and an interrupted download; on QEMU aarch64, networking interrupts transfers after about 150 seconds. For installcerts on the Pi, the release notes specify that the certificates used came from an earlier build: the version in the archive was tested in QEMU.
There are limits worth knowing: HTTP status is not checked, so an error page can be saved as a file; some certificate errors return exit code zero. TLS 1.2 does not offer ECDHE-ECDSA suites, while TLS 1.3 can be used where available. A chain with an unrecognised cross-signed root can require confirmation: the i choice replaces the installed root of the same name, so use it carefully. On x86_64 about 6 KB remain allocated after each run.