Table of Contents
Permissions, sandboxing, and trust
Modules are your own unrestricted code. Packages run in separate sandboxes unless you explicitly trust them. A sandboxed package receives only the permissions declared by its manifest and accepted during installation.
Test a local package in its manifest sandbox before publishing. The package detail should describe the same access an installer will be asked to grant.
Permissions from a package and its transitive dependencies are combined. If an update requests additional access, smudgy waits for approval before loading that version.
Runtime resources
These fields control Deno and web-platform APIs:
| Manifest field | What it allows |
|---|---|
net | Connections to listed hosts or host:port targets. |
read | Reading listed files or directory trees. $DATA names the package's private data directory. |
write | Writing listed files or directory trees. $DATA names the package's private data directory. |
env | Reading listed environment variables. |
sys | Reading listed categories of operating-system information, such as hostname, osRelease, cpus, or systemMemoryInfo. |
run | Starting the listed programs, named by executable name or absolute path. The child process runs with the user's operating-system authority, outside Smudgy's script sandbox. |
ffi | Loading the listed native libraries. $DATA may be used in a path, but loaded native code executes outside Smudgy's script sandbox. |
import | none allows only smudgy modules and declared packages; registries also allows npm and JSR; any also allows arbitrary HTTP(S) modules. |
Network access and code imports are independent. For example, importing an npm package requires import: "registries"; letting that package call a web service also requires the corresponding net target.
