Setting the `AGEDEBUG` environment variable to `plugin` will cause all
plugin communications, as well as the plugin's stderr, to be printed to
the stderr of the parent process (e.g. rage).
If a Base64 line has length 2 or 3 mod 4, there are more bits in the
encoding characters than can be decoded into bytes. RFC 4648 states:
For example, if the input is only one octet for a base 64 encoding,
then all six bits of the first symbol are used, but only the first
two bits of the next symbol are used. These pad bits MUST be set to
zero by conforming encoders, which is described in the descriptions
on padding below.
The `base64` crate enforces this check, but in the 0.7.0 refactor we
forgot to enforce it ourselves.
The length of a Base64 encoding can never be 1 mod 4, because that
only provides six of the eight bits necessary for encoding a byte.
Previously we checked that every line was valid Base64 (which works
because all lines except the last are 64 characters, which exactly
encodes 48 bytes).
In 0.7.0 we improved the parser efficiency by only running the Base64
decoder lazily. We replaced the per-line check with an `is_base64_char`
check, but forgot to reject the invalid subset of last-line lengths.
We switch from the c2-chacha crate to the chacha20 crate, as the latter
is now close to equivalent performance (equivalent when compiled with
`RUSTFLAGS="-Ctarget-feature=+avx2"`), and is no longer optional
upstream.
Instead of checking that each line is individually valid Base64, just
check line lengths. The no-padding-character check is moved to the end,
and the final Base64 decode is now load-bearing.
The parser structure has also been simplified using `nom` combinators.
We don't want plugin binaries to make any assumptions about where they
are run from. The easiest way to ensure this is to always run them from
a fresh temporary directory.
Closesstr4d/rage#200.
This enables plugins to wrap file keys to identities, for example when
the plugin is built around a symmetric primitive (since we do not want
the recipients encoding to ever contain secrets).
The previous iteration of the recipient-v1 state machine assumed that
user interaction would never be required during encryption. This is
almost certainly true for asymmetric recipients, but is not the case
for symmetric recipients (e.g. the symmetric key might be stored on a
hardware token that requires a PIN).
The recipient-v1 state machine now uses a bi-directional second phase,
matching the identity-v1 state machine. It defines the same commands
for interacting with users.
FiloSottile/age has implemented the client side of the specification,
and is able to communicate with our plugin side. This is sufficient for
releasing beta plugin support!
This implements the same mitigation as FiloSottile/age for the multi-key
attack. The age crate was already checking these lengths for built-in
recipient types; this change extends the mitigation to other crates that
reuse the age primitives, such as age plugins.
This enables a stream of stanzas to be parsed, such as in the upcoming
plugin IPC. Previously the parser could not distinguish an
stanza with a body of length 0 mod 64 from an incomplete stanza. This did
not cause issues for V1 header parsing because the recipients list is
always terminated with the MAC line, which has a distinct prefix.
V1 header parsing now accepts either kind of stanza body encoding.
