Crate sequoia_ipc

source ·
Expand description

IPC mechanisms for Sequoia.

This crate implements IPC mechanisms to communicate with Sequoia services.

§Rationale

Sequoia makes use of background services e.g. for managing and updating public keys.

§Design

We use the filesystem as namespace to discover services. Every service has a file called rendezvous point. Access to this file is serialized using file locking. This file contains a socket address and a cookie that we use to connect to the server and authenticate us. If the file does not exist, is malformed, or does not point to a usable server, we start a new one on demand.

This design mimics Unix sockets, but works on Windows too.

§External vs internal servers

These servers can be either in external processes, or co-located within the current process. We will first start an external process, and fall back to starting a thread instead.

Using an external process is the preferred option. It allows us to continuously update the keys in the keystore, for example. It also means that we do not spawn a thread in your process, which is frowned upon for various reasons.

Please see IPCPolicy for more information.

Re-exports§

Modules§

  • keybox
    Support for the GnuPG keybox format.
  • sexp
    S-Expressions for communicating cryptographic primitives.

Structs§

  • Config
    Represents a Context configuration.
  • Context
    A Context for Sequoia.
  • Descriptor
    A descriptor is used to connect to a service.
  • Keygrip
    A proprietary, protocol agnostic identifier for public keys.
  • Server
    A server.

Enums§

  • Error
    Errors returned from the network routines.
  • IPCPolicy
    IPC policy for Sequoia.

Traits§

  • Handler
    Servers need to implement this trait.

Type Aliases§