The stellar/stellar-dev-env repo pins a paired release of sapp-4.3.38 with a companion component "stellar-c-1.0.13", built via an internal RPM repo hostname (el8.repo.internal.geedge.net.repo) and a "tsg_framework.sh" bootstrap script — evidence of a previously undocumented internal component ("stellar-c") versioned alongside sapp and an internal geedge.net package-repo infrastructure supporting TSG-OS builds.
✨ feat(stellar-c sapp version update): sapp-4.3.38 stellar-c-1.0.13
Cited artifacts
mesalab_git—stellar/stellar-dev-env.bundle(git-commit-log)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.
TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.
A June 2021 internal report measures a live in-network TLS-interception pilot: one sapp instance ingests raw ciphertext via mrzcpd while a second ingests plaintext from a "third-party decryption platform" over a Unix domain socket, and one hour of production traffic on a live front-end (10.187.0.2) shows the decryption platform successfully produced plaintext for 4.85% of raw traffic bytes and 7.4% of all port-443 TCP connections, with an average end-to-end decrypt latency of 1741ms (median 460ms, up to 6000ms) between first ciphertext byte and the resulting plaintext HTTP GET.
sapp's plugin API exposes explicit enforcement primitives -- MESA_kill_tcp()/MESA_rst_tcp() to inject a single RST, and MESA_set_stream_opt() with MSO_TCP_RST_REMEDY/MSO_DROP_STREAM to make RST-injection or packet-dropping persist for the remaining lifetime of a flow -- with a global sapp.toml auto_remedy toggle and a per-stream option controlling whether a lone RST is reinforced repeatedly for as long as the flow keeps sending data.
An internal "sapp" developer guide (marked "Geedge Networks Confidential And Proprietary") documents that MESA's core DPI/traffic-processing platform has gone through four generations since roughly 2005 -- start -> papp -> sappv3 -> sappv4 -- with sappv4 (introduced 2019) now the sole actively maintained branch, while some sappv3 deployments still run unless a critical bug forces an upgrade.
sapp's internal architecture guide documents three deployment topologies (mirror/passive-tap, inline, dual-arm transparent) and four distinct methods for injecting blocking packets back onto the wire, including a MAC-in-MAC scheme that extracts device/link IDs from mirrored traffic's source MAC field to route an injected packet to the correct physically separate inline device over VXLAN when multiple injection points exist.