Age | Commit message (Collapse) | Author |
|
|
|
- Closes #767.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
- cargo deadlinks does not like name="foo" anchors, but id="foo"
fragments are fine. Functionally, there is no difference for the
site's user.
|
|
|
|
|
|
|
|
|
|
|
|
- RUSTSEC-2021-0115: #[zeroize(drop)] doesn't implement Drop for enums
(vulnerability)
- The zerioize_derive team released 1.1.1, which fixes this and keeps
the MSRV <= 1.48.
- Fixes #764.
|
|
- RUSTSEC-2021-0093: Data race in crossbeam-deque (vulnerability)
- Patched: >=0.7.4, <0.8.0 and >=0.8.1
|
|
- Remove explicit dependency on unicode-normalization. It was added in
2a19afb8 to pin the crate to a version that has a low enough MSRV.
The pin was removed in 742eac41, but the explicit dependency wasn't.
|
|
|
|
|
|
|
|
Reported by: Jörg Knobloch <jorgk@jorgk.com>.
|
|
|
|
|
|
- This adds a cryptographic backend based on the RustCrypto crates.
The backend is marked as experimental, as the RustCrypto crates'
authors state that they have not been audited and may not perform
computations in constant time. Nevertheless, it may be useful in
certain environments, e.g. WebAssembly.
- The backend implements RSA, EdDSA and ECDH over Curve25519, IDEA,
3DES, CAST5, Blowfish, AES, Twofish, EAX, MD5, SHA1, RipeMD160, and
the SHA2 family.
- Notably missing are DSA, ElGamal, and ECDSA and ECDH over the NIST
curves.
- See #333.
|
|
|
|
|
|
- r is a mem::Protected, no need to explicitly clean it up.
|
|
|
|
This reverts commit 666c5731e5c705bc85007625524bf93a41994ee9.
|
|
See https://rust-lang.github.io/rust-clippy/master/index.html#single_match
|
|
See
https://rust-lang.github.io/rust-clippy/master/index.html#redundant_pattern_matching
|
|
Instead of:
if text.starts_with(prefix) {
&text[prefix.len()..]
} else {
&text
}
use this:
if let Some(rest) = text.strip_prefix(prefix) {
rest
} else {
&text
}
The strip_prefix is easier to understand, and also removes the
dependency between the if condition and the computation to get the
slice after the prefix. The dependency is reasonably clear, but the
compiler does not understand it so it's plausible that a future change
might change the condition but not the slice. The approach using
strip_prefix avoids that.
This was found by the clippy lint manual_strip:
https://rust-lang.github.io/rust-clippy/master/index.html#manual_strip
|
|
A chain of if statements is not guaranteed to test every possible
case, the way match does. Thus it seems better to use match here, when
there are three possible results from a comparison.
Found by clippy lint comparison_chain:
https://rust-lang.github.io/rust-clippy/master/index.html#comparison_chain
|
|
We should arguably use a different approach, but I don't understand
the code enough to suggest how.
Found by clippy lint transmute_ptr_to_ptr:
https://rust-lang.github.io/rust-clippy/master/index.html#transmute_ptr_to_ptr
|
|
We have two loops where the last statement is a return or a break,
without there being a continue. This means the loops will never loop.
This is a symptom of the code being hard to understand. We should
probably rewrite the logic without a loop, but I did not feel
confident doing that yet.
Found by clippy lint never_loop:
https://rust-lang.github.io/rust-clippy/master/index.html#never_loop
|
|
A complex type without a name tends to be harder to understand. We
have a few of them. Using "type" to give them a name would hopefully
help, but I don't understand the code well enough to come up with
meaningful names, and meaningless names won't help. Also, arguably, a
struct or enum would often be the better approach, but would change
the API. Thus, I'm only configuring clippy to allow complex types. We
should later revisit this and improve the code, when we're making
other API changes anyway.
Found by clippy lint type_complexity:
https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity
|
|
By default, clippy allows up to seven arguments to a function.
Anything more and it will complain.
https://rust-lang.github.io/rust-clippy/master/index.html#too_many_arguments
Seven is already a very large number. However, changing the number of
arguments in public functions would change the API of the library, so
I've upped the limit to ten, which is enough to placate clippy.
Arguably, when we are changing the API anyway, we should consider ways
to remove the number of arguments to functions, possibly by using the
builder pattern.
|
|
Generally speaking, single-character names are not great for the
person reading the code later. They don't usually act as a cognitive
aid to understand the code. However, this in code implementing
cryptographic operations that implements mathematical formulas that
canonically use single-letter names it's clearer to use the same name
in the code. Thus, I only tell clippy those names are OK in these
cases.
Found by clippy lint many_single_char_names:
https://rust-lang.github.io/rust-clippy/master/index.html#many_single_char_names
|
|
clippy warns if one of the variants of an enum is significantly larger
than the others, as that can cause surprising memory use: an enum uses
as much space as its largest variant. We have some such enums, but
changing them to have variants of similar size would change the API so
I've chosen to allow variants up to 512 bytes.
Found by clippy lint large_enum_variant:
https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant
|
|
An if condition is an expression and can be as complex as the
programmer wants. However, the more complex a condition is, the harder
it tends to be to understand. I marked functions with such if
conditions so that clippy won't complain about the code. I probably
should have simplified the code, perhaps by extracting the condition
to its own function, but it would have been much harder to do, so I
didn't.
Found by clippy lint blocks_in_if_conditions:
https://rust-lang.github.io/rust-clippy/master/index.html#blocks_in_if_conditions
|