ddidderr
2c101abdbd
`--threads` was an `Option<usize>` with no value-parser bound. Passing
`-j 0` slipped past clap and reached the dispatch in `crypto::encrypt`
/ `decrypt`, where the `threads > 1` check evaluates to false for 0 and
the call quietly fell through to the serial path. The user thought
they had asked for "no worker threads" and got something else instead;
either way, 0 workers is not a meaningful configuration.
Switch the field to `Option<u32>` and add `value_parser!(u32).range(1..)`
so clap rejects `-j 0` at parse time with a usage error. Cast to
`usize` at the single use site. Using `u32` rather than `usize` avoids
shipping a host-pointer-width-dependent CLI surface; thread counts well
past 4 billion are not a thing we need to plan for.
Test plan:
- New integration test `rejects_zero_threads` invokes the binary
with `-j 0` and asserts non-zero exit.
- Existing `roundtrip_multi_threaded` (`-j 4`) still passes, so the
range bound has not broken normal usage.
Refs: external review (GLM51 #1; Gemini #3 misdescribed the symptom
as "silent corruption" — verified the actual behaviour was a fall-
through to the serial path, not output corruption, but the fix is
the same).
fcry - [f]ile[cry]pt
A file en-/decryption tool for easy use.
Currently fcry uses ChaCha20Poly1305 (RFC 8439) as AEAD cipher provided by the chacha20poly1305 crate.
Status
Currently fcry is not thoroughly tested and in early stages of development.
There is a chance, that something is broken as of now.
Encryption seems to work, but due to a possible lack of understanding of some underlying methods
(or misinterpretation) it could theoretically be not effective at all.
See TODO.md for further information.