A secret too large for the locked-memory limit fails with an error, not a panic (closes #145)
check / check (push) Waiting to run
check / check (push) Waiting to run
secret add, import and generate secret crashed with memguard's panic once a value outgrew the locked-memory limit, and because the value was held twice, half the usual 8 MiB limit was enough. secret now raises the limit to the hard limit at startup. Each of the three commands refuses, before its first locked allocation, a limit that leaves fewer than 8 pages for its keys and buffers. The value is read a page at a time into a memguard.Stream, which keeps it encrypted, and copied once into locked memory after its size is checked against 100 MiB and the limit. It leaves the stream through Next, not Read: Read re-encrypts a leftover piece, and memguard hangs if that runs out of locked memory. Model: opus-5-5
This commit is contained in:
@@ -129,6 +129,17 @@ one.
|
||||
|
||||
### Secret Management
|
||||
|
||||
#### Secret Size
|
||||
|
||||
While `secret` works on a secret's value it keeps the value in locked memory, so
|
||||
the value counts against the locked-memory limit (`ulimit -l`). `secret` raises
|
||||
that limit to the hard limit when it starts. `secret add`, `secret import` and
|
||||
`secret generate secret` refuse a value that does not fit in the limit with 8
|
||||
memory pages to spare (32 KiB with 4 KiB pages), with an error that names the
|
||||
limit. Linux's usual limit of 8 MiB allows a value of nearly 8 MiB; a larger one
|
||||
needs a higher hard limit, such as `memlock` in `/etc/security/limits.conf`. No
|
||||
value may be over 100 MiB, whatever the limit.
|
||||
|
||||
#### `secret add <secret-name> [--force]`
|
||||
|
||||
Adds a secret to the current vault. Reads the secret value from stdin.
|
||||
|
||||
Reference in New Issue
Block a user