Architecture & Security

Where socksy's files live, and how it keeps your proxy credentials off the process list.

How it's wired

Piece	Location
`socksy` command	`~/.local/bin/socksy` (`/usr/bin/socksy` from a package)
`gost` relay binary	`~/.local/bin/gost`
systemd user service	`~/.config/systemd/user/socksy-relay.service`
watchdog timer (opt-in)	`~/.config/systemd/user/socksy-watchdog.{service,timer}`
relay config (holds credentials)	`~/.config/socksy/relay.yaml` (chmod `600`)
saved profiles	`~/.config/socksy/profiles` (chmod `600`)
optional config	`~/.config/socksy/config`
env-backend exports	`~/.config/socksy/env.sh` (chmod `600`, `env` backend only)
local relay listener	`127.0.0.1:1081`

Proxy credentials are stored in plain text on disk, in the relay config, the systemd unit, and the profiles file, all written with 600 permissions (only your user can read them). This is standard for local proxy setups, but don't commit these files or share them.
Credentials are kept off the relay's command line. Passing them as gost -F socks5://user:pass@host:port would put the password in /proc/<pid>/cmdline, which is world-readable on a default Linux kernel, so any local user could read it out of ps while the relay ran, regardless of the 600 files. socksy instead hands gost a 600 config file. socksy status reports which mode is in use, and you can force it either way with relay_creds (auto is the default; file refuses to start otherwise, args restores the old command-line behaviour):
```
relay_creds = file
```
On a gost too old to accept a generated config, socksy falls back to the command line and says so.
socksy never sends your credentials anywhere except to the upstream proxy you specify.