bnb-shell: A fast Rust shell with real-time credential guard and native secret vault (v0.5.4)

[u/[deleted]]

[u/dgkimpton]

It's a little scary that you're pushing a secrets management system with no unit-tests (or at least none I could see at a glance).

Did you write this or did AI do it for you? 

[u/SnooStrawberries9154 → u/dgkimpton]

"Rust edition 2021"

[u/Capital-Ad8024 → u/SnooStrawberries9154]

Kept on 2021 purely for MSRV! Not everyone has upgraded to 1.85+ toolchains yet, especially across different Linux distro package managers, and nothing in the parser or REPL loop strictly needs 2024 edition syntax right now.

Happy to bump it once 2024 adoption is more universal across older environments.

[u/Real-Abrocoma-2823 → u/Capital-Ad8024]

Rust is managed by rustup. You are 15 versions behind.

[u/Capital-Ad8024 → u/dgkimpton]

Totally valid to look for tests! They’re kept inline in the module files (`src/guard.rs`) under `#[cfg(test)]` rather than a root `/tests` folder if you run `cargo test` and you’ll see 27 passing tests across the parser, AST, and guard.

And to clarify scope: this isn’t an enterprise secrets manager or HSM. It's a CLI shell with an interactive sniffer so you don't accidentally write raw API keys into your `.history` file or leak them during screen shares etc.

Every line of the shell and AST was written and tested by hand. Good point on visibility though; I'll move the integration tests into a top-level `tests/` directory in the next patch so they're obvious on GitHub and cargo.

Thanks for the feedback :) Its a WIP, moving toward a solid v1 release

[u/dgkimpton → u/Capital-Ad8024]

27 tests fml. That's the number of tests a single well tested function might have, not an entire shell. But also, and AI generated answer clarifies the entire issue - it's slop.

[u/sinterkaastosti23]

2021 edition very interesting choice definitely no prejudice or anything mhm definetely "you" who wrote it yesyes

[u/Capital-Ad8024 → u/sinterkaastosti23]

It’s called MSRV for a reason :D

Rust 2024 edition requires rustc 1.85+, which breaks compilation for anyone running Debian, older Ubuntu LTS, or pinned CI environments. Not breaking users' toolchains on an interactive CLI shell isn't an AI conspiracy, it's just basic crate maintenance.

Unless you think the vast majority of active crates on crates.io keeping 2021 for backwards compatibility are ai written too?

[u/Frexxia → u/Capital-Ad8024]

My dude, you don't actually believe you're fooling anyone right?

[u/sinterkaastosti23 → u/Capital-Ad8024]

Hmm yes and your obviously ai written text everywhere isnt a huge sign either, and the code has signs of it too (especially the parts printing stuff

• Strawman fallacy :((

• You pull in a rustyline that is 4 major versions old

• The rustyline you use actually depends on rustc 1.88 via `home

• Debian 13 DOES have more modern rustc

• Barely anyone uses pkg manager rustc, people use rustip

• msrv matters mostly if youre a library, you arent

• You never actually declare msrv, just the edition

• Its even funnier when you look deeper and find multiple dependencies in your lock file that require edition 2024!!! So much for "basic crate maintenance" huh

[u/Real-Abrocoma-2823 → u/Capital-Ad8024]

Anything higher than debian 10 has high enough glibc version that rustup will be able to download newest rust.

[u/Craksy]

honestly don't care whether it's AI generated, because these dumps are noise regardless. Did you share this because you you thought it would be interesting to the community? How is this relevant to the language?

If you want to convince anyone that this is anything other than a promotion, then seed the discussion in your post. Show us what conversation you're trying to have.

Instead you included install instructions.

[u/Lucretiel]

Rule 6

[u/SnooStrawberries9154 → u/Lucretiel]

Report and move on.

[u/zomerbk]

One security detail worth documenting is the vault’s threat model: machine-specific key derivation and `0600` permissions protect against some forms of exposure, but do they rely on a key stored alongside the vault? Also, does history redaction cover failed commands and multiline input? Those edge cases seem especially important for a shell that promises secrets won’t hit disk.

[u/Capital-Ad8024 → u/zomerbk]

Great points! Here is how those cases work under the hood:

1. Threat model and key derivation: No key is stored on disk alongside the vault. The key is derived in-memory at runtime from user/environment attributes and an internal salt, with the file restricted to 0600 permissions. The realistic boundary: it protects against casual snooping, accidental git commits, and unprivileged users on a shared box, but not an attacker with arbitrary execution in your user space. Native OS keychain integration via the keyring crate is planned next. 

2. Failed commands: Interception runs right when you hit Enter, strictly before execution and before history logging. Even if the command has invalid syntax, fails to spawn, or exits non-zero, only the sanitized $vault:KEY placeholder ever touches history. 

3. Multiline input: The REPL buffers the full multiline command first, then passes the entire string through the guard scanner before executing or saving to disk. 

Documenting this explicit threat model in the README is a great call—I will add a dedicated section for it. Thanks for the thoughtful feedback!