No description
  • Rust 98.4%
  • Just 1.6%
Find a file
2026-05-29 15:32:40 +01:00
.cargo lontra-xtask: set default-run to avoid having to specify the crate name 2026-05-28 16:35:46 +01:00
crates lontra-xtask pre-commit: test doctests 2026-05-29 15:32:40 +01:00
.gitignore Justfile: add Linux and MacOS cross-compilation 2026-04-11 21:26:21 +01:00
Cargo.lock lontra-asserts: add README.md 2026-05-29 15:29:52 +01:00
Cargo.toml Bump version to 0.1.7 2026-05-29 02:12:19 +01:00
Justfile Justfile: fix tests for cross targets 2026-05-28 19:20:29 +01:00
LICENCE Add Apache-2.0 licence 2026-04-17 22:41:57 +01:00
README.md Add README.md and repository link 2026-04-13 22:52:24 +01:00

Lontra

Lontra is a personal configuration framework.

Lontra is designed to help users manage their dotfiles across multiple machines.

Status

This project is currently work in progress and is not yet ready for general use.

What is lontra?

Lontra is an otter, in Italian.

Usage

  1. Download a binary compatible with your OS from Releases.
  2. Save the binary into a location in PATH. The name of the binary is up to the user, but lontra is recommended for consistency.

TODO: Fix and describe the configuration repository format.

Upgrade security

The current security model relies on SSH signatures. The public key(s) of the project maintainer are compiled into the binary. These keys can be found in allowed_keys.rs.

The upgrade process works as follows:

  • {current} is the name of the currently running binary.
  • {staging} is a temporary filename in the same directory as {current}.
  • {url} is the URL of the remote binary.
  1. If required_version defined in lontra.toml at the root of the configuration repository differs from the current version, a new binary is downloaded into {staging}. The name of the new file is intentionally obscure.
  2. The signature is downloaded from {url}.sig into RAM.
  3. {staging} is verified against the signature. The process aborts with an error if the verification fails.
  4. The {staging} is marked as executable.
  5. The currently running binary is renamed into {current}.bak. This allows the user to manually restore the file if the next steps fail.
  6. {staging} is renamed into {current}.
  7. {current}.bak is removed.