GitHub - Brooooooklyn/keyring-node: https://github.com/hwchen/keyring-rs Node.js binding via https://napi.rs. Including 100% compatible node-keytar alternative. · GitHub
Skip to content

About

https://github.com/hwchen/keyring-rs Node.js binding via https://napi.rs. Including 100% compatible node-keytar alternative.

Resources

Stars

106 stars

Watchers

2 watching

Forks

Repository files navigation

@napi-rs/keyring

https://github.com/Brooooooklyn/keyring-node/actions Downloads

https://github.com/hwchen/keyring-rs Node.js binding via https://napi.rs

Usage

import { Entry } from '@napi-rs/keyring'

const entry = new Entry('my_service', 'my_name')
entry.setPassword('topS3cr3tP4$$w0rd')
const password = entry.getPassword()
console.log('My password is ', password)
entry.deletePassword()

Linux backend selection

On Linux, Entry and AsyncEntry pick a credential store automatically: the Secret Service (gnome-keyring, KWallet, keepassxc, ...) is tried first, and the binding silently falls back to the kernel keyutils keyring when no Secret Service is available.

You can pin an entry to one specific store by passing the options bag as the last argument (the option is accepted on every platform but only meaningful on Linux):

new Entry('my_service', 'my_name', { linux: { store: 'secret-service' } }) // require Secret Service
new Entry('my_service', 'my_name', { linux: { store: 'keyutils' } }) // require the kernel keyring
Entry.withTarget('target', 'my_service', 'my_name', { linux: { store: 'keyutils' } })

When a store is required, the constructor throws if that store is unavailable — there is no silent fallback. When withTarget is combined with the keyutils store, the target is used as the kernel key description, so distinct targets keep distinct credentials.

Note: the keyutils store keeps credentials in kernel memory: per the linux-keyutils-keyring-store docs, the key management facility "is completely in-memory and will not persist across reboots". Prefer secret-service for credentials that must survive a restart.

Bundled Rust dependencies

The prebuilt .node binaries are built with --locked from the committed Cargo.lock, and with cargo auditable, which embeds the exact list of Rust crates compiled into each binary. Recover it for license compliance or vulnerability scanning with:

cargo install rust-audit-info
rust-audit-info node_modules/@napi-rs/keyring-darwin-arm64/keyring.darwin-arm64.node

# or scan for known vulnerabilities
cargo audit bin node_modules/@napi-rs/keyring-darwin-arm64/keyring.darwin-arm64.node

syft, trivy and grype read the same data.

Each platform package also ships a LICENSE.third-party.md with the license texts of those crates, generated by cargo-about. After changing Cargo.lock, regenerate them with yarn licenses (needs cargo install --locked cargo-about --features cli); CI fails while they are stale.

Note: the Linux binaries statically link libdbus (built from the sources vendored by libdbus-sys), which is licensed under AFL-2.1 OR GPL-2.0-or-later rather than the crate's own MIT OR Apache-2.0. The Linux LICENSE.third-party.md files include its license and copyright notices.

About

https://github.com/hwchen/keyring-rs Node.js binding via https://napi.rs. Including 100% compatible node-keytar alternative.

Resources

Stars

106 stars

Watchers

2 watching

Forks

Releases

Sponsor this project

Packages

Used by

Contributors

Languages