| Age | Commit message (Collapse) | Author |
|---|
|
- Cert::keys_valid() is just a short-cut for
Cert::keys_all().alive().revoked(false).
- Remove Cert::keys_valid() and rename Cert::keys_all() to
Cert::keys().
|
|
- A tuple is just an unnamed, inflexible struct. Use a struct
instead.
- Fixes #400.
|
|
- Now that we eagerly check the syntax, there no longer is the need
for storing Unknown packets there.
|
|
|
|
- If a syntactically malformed subpacket is encountered, we do the
same as for malformed packets, we turn the whole signature into an
unknown packet.
- Fixes #200.
|
|
- The subpacket areas now have a vector of subpackets. Change some
accessors here and there to accommodate this.
- This requires bit-perfect roundtripping of subpackets so that
signatures are not invalidated.
- First step towards fixing #200.
|
|
|
|
|
|
|
|
- The signature knows the hash algorithm.
|
|
- Do not expose the PacketParserResult, improve error handling.
- Fixes #278.
|
|
- See #371.
|
|
- See #371.
|
|
- Fixes #359.
|
|
- See #359.
|
|
- Modify the streaming verifiers to account for clock skew when
using the current time.
|
|
|
|
- And drop Literal::set_filename_from_bytes.
|
|
- Now that we store timestamps in OpenPGP's native encoding, the
canonicalization happens when converting to it.
|
|
|
|
|
|
- Fixes #387.
|
|
- To that end, make VerificationHelper::get_public_keys take
KeyHandles for all the issuers.
|
|
- A signature can contain multiple hints as to who created the
signature. Return all those hints to the caller.
- Adapt all callers accordingly.
- Fixes #264.
|
|
|
|
|
|
- Fixes #381.
|
|
|
|
- Fixes #380.
|
|
- In sq and sqv, use chrono to interface with the user.
- Fixes #341.
|
|
- See #375.
|
|
- See #375.
|
|
- Consider the following scenario: computer A's clock says 9:00.00
and signs and sends a message to computer B. Computer B's clock
says 8:59.59, it receives the message and tries to verify it.
From Computer B's perspective, the signature is not valid, because
it was generated in the future.
- This situation occured, because the two clocks were not completely
synchronized. Unfortunately, a few seconds of clock skew are not
unusual, particularly when dealing with VMs.
- Since it is almost always better to consider such messages as
valid, be tolerant when deciding whether a signature is alive.
|
|
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
- The last commit introduced a gratuitious and unreachable "else if"
branch, remove it.
|
|
- Return a different `VerificationResult` for signatures that are
not alive (BadSignature) from signatures that are actually
bad (BadCheck).
|
|
- The original function was nested too much.
|
|
|
|
|
|
- A SignatureGroup currently contains a hash mapping hash algorithms
to hash contexts. Typically this will only contain one or two
mappings. At most it will contain one mapping for each algorithm
that we support (currently, we support 7 hash algorithms).
- Given the small expected and small maximum size, a vector is the
better data structure:
- The small number of elements means that look up time will be
comparable whether we do a linear scan or look in a hash (in
fact, the linear scan is probably cache friendlier).
- Iterating over a vector is faster than iterating over a hash
map. The is the fast path.
- A vector takes up less space.
- Change SignatureGroup::hashes to use a Vec instead of a HashMap.
|
|
|
|
- To avoid an infinite loop, we need to not only read data, but also
consume it.
- Add a regression test.
- Fixes #349.
|
|
- On debug builds, Vec<u8>::truncate is very, very slow. For
instance, running the decrypt_test_stream test takes 51 seconds on
my (Neal's) computer using Vec<u8>::truncate and <0.1 seconds using
`unsafe { v.set_len(len); }`.
The issue is that the compiler calls drop on every element that is
dropped, even though a u8 doesn't have a drop implementation. The
compiler optimizes this away at high optimization levels, but
those levels make debugging harder.
|
|
|
|
- The `Generic::data_helper` was not sufficiently careful when
dealing with errors. In particular:
- If `Generic::data_hard(1)` was called, and an error occured, and
nothing was buffered or read, `Generic::data_helper` would
return the empty string instead of the error.
- If `Generic::data(n)` was called, and an error occured, but some
data (< n bytes) was buffered, `Generic::data_helper` would
return the error instead of the data that was read.
- Fix these bugs.
- Also, simplify the code and don't save whether we hit EOF or the
error (which we can only return once, anyway). Instead, rely on
the underlying reader to return EOF or the error again.
- Fixes #174.
|
|
- The correct header is "-----BEGIN PGP SIGNATURE-----", not
"-----BEGIN SIGNATURE-----".
|
|
|
|
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
- The AEAD implementation did not correctly handle messages where
the last chunk was a bit smaller than the chunk size.
Specifically, assume that the chunk size is 32 bytes and the
digest size is 16 bytes, and consider a message with 17 bytes of
data. That message will be encrypted as follows:
[ chunk1 ][ tag1 ][ tagF ]
17B 16B 16B
If we read a chunk and a digest, we'll successfully read 48
bytes of data. Unfortunately, we'll have over read: the
last 15 bytes are from the final tag.
To correctly handle this case, we have to make sure that
there are at least a tag worth of bytes left over when we
read a chunk and a tag.
- Test encrypting and decrypting more message sizes using AEAD.
- Also, check that the AEAD implementation correctly handles
corruption (specifically, a corrupted final tag).
|
|
- A correct AEAD implementation ensures that the final tag is
correct (currently we don't see issue #346). When doing a trial
decryption of a single chunk, we need to provide more than a
single chunk of data to the decryptor otherwise it might think the
file reached EOF and assume the chunk was a partial chunk, and
then the AEAD tags won't match.
|
