dickyj-grc/Amoeba

Amoeba has a strong core design for a young project. The Rust code is divided cleanly across authentication, routing, capacity control, container lifecycle, configuration, metering, and app management. Private services fail closed, permissions map HTTP operations to roles, proxy responses stream without buffering, and active connections prevent premature scale-to-zero. ArcSwap-based hot reloads, bounded request bodies, upstream timeouts, secret-file permissions, and capacity admission checks show careful engineering. The repository also includes a locked dependency graph, unit and integration tests, example configurations, Docker packaging, and a nightly DigitalOcean test that exercises authentication, app installation, RBAC, streaming, and scale-to-zero.

The largest gap is between the documented authentication architecture and the executable server. The README and example TOML describe configurable local JWT and JWKS modes, issuer and audience checks, configurable paths, and a configurable bind address. main.rs does not load that file. It always starts local HMAC authentication, uses fixed file paths, binds to 0.0.0.0:8080, and falls back to a known default signing secret when the environment variable is absent. Production startup should fail when the secret is missing. JWKS mode also needs to be wired into startup and tested with real RSA or EC keys before it can be presented as supported. Token revocation has another important flaw: revoked identifiers live only in memory, so restarting with the same signing secret makes previously revoked, unexpired tokens valid again. The README incorrectly says restart forces every caller to log in again.

App packages need stronger validation because Amoeba has access to the host Docker socket. A package-provided Compose file can effectively gain host-level control, so installation should be described and treated as running trusted code. Manifest names currently reject separators but still allow . and .., while secret keys and referenced package paths are joined without strong containment checks. Multipart uploads and extracted archives also have no clear size, file-count, or expanded-size limits. Strict slug validation, canonical path checks, archive limits, signed package support, and explicit trust warnings would reduce this risk. The catalog mutex also belongs in shared application state because a new AppManager and mutex are created for each request, leaving concurrent installs vulnerable to lost updates. Finally, the security policy is untouched boilerplate that lists versions 4.x and 5.x even though the project is at 0.1.0. Replacing it with a real private reporting process should be a release priority.