revault_api 0.1.0-aarch64-linux → 0.3.12-aarch64-linux

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 2d880e754be5480c6279cf84d892323e67e4255a627ce98450fb5a121687835d
-  data.tar.gz: 198bdb505793856ef0de283a749a684c229d58c1c52ef10e59a2c2737e25ab6a
+  metadata.gz: 3efa85e4f6c3a302809824e0d2bf3917170197aaf19d3b114ce0a4d255941700
+  data.tar.gz: 4b269c717259473dfb57bfdef584956307a3bdeebcef77b161a0b584124e2945
 SHA512:
-  metadata.gz: 36a0cef1e88cc0f63999f099787a4b41fbf6ac7d34510afa729c708e91d08368fdc8e8701ddb0188a0f3499caec2ba5bc3df25f726320ff9d05b8ccb61df8dab
-  data.tar.gz: 8a7845af64a1a49562d6d409a1ec529bffcc5b1182c8af88d91f50ab585bd2b97c971425d20bbe54367e181815efd1d97e3b46fd75298ad8629575f13fcd470c
+  metadata.gz: 3c098655bb4c721e80751addd38e5be933885faf080cb1a7a03452d47962e6f00ce78587e3dfde79ffe610a6bba8b61f1ccb54f56659c601c5a867d100764fa8
+  data.tar.gz: bd955113153f2c8b64d63070bb5a1c01aeda16e7b5b5305c2fac389fdf989f574bc499bd74d49f235ad9a0d86b63b3b9065e7262cc6ac441388f75c618ffc351

data/LICENSE

@@ -1,8 +1,8 @@
-reVault Source Available License 1.0
+Dvault Source Available License 1.0
 
 Copyright (c) 2021 OnePub IP Pty Ltd
 
-This license applies to the reVault software and associated documentation files
+This license applies to the dvault software and associated documentation files
 (the "Software").
 
 1. Grant of Rights

data/README.md

@@ -0,0 +1,419 @@
+# reVault / Lockbox
+
+reVault creates portable archives that are secure and compressed.
+
+The reVault archives are called 'Lockboxes'.
+
+You can think of a Lockbox as a zip file on steriods. 
+
+A Lockbox can be used to store:
+* files
+* directories
+* symlinks
+* file/directory permissions
+* variables
+* forms (collection of variables)
+
+
+A lockbox is encrypted, compressed and signed using modern encryption and compress
+techniques.
+
+reVault is designed to be simple and safe to use, avoiding overly complex 
+terminology.
+
+reVault works on Linux, Windows and MacOS.
+
+reVault ships as a:
+  * cli
+  * apis
+  * libraries for multiple languages
+
+
+
+- `revault_cli`, a CLI for everyday use.
+- `revault_lockbox_api`, for creating lockboxes.
+- `revault_vault_api`, for creating and managing vaults.
+
+Terminology is explicit:
+
+- A **lockbox** is a portable archive and uses the `.lbox` extension.
+- A **key** is used to lock and unlock lockboxes. Keys are more secure than passwords.
+- A **vault** is where we store information about lockboxes such as the keys
+used to open and close a lockbox. The vault also holds a contact list which helps us share 
+lockboxes with other people.
+  
+
+> **Pre-release:** the Rust implementation is currently alpha software. The
+> archive format and public APIs may change between releases. Do not use it as
+> the only copy of important data, and keep vault backups and profile recovery
+> material offline.
+
+## Installation
+
+The best way to start with reVault is to install the CLI tooling.
+
+
+### crates.io
+The easist way to install the reVault CLI is from crates.io
+
+```
+cargo install revault_cli
+```
+
+
+### repo
+
+You can also install the CLI by cloning the github repo.
+
+```bash
+git clone https://github.com/onepub-dev/reVault.git
+cd reVault/rust
+cargo xtask install-cli
+```
+
+# Initialise your vault
+
+In order to create a lockbox you must first initialise your Vault.
+
+When you install the reVault CLI, Cargo installs both `lockbox` app and its alias `lbx` into `~/.cargo/bin`.
+Ensure that directory is on your `PATH`.
+
+To initialise your vault run:
+
+```bash
+lbx vault init
+```
+The init command will create the keys need to create/open and close lockboxes.
+The keys are stored in your reVault vault.
+
+The init command will also dump those keys to the terminal. You need to backup those
+keys safely.
+* If you loose the keys you will not be able to access any lockbox - there is no way to recover from this!!!
+* If some else gets access to those keys then they have access to all of your lockboxes.
+
+
+## CLI Quick Start
+
+Create a lockbox for the default vault profile: (recommended)
+
+```bash
+lockbox secrets.lbox create
+```
+
+For a lockbox protected by a passphrase instead of a vault profile:
+
+This form is less secure than using a profile.
+
+```bash
+lockbox secrets.lbox create --password
+```
+
+Open it for normal commands:
+
+```bash
+lockbox secrets.lbox open
+```
+
+### Persistent directory mirrors
+
+A mirror project records a one-way relationship between a host directory and
+an exclusively managed directory inside the lockbox. The project definition,
+including its include and exclude rules, is encrypted inside the lockbox and
+travels with it.
+
+```bash
+lbx secrets.lbox mirror source create --from ./src --to /projects/source
+lbx secrets.lbox mirror source rule add exclude target/** '*.tmp'
+lbx secrets.lbox mirror source status
+lbx secrets.lbox mirror source update
+```
+
+`status` previews the complete plan; `update` recalculates and applies it.
+Multiple projects can coexist when their destination directories do not
+overlap. See the [CLI guide](docs/cli_how_to.md#mirror-a-host-directory-safely)
+for ownership, deletion, rule, and safety details.
+
+The open is cached in a per-user in-memory agent which will automatically close
+it after about 30mins.  Lock it when you are done:
+
+```bash
+lockbox secrets.lbox close
+```
+
+Add files:
+
+```bash
+lockbox secrets.lbox add --recursive ./project --to project/
+lockbox secrets.lbox add ./generated.env --to secrets/prod.env
+```
+
+List and extract:
+
+```bash
+lockbox secrets.lbox list /
+lockbox secrets.lbox list '/project/**/*.rs'
+lockbox secrets.lbox extract /project/README.md ./out/README.md
+```
+
+See [docs/cli_how_to.md](docs/cli_how_to.md) for command-focused examples.
+
+## Profiles And Sharing
+
+Create another local profile:
+
+```bash
+lockbox vault profile create laptop
+```
+
+Create an independent encrypted vault with a fresh profile and register that
+profile's public key as a contact in the current vault:
+
+```bash
+lbx vault beget production
+# Creates production.vault.lbx with profile:production.
+# Saves only the public key locally as contact:production.
+
+lbx access grant shared.lbox contact:production
+```
+
+Use `--output` to choose the new vault path, `--contact-name` to avoid a local
+contact-name collision, or `--no-contact` to leave the current vault unchanged.
+`beget` never grants lockbox access automatically and never copies private
+material from the current vault.
+
+List profiles and export a public key:
+
+```bash
+lockbox vault profile list
+lockbox vault profile export ./laptop.pub --name laptop
+```
+
+Import a contact public key after independently verifying its fingerprint:
+
+```bash
+lockbox vault contact import alice ./alice.pub \
+  --fingerprint <fingerprint> \
+  --fingerprint-channel phone-call-to-owner
+```
+
+Create a lockbox for a recipient:
+
+```bash
+lockbox shared.lbox create --for alice
+```
+
+Grant or revoke access on an existing lockbox:
+
+```bash
+lockbox shared.lbox access grant alice
+lockbox shared.lbox access list
+lockbox shared.lbox access revoke alice
+```
+
+Exporting a private key is supported for backup and migration, but treat the
+output as a secret:
+
+```bash
+lockbox vault profile backup ./default.profile-backup
+```
+
+Private vault keys are stored inside the local vault as secret variable records,
+not as normal files in the vault lockbox. See the CLI help and
+[CLI how-to](docs/cli_how_to.md) for vault backup and profile recovery.
+
+## Variables
+
+Variables are encrypted metadata, not files. They do not appear in file
+listings and are loaded only when variable commands or APIs request them. The
+canonical command is `variable`; `variables` and `var` remain compatibility
+aliases.
+
+Plain variables are for values that are useful configuration but not high-value
+secrets:
+
+```bash
+lockbox secrets.lbox variable set DATABASE_URL --value 'postgres://localhost/app'
+lockbox secrets.lbox variable set DATABASE_URL='postgres://localhost/app'
+lockbox secrets.lbox variable get DATABASE_URL
+```
+
+With a session-default lockbox, assignment syntax is also supported:
+
+```bash
+lockbox variable set DATABASE_URL='postgres://localhost/app'
+lockbox variable set DATABASE_URL 'postgres://localhost/app'
+```
+
+Secret variables are for passwords, API tokens, signing keys, and similar
+material. They use secure-memory handling in the variable path and must be provided
+through an explicit source:
+
+```bash
+lockbox secrets.lbox variable set --secret API_TOKEN --interactive
+lockbox secrets.lbox variable set --secret API_TOKEN --file ./api-token.txt
+lockbox secrets.lbox variable set --secret API_TOKEN --stdin
+lockbox secrets.lbox variable set --secret API_TOKEN --from-env API_TOKEN
+```
+
+Avoid passing secrets as command-line arguments. Shell history and process
+inspection can expose argv. Prefer `--interactive`, `--stdin`, `--file`, or
+`--from-env`.
+
+Sensitivity is chosen when a variable is created. Updating the value preserves
+that sensitivity. To change plain to secret, or secret to plain, delete and
+recreate the variable.
+
+## Avoiding Leaks
+
+Use these defaults unless you have a specific reason not to:
+
+- Use `lockbox open` and the local agent instead of repeatedly passing
+  passwords or private keys.
+- Use secret variables for credentials and tokens.
+- Do not store secrets as normal files when variable semantics are appropriate.
+- Do not pass secret values on the command line.
+- Keep private key exports offline, short-lived, and permission-restricted.
+- Prefer recipient keys over shared passwords for team access.
+- Run `lockbox secrets.lbox close` when an open should no longer be cached.
+- Use `lockbox secrets.lbox visualize` for diagnostics; it intentionally avoids
+  printing file paths, file contents, variable names, or variable values.
+
+
+Lockbox protects data inside the container. It cannot protect a secret after you
+write it to a normal terminal, shell history, clipboard, exported file, build
+log, or process environment controlled by other tooling.
+
+## Key Server, Topology, and Replication
+
+`revault_key_server` is a short-lived rendezvous service for sharing candidate
+contact public keys. A publisher uploads a payload, verifies their email, and
+shares the resulting publish code with the recipient. The recipient uses that
+code to receive the candidate key, then verifies its fingerprint independently
+before trusting it. The server does not establish profile trust and is not a
+store for private keys.
+
+### Single server
+
+A first deployment uses one server with `server_id = 0`. Publish codes include
+that server id as their first digit, followed by a random code body. Using a
+self-routing code from the start keeps pending publishes compatible if the
+deployment later gains standby servers.
+
+### Topology servers
+
+Servers publish a topology document containing the known server URLs and the
+primary/failover route for each publish-code owner id. Clients use it as follows:
+
+- For a publish, discover the cluster through a topology endpoint, select a
+  key-server member, and keep that choice sticky locally.
+- For receive and delete, read the publish code's first digit, contact that
+  owner id's primary server, then use only its configured failovers.
+- Do not fail over after a rate-limit response; hopping servers must not bypass
+  abuse controls.
+
+DNS can provide normal host resolution, but it is not the routing mechanism.
+Round-robin DNS alone can send a receive request to a server that does not own
+the corresponding publish code.
+
+### Replication and failover
+
+Each server is authoritative for the codes carrying its own server id. It sends
+signed state events—published payloads, receive counts, payload lifecycle
+tombstones, and rate-limit blocks—to configured standby peers through the separate
+`/v1/replicate` endpoint. Events carry an origin server id, epoch, and sequence
+number, so standbys apply duplicates idempotently and never replicate received
+peer events again.
+
+Replication does not make the cluster hot/hot. A standby keeps replica state
+but serves an owner's payloads only after an operator explicitly promotes it for
+that owner id. This avoids two servers consuming a single-use publish at the
+same time during a network partition. See the [key-server deployment guide](https://github.com/onepub-dev/reVault/blob/master/rust/revault_key_server/README.md), [configuration reference](https://github.com/onepub-dev/reVault/blob/master/rust/revault_key_server/KEY_SERVER_CONFIG.md), and [redundancy design](https://github.com/onepub-dev/reVault/blob/master/rust/revault_key_server/REDUNDANCY.md) for the deployment and recovery procedures.
+
+## Rust Library
+
+Use `revault_lockbox_api` when you need the portable storage engine:
+
+```rust
+use revault_lockbox_api::{Lockbox, LockboxOpen, LockboxPath, LockboxProtection, SecretVec};
+use std::path::Path;
+
+let key = SecretVec::try_from_slice(b"correct horse battery staple")?;
+let signing_key = revault_lockbox_api::OwnerSigningKeyPair::generate()?;
+let mut lockbox = Lockbox::create_file(
+    Path::new("secrets.lbox"),
+    LockboxProtection::ContentKey(key.try_clone()?),
+    &signing_key,
+)?;
+
+lockbox.add_file(&LockboxPath::new("/docs/a.txt")?, b"alpha", false)?;
+lockbox.add_file(&LockboxPath::new("/docs/b.txt")?, b"bravo", false)?;
+lockbox.commit()?;
+
+let reopened = Lockbox::open(
+    Path::new("secrets.lbox"),
+    LockboxOpen::ContentKey(&key),
+)?;
+let file = reopened.get_file(&LockboxPath::new("/docs/a.txt")?)?;
+```
+
+Use `revault_vault_api` for native applications that want the local vault and
+open-cache behavior:
+
+```rust
+use revault_vault_api::{local_vault, SecretString};
+
+let vault = local_vault();
+let password = SecretString::try_from_bytes(b"pw".to_vec())?;
+
+vault.create_lockbox_with_password("secrets.lbox", &password)?;
+
+let lockbox = vault.open_lockbox_with_password("secrets.lbox", &password)?;
+let mut lockbox = lockbox;
+lockbox.add_file_from_path("notes.txt", &revault_lockbox_api::LockboxPath::new("/notes.txt")?)?;
+lockbox.commit()?;
+```
+
+## Documentation
+
+- [reVault manual](https://docs.revault.onepub.dev/): installation, concepts,
+  CLI workflows, language APIs, and operational guidance.
+- [CLI how-to](docs/cli_how_to.md): command examples.
+- [CI/CD with reVault](docs/ci_cd.md): proposed bootstrap and ephemeral CI
+  workflow for encrypted deployment secrets.
+- [Lockbox Session Agent](docs/lockbox_session_agent.md): local open cache
+  lifecycle, protocol, and security model.
+- [Archive format](rust/revault_lockbox_api/ARCHIVE_FORMAT.md): lockbox archive details and page
+  layout.
+- [Rust development](docs/rust_development.md): build, test, and API docs.
+- [Dependency review](rust/docs/dependency_review.md): dependency and security
+  review notes.
+
+## Development
+
+Run the Rust checks:
+
+```bash
+cd rust
+cargo fmt --all
+cargo check --workspace --all-targets --all-features
+cargo test --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+Generate Rust API docs:
+
+```bash
+cd rust
+cargo xtask generate-api-docs
+```
+
+## License
+
+Dvault Source Available License 1.0 - see [LICENSE](LICENSE).
+
+The source remains available for inspection, modification, and redistribution.
+Derivative works must publish their corresponding source code in a publicly
+accessible repository such as GitHub or a similar service. The license also
+restricts third parties from offering dvault, modified dvault, or substantially
+similar dvault-derived functionality as a hosted, managed, or
+network-accessible service without a separate written license.

metadata

@@ -1,48 +1,32 @@
 --- !ruby/object:Gem::Specification
 name: revault_api
 version: !ruby/object:Gem::Version
-  version: 0.1.0
+  version: 0.3.12
 platform: aarch64-linux
 authors:
 - OnePub
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-07-16 00:00:00.000000000 Z
-dependencies:
-- !ruby/object:Gem::Dependency
-  name: google-protobuf
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.25'
-  type: :runtime
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.25'
+date: 2026-08-26 00:00:00.000000000 Z
+dependencies: []
 description: Complete class-based reVault lockbox and vault API
 email:
+- bsutton@onepub.dev
 executables: []
 extensions: []
 extra_rdoc_files: []
 files:
 - LICENSE
-- generated/revault_bindings_pb.rb
-- lib/revault/binding_operations.rb
-- lib/revault/native_library.rb
-- lib/revault/vault.rb
-- native/linux-aarch64-gnu/librevault_api.so
-- native/linux-aarch64-gnu/librevault_ruby_shim.so
-- native/revault_ruby_shim.c
-- revault_api.rb
-homepage: https://github.com/onepub-dev/reVault
+- README.md
+homepage: https://docs.revault.onepub.dev/
 licenses:
 - Nonstandard
-metadata: {}
+metadata:
+  bug_tracker_uri: https://github.com/onepub-dev/reVault/issues
+  changelog_uri: https://github.com/onepub-dev/reVault/blob/main/bindings/CHANGELOG.md
+  documentation_uri: https://docs.revault.onepub.dev/
+  source_code_uri: https://github.com/onepub-dev/reVault/tree/main/bindings/ruby
 post_install_message:
 rdoc_options: []
 require_paths: