| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- individual jobs for sequoia-ipc, sequoia-store, as they are the
interesing ones
|
|
|
|
|
|
|
|
- sq keyserver get expects a fingerprint or keyid, but only ever used
the keyhandle parsed as a fingerprint. Fix this by parsing as a
KeyHandle, instead.
- Found with clippy lint if_same_then_else:
https://rust-lang.github.io/rust-clippy/master/index.html#if_same_then_else
|
|
KeyHandle::is_invalid
|
|
- Fixes #570.
|
|
- This is used by the Rust Crypto crates.
|
|
|
|
|
|
- Fixes #769.
|
|
- Fixes a bug where subplot picks up the wrong binary by mistake.
|
|
|
|
|
|
|
|
- With this patch, Sequoia's armor encoding and decoding performance
roughly matches GnuPG's.
- Fixes #772.
|
|
|
|
|
|
- Instead of encrypting and emitting ciphertext block-wise, encrypt
all whole blocks at once and emit the resulting ciphertext. This
saves invocations of the cipher (which may traverse language
boundaries), and reduces the overhead later in the writer stack by
writing larger chunks.
|
|
- When we stream packet bodies, we hash their contents so that we
can compare them later on, even if we no longer have the data.
Previously, we used the fasted hash from the SHA2 family, either
SHA256 or SHA512 depending on the architecture.
- That, however, turned out to be a major performance problem. When
decrypting a non-compressed, binary file on amd64, we spent
roughly a third of the time just to compute the hash.
- Using the non-cryptographic hash function XXH3, we can greatly
improve the performance. On my system, it is 30x as fast as SHA3,
and reduces the overhead of computing the body hash considerably:
% time ./sq-sha512 decrypt --recipient-key juliet.key.pgp 3g-for-juliet.binary.pgp >/dev/null 2>&1
13.931 total
% time ./sq-xxh3 decrypt --recipient-key juliet.key.pgp 3g-for-juliet.binary.pgp >/dev/null 2>&1
9.264 total
- See #771.
|
|
- Previously, for a read of X bytes, we'd request X + buffer_size
from the underlying buffered reader, then satisfy the read
request, after which we'd request the next X + buffer_size bytes
for the next read. This requires the underlying reader to copy
buffer_size bytes for each read. In a typical scenario, we'd copy
25 megabytes (the default buffer size) for every 8 kilobytes
read (std::io::copy's default buffer size). This incurs a linear
cost with a very high factor.
- Improve this by requesting 2 * buffer_size, then satisfying the
reads from the first half of that buffer, only consuming the first
half once we have exhausted the first half. Then, we'd request
the next 2 * buffer_size, at which point the underlying buffered
reader has to copy the data to a new buffer.
- See #771.
|
|
|
|
- Previously, when the read exceeded the buffered data, we tried to
fill the buffer even if we reached the last chunk. Then, we would
allocate a new buffer and copy the data over, only to later
realize that we reached the last chunk and the current chunk is
exhausted.
|
|
- If the opportunity arises, i.e. we have a buffer but previous
reads exhausted it, we can drop the buffer and serve the requests
from the next buffered reader without copying them first.
|
|
- Previously, we spent a considerable amount of time callocing new
buffers.
|
|
- Previously, we spent a considerable amount of time callocing new
buffers.
|
|
- Fixes #773.
|
|
|
|
|
|
|
|
- If certificates contain secret keys try to decrypt the in place.
- If certificates contain only public bits and the private key store
has been set try to decrypt it using the sequoia_net::pks functions.
|
|
- Extend the decrypt and sign operations with private-key-store
parameter.
- Reduce the number of parameters by using wrapper structs.
|
|
- Add sequoia_net::pks::unlock_signer.
- Add sequoia_net::pks::unlock_decryptor.
|
|
|
|
|
|
Add support for an integration and acceptance test suite using the
Subplot tool (https://subplot.liw.fi/). There are the initial, very
simple test scenarios, to get us started. The goal is to introduce the
scaffolding for integration tests, so that further tests can be added
with ease later.
The tests are documented and defined in sq-subplot.md. In build.rs, we
call Subplot to generate test code from the markdown file. The tests
are run via "cargo test", as usual.
Subplot can also generate a typeset test document from sq-subplot.md,
but we don't do that here.
|
|
- net: hyper has two vulnerabilities:
- RUSTSEC-2021-0079: "Integer overflow in `hyper`'s parsing of the
`Transfer-Encoding` header leads to data loss" (vulnerability)
- RUSTSEC-2021-0078: "Lenient `hyper` header parsing of
`Content-Length` could allow request smuggling" (vulnerability)
Both are fixed in hyper 0.14.10., which depends on tokio 1. tokio
0.2 is incompatible to tokio 1, so we need to update that too, also
in the dependents sq and ffi.
hyper-tls 0.4 is incompatible to hyper 0.14., update to hyper-tls
0.5.
|
|
- The new 1.56.0 compiler has started issuing a new warning: "trailing
semicolon in macro used in expression position", which will be an
error in a future release.
- For more information, see https://github.com/rust-lang/rust/issues/79813
|
|
- Closes #476.
|
|
|
|
|
|
- Change Sequoia's license from GPL 2.0 or later to LGPL 2.0 or
later as unanimously decided on October 18, 2021 by:
- Christof Wahl <cw@pep.security> (pEp security CEO)
- Heiko Schaefer <heiko.schaefer@posteo.de> (pEp Foundation
employee, Sequoia developer)
- Justus Winter <justus@sequoia-pgp.org> (pEp Foundation
employee, Sequoia Founder)
- Neal H. Walfield <neal@pep.foundation> (pEp Foundation
employee, Sequoia Founder)
- Patrick Meier <pm@pep.security> (pEp security Chief Product
and Service Officer)
- Rudolf Bohli <rb@pep.security> (pEp security Chairman of the
Board)
- Volker Birk <vb@pep.security> (pEp security Founder, pEp
Foundation Council)
|
|
The output keyring now has keys in fingerprint order.
Closes #762
|
|
This amends the "rust-stable" pipeline to build with stable rust (from
rustup), then unset the override to use stable, which means the
rust-toolchain file is obeyed. It then installs clippy, and runs it.
|
|
Replacing the closure with just the value it returns would be simpler,
but it would result in more computation happening at runtime if the
result is Ok.
See
https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_lazy_evaluations
This clippy warning wasn't caught by CI, because we don't yet have
clippy in CI.
|
|
|
|
|
|
|
|
|
