Rose overview

Rose is the focused Linux distribution/runtime for the Windows WSL2 path. The current package is an Alpine root filesystem containing STATIC, an eBPF program, Linux networking tools, and a fallback startup script. It is not a second web proxy, a hosted exit, or evidence that a custom Linux kernel is installed. WSL2 supplies the Linux kernel; Rose supplies the userspace image and operating contract.

                                      
                                     
 ████████   ██████   █████   ██████  
░░███░░███ ███░░███ ███░░   ███░░███ 
 ░███ ░░░ ░███ ░███░░█████ ░███████  
 ░███     ░███ ░███ ░░░░███░███░░░   
 █████    ░░██████  ██████ ░░██████  
░░░░░      ░░░░░░  ░░░░░░   ░░░░░░   
                                     
                                     
  /-_-\
 /  /  \
/  /    \
\  \    /
 \__\__/
    \\
    -\\    ____
      \\  /   /
____   \\/___/
\   \ -//
 \___\//-
    -//
     \\
     //
    //-
  -//
  //
  \\
   \\

The boundary between host, distro, and proxy

How a request moves→ request ← response
ClientWindows browserStarts the request
Local middlewareSTATIC in RoseShapes supported signals
DestinationWebsiteReceives the request
On your deviceOutside your device

The browser routes to STATIC’s local proxy listener in WSL2. STATIC opens the outbound request; the attached Linux packet path can adjust supported egress fields when its program and profile map are ready. The website receives traffic through your normal network route.

Windows owns the browser and host certificate trust. someguy or the CLI operator imports and starts the distribution. STATIC owns HTTP/TLS interception, profile selection, injected JavaScript, CA key custody, and the local API. Rose supplies the filesystem, dependencies, WSL integration, and Linux environment for packet handling. Rose’s eBPF packet path follows the packet from profile selection to the egress interface; STATIC’s packet boundary focuses on the handoff from the proxy.

What ships in the root filesystem

/etc/wsl.conf              default user and automount settings
/etc/resolv.conf           fallback DNS configuration
/opt/404/static            musl-linked STATIC executable
/opt/404/ttl_editor.o      compiled eBPF program
/opt/404/404-init.sh       fallback/manual launcher
/opt/404/distro-version    version baked into the archive
/opt/404/win-user          Windows username supplied at runtime

The Alpine image definition installs bpftool, iproute2 (including tc), and libgcc. A glibc-targeted host binary is not a substitute for the release’s x86_64-unknown-linux-musl binary. The host-side TOML and profiles are supplied through the Windows mount, rather than being the source of truth inside the tarball.

Read this section in order

  1. Distribution anatomy follows the rootfs, startup paths, config mounts, and packet attachment.
  2. eBPF packet path explains the classifier, packet fields, map synchronization, and verification on the wire.
  3. Provisioning and updates separates the self-hosted import from someguy’s managed workflow.
  4. Build and release traces Rust, JS, eBPF, Alpine packaging, signed manifest, and publication through CI.

The Windows CLI installation guide is the operational path. This section explains what that installation is actually running.

The Developer resources hub maps these references to repositories and the local API.