# Snigdha NetGuard — Tor Lifecycle & Bridge Management

# 1. Tor Daemon Integration

Snigdha OS Decentralized packages official Arch Linux Tor (tor 0.4.9.16-1) without modifications or private patches. Tor is configured to operate in a client-only, privacy-hardened mode.

# 1.1 Startup Invariant (DisableNetwork 1)

Unlike conventional desktop operating systems where Tor or NetworkManager connects automatically upon detecting a physical link, Snigdha OS boots with:

DisableNetwork 1

in /etc/tor/torrc.

Rationale: In hostile networks, authoritarian environments, or corporate monitoring scenarios, the mere establishment of a Tor TLS handshake or directory consensus download may trigger immediate network alarms or ISP intervention. Setting DisableNetwork 1 guarantees that Tor binds its listeners on 127.0.0.1 and opens its ControlSocket, but transmits zero packets across physical interfaces until the user makes an explicit decision.

# 2. Connection Lifecycle

The NetGuard daemon (snigdha-netguardd) manages the lifecycle states:

stateDiagram-v2
    [*] --> DISCONNECTED: System Boot (DisableNetwork 1)
    DISCONNECTED --> CONNECTING: User requests 'Connect'
    CONNECTING --> BOOTSTRAPPING: Firewall Verified & Tor Enabled
    BOOTSTRAPPING --> CONNECTED: Bootstrap 100% & Circuit Ready
    CONNECTED --> DEGRADED: Circuit Dropped / Link Interrupted
    DEGRADED --> CONNECTED: Circuit Restored
    CONNECTED --> DISCONNECTING: User requests 'Disconnect'
    DISCONNECTING --> DISCONNECTED: DisableNetwork 1 (Firewall Stays Active)
    BOOTSTRAPPING --> ERROR: Bootstrap Failed / Socket Error
    CONNECTING --> BLOCKED: Firewall Inactive (Safety Abort)

# 2.1 Explicit Connection Steps

1. The user clicks "Connect to Tor" in Polybar/Rofi or runs snigdha-netguard connect.
2. NetGuard verifies that table inet snigdha is loaded and healthy. If inactive, connection is aborted (BLOCKED).
3. If volatile bridges are configured, NetGuard transmits SETCONF UseBridges=1 and Bridge="..." to Tor.
4. NetGuard sends SETCONF DisableNetwork=0 via the Unix domain ControlSocket.
5. Tor begins circuit bootstrap (0% -> 100%).
6. Upon reaching PROGRESS=100 TAG=done and circuit verification, state shifts to CONNECTED.

# 2.2 Disconnection Steps

1. The user clicks "Disconnect from Tor" or runs snigdha-netguard disconnect.
2. NetGuard sends SETCONF DisableNetwork=1 and SIGNAL NEWNYM.
3. State transitions to DISCONNECTED.
4. The firewall ruleset remains 100% active. Applications cannot leak clearnet packets.

# 3. Bridge Management & Censorship Circumvention

Bridges (unlisted Tor relays) allow users in censored environments to reach the Tor network when public directory authorities and guard relays are blocked.

# 3.1 Strict Invariant: Bridge Volatility

Private bridge addresses and fingerprints are sensitive cryptographic credentials. If stored on disk, they create permanent forensic evidence of censorship circumvention.

• RAM-only storage: Bridges configured via CLI or Rofi are stored in memory and written only to volatile tmpfs (/run/netguard/bridges.json).
• Zero persistent writes: Bridges are never committed to physical storage or ISO overlay backing.
• Redaction: Bridge lines are never displayed in full in Polybar, desktop notifications, or system logs. The validator masks IP addresses and fingerprints (e.g., Bridge [REDACTED_IP]:9001 43D2C3...1678).

# 3.2 Bridge Syntax & Security Validation

Before passing a bridge line to Tor, NetGuard's bridge_validator.py applies rigorous parsing:

• Rejects shell metacharacters (;, &, |, `, $, <, >, (, ), ", ').
• Validates IP address format (IPv4 and bracketed IPv6 [addr]:port).
• Validates port numbers (1-65535).
• Verifies 40-character hex identity fingerprints.
• Verifies key=value arguments for pluggable transports.

# 4. Pluggable Transport Support & Provenance

# 4.1 Strict Base Image Policy

To preserve cryptographic supply-chain integrity, Snigdha OS does not bundle unverified third-party AUR binaries into the core distribution. Standard Tor bridges and official meek are supported natively. The transport architecture defines modular client helpers if future official packages become available.