rye

repository·main·Indexed 20 days ago

https://github.com/refaktor/rye

A programming language ecosystem featuring a local interpreter builder (l.rye), the ryesig tool for Ed25519 script signing and verification, and the cato inline editor. It includes an official VS Code extension for syntax highlighting and support for Ollama integration for text generation, embeddings, and chat completions via the b_ollama build tag.

Tokens
14.1K
Snippets
60
Records
82
Agent score
71%

What's inside rye

  1. Overview of Rye Configuration Steps

    main

    The examples are organized into six progressive steps to demonstrate the capabilities of Rye configuration:

    • Step 1: Minimal Server: Demonstrates pure data notation with key-value pairs and a basic markdown server.
    • Step 2: Basic Computation: Introduces arithmetic operations (* and +) and derived values within the config.
    • Step 3: Environment Variables: Demonstrates the get-env builtin and the any combinator for providing fallbacks when environment variables are missing.
    • Step 4: Route Registration: Shows the route builtin and conditional logic using if and = for dynamic routing.
    • Step 5: User Functions: Introduces the fn keyword for user-defined functions, including string operations like replace and capitalize?.
    • Step 6: Debugging: Features the probe tool for value inspection and enter-console for live REPL debugging, including execution limits for safety.
  2. Overview of rye-contrib packages

    main
    The rye-contrib collection contains packages for contributed, third-party, or unofficial bindings and built-in functions for the Rye ecosystem. These are generally considered less-official than the core Rye packages.
  3. Rye Language VS Code Extension Features

    main

    The extension provides comprehensive syntax highlighting and editor support for the Rye programming language.

    Supported File Extensions:

    • .rye

    Key Features:

    • Syntax Highlighting: Covers comments (;), strings ("" and ``), numbers, constants (true, false, none, nil, _), URIs, file paths (%path), email addresses, and XWords (<type>).
    • Word Highlighting: Specialized highlighting for various word types including Set-words (word:), Mod-words (word::), Left set/mod words (:word, ::word), Get-words (?word), Tag-words ('word), Op-words (.word), Pipe-words (|word), and Return words (^word).
    • Language Constructs: Highlighting for keywords (e.g., fn, does, if, try, context), operators, built-in functions, and context paths (module/function).
    • Editor Utilities: Bracket colorization ({}, [], ()), block-based code folding, and auto-closing pairs for brackets and strings.
  4. Conceptual approaches for Rye script signing and key management

    main

    The project is exploring several methods to implement a 'signed code mode' where the Rye evaluator only runs scripts signed by trusted keys. The following strategies are being evaluated for security and portability:

    1. Keys embedded in Rye binary

    Each project or application can include its own Rye binary with trusted public keys embedded directly.

    • Pros: Binds the keys to the binary, making it harder to replace keys without replacing the binary.
    • Cons: Requires the trusted person to have Go and Rye dependencies installed to build the binary; pushes trust to the person building the binary.

    2. Keys on System Keystore

    Using OS-level keystores (e.g., via PKCS#11).

    • Pros: Leverages existing system security.
    • Cons: Highly OS-dependent; lacks a unified standard across Linux distributions (e.g., Ubuntu); high complexity and portability issues.

    3. Keys in application directory

    Storing keys locally within the application folder.

    • Pros: All files are local and easy to manage.
    • Cons: Requires strict file permissions (e.g., 440) to prevent unauthorized changes; vulnerable if an attacker copies the entire directory structure to a new location where they have write access.

    4. User-level path (Linux specific)

    Treating the Linux user as the unit of trust and looking for keys in a user-specific path.

    • Pros: If the path has 440 permissions, an attacker would likely need superuser access to create a new user to bypass the restriction.
  5. Security requirements for policy files

    main

    To prevent unauthorized modification of security constraints, all policy files (.ryesec, /etc/rye/*.yaml) and key files must meet strict ownership and permission requirements:

    • Ownership: Must be owned by root (uid 0).
    • Permissions: Must not be writable by group or others (mode 644 or stricter).

    Note: If these requirements are not met, Rye will refuse to run.

  6. How Rye script signing works

    main

    The ryesig tool manages signatures that are compatible with Rye's built-in verification system.

    Signature Format

    Signatures are appended to the end of the script file using this format:

    ;ryesig <hex-encoded-signature>

    Automatic Verification

    Rye can automatically verify signatures when running a script in two ways:

    1. Manual Flag: Use the --codesig flag when executing the script.
    2. Trusted Keys: Place a .codepks file containing trusted public keys in the same directory as the script.

    Security Best Practices

    • Private Keys: Keep them secure. Anyone with the private key can sign scripts that appear to come from you.
    • Public Keys: These can be shared freely. For system-wide verification, distribute them via .codepks files.
  7. How the Unified Security Policy works

    main

    Rye uses a hierarchical security policy system to configure system call filtering (seccomp), filesystem access control (landlock), and code signing. Policies are applied based on a priority order, where higher priority sources override lower ones:

    1. Embedded (compiled into the binary): Highest priority; cannot be bypassed.
    2. System (/etc/rye/mandatory.yaml): Must be root-owned.
    3. Local (.ryesec in the script directory): Must be root-owned.
    4. CLI flags: Lowest priority.

    If a policy defines mandatory: true, it cannot be relaxed or overridden by CLI flags.

  8. Generate an Ed25519 key pair with ryesig

    main

    Use the --generate (or -g) flag to create a new Ed25519 key pair. This will produce two files: a public key ([path].pub) and a private key ([path].priv).

    If you do not specify an output path, the tool defaults to creating files named keys.pub and keys.priv.

    rye cmd/ryesig/main.rye --generate my_keys
    # Creates my_keys.pub and my_keys.priv
  9. Run Landlock filesystem access control tests

    main

    Landlock tests verify that Rye's Linux filesystem access control is working correctly. You can test different profiles by using the -landlock and -landlock-profile flags.

    Profiles available:

    • readonly: Blocks write, create, and delete operations; blocks execution.
    • readexec: Blocks write, create, and delete operations; allows execution.
    • custom: Uses specific path permissions defined via -landlock-paths.

    Note: Landlock requires Linux kernel 5.13+ and must be enabled during the Rye build process.

    # Test readonly profile
    rye -landlock -landlock-profile=readonly security/test_landlock_comprehensive.rye readonly
    
    # Test readexec profile
    rye -landlock -landlock-profile=readexec security/test_landlock_comprehensive.rye readexec
    
    # Test custom profile
    rye -landlock -landlock-profile=custom -landlock-paths=landlock_test/readable:r,landlock_test/writable:rw security/test_landlock_comprehensive.rye custom
  10. Configure Seccomp profiles in Rye

    main

    Rye uses Seccomp (secure computing mode) to restrict system calls, enhancing security by limiting the potential damage from compromised processes. You can control the level of restriction using the -seccomp-profile flag.

    Available profiles:

    • strict: The default profile. It allows essential syscalls for Go programs, including read and write operations, but blocks dangerous syscalls like execve to prevent external command execution.
    • readonly: Blocks write operations to files while allowing read operations. This is ideal for running untrusted scripts that should only access the filesystem in a read-only capacity.
    # Use the strict profile
    rye -seccomp-profile=strict
    
    # Use the readonly profile
    rye -seccomp-profile=readonly
  11. Use Landlock and Seccomp together for defense in depth

    main

    For maximum security, you can combine Landlock (which restricts filesystem access) with Seccomp (which restricts syscalls). This provides multiple layers of security for Rye scripts.

    • Use both for maximum security by applying a seccomp profile and enabling landlock.
    • Use Landlock alone if you only need to enforce filesystem restrictions without restricting syscalls.
    # Maximum security: strict seccomp profile + readonly landlock
    rye -seccomp-profile=strict -landlock -landlock-profile=readonly script.rye
    
    # Filesystem restrictions only: custom landlock profile
    rye -landlock -landlock-profile=custom -landlock-paths=/home/user/data:r,/tmp:rw script.rye