Age | Commit message (Collapse) | Author |
|
- This way, only the leaf package has to concern itself with the
selection of a cryptographic backend for Sequoia. Notably, we
don't have to repeat all of sequoia-openpgp's features in all
crates that use sequoia-openpgp.
- Enable the new feature resolver which allows for this method.
- A complication arises because we want to make `cargo test` work by
default for the intermediate crates without developers having to
select a cryptographic backend. To make that work, we implicitly
select a backend in the dev dependencies which are enabled when
compiling the tests. To make it even more convenient, we select
the most convenient backend, which is CNG for Windows and Nettle,
our default, for every other platform.
- Now that we have implicitly selected CNG on Windows for running
the tests, when the user wants to use Nettle on Windows, and does
`cargo test --features sequoia-openpgp/crypto-nettle`, then two
backends are selected: the implicitly selected CNG and the
explicitly selected Nettle. In this case, we detect that an
implicit selection has been made, and ignore the implicitly
selected backend. Now, this has already been compiled by
cargo (remember that we cannot influence the set of dependencies
at the time the build script is run), but we can still ignore the
implicit backend using conditional compilation (i.e. it will not
be included in the resulting binary). The same happens on
non-Windows platforms where Nettle is the implicit default for
tests when the user explicitly requests a different backend. In
both cases, Nettle and CNG are slim wrappers around native
libraries, so the wasted compilation time is low.
|
|
- Remove the general-purpose ffi crates. They will be moved into
their own repository. Note that we consider general-purpose ffi
crates to be a dead end: exposing Sequoia's interface requires a
large number of types and functions, and using the interface from
C turned out to be verbose and error-prone. Instead, we prefer to
write point solutions in Rust that implement exactly the
functionality the downstream consumer needs, then expose this via
ffi bindings.
- See https://gitlab.com/sequoia-pgp/sequoia-ffi.
|
|
- The store has never been really used, and never reached a maturity
where it was useful. And, we're on the verge of replacing it with
the Shared PGP Certificate Directory.
|
|
- From this point on, the crate sequoia-sqv will be maintained in
its own repository.
|
|
- This moves all functionality from sequoia_core crate as an inner
`core` module of the ipc crate.
- The `core` module has to be public as other crates depend on
`core::Context` either directly (store, ffi) or indirectly (store
through ffi crate).
- Remove the `core` crate completely.
|
|
- From this point on, the crate sequoia-sop will be maintained in
its own repository.
|
|
|
|
This runs into surprising interactions when trying to build member
packages with other than default feature set.
See https://gitlab.com/sequoia-pgp/sequoia/-/issues/575 for more info.
|
|
|
|
|
|
|
|
- This adds a new frontend to Sequoia that implements the Stateless
OpenPGP Command Line Interface.
- Compared to sq, sop has a much smaller feature set and hence a
smaller set of dependencies. It is less opinionated, and tries to
faithfully implement the SOP protocol. We will use it to test
Sequoia using the OpenPGP Interoperability Test Suite.
|
|
|
|
|
|
|
|
- Move the autocrypt-related functionality to a new crate.
- Fixes #424.
|
|
|
|
|
|
|
|
|
|
|
|
- The rfc2822 crate doesn't implement all of RFC 2822. Moreover, it
includes a number of extensions. This makes rfc2822 a misnomer.
- RFC 2822 is actually obsoleted by RFC 5322. This means that if we
ever add support for RFC 5322, it will be an even worse misnomer.
- Move the whole crate into the openpgp crate. Note: we don't
directly export the API; it is only used internally by
packet::userid.
- Closes #279.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Also bump rfc2822 to 0.6.0. After all, we create tags for the
versions.
|
|
- An RFC 2882 mail name-addr parser.
|
|
|
|
|
|
|
|
|
|
- This creates a new crate, 'sequoia-openpgp-ffi', and moves a
handful of functions from 'sequoia-ffi' to it.
- The 'sequoia-ffi' crate is a superset of the 'sequoia-openpgp-ffi'
crate. This is accomplished by some include! magic.
- My first attempt involved having 'sequoia-ffi' depend on
'sequoia-openpgp-ffi', so that the former just re-exports the
symbols. However, that turned out to be unreliable, and might be
not what we want, because it could also duplicate parts of Rust's
standard library.
- Fixes #144.
|
|
- This crate contains macros for Sequoia's FFI crate(s). Having it
in a separate crate means that we can share it when we split the
FFI crate into two.
- More importantly, we need a separate crate if we want to create
procedural macros.
- As first macro, this patch adds ffi_catch_abort that wraps a
function's body in a catch_unwind block, aborting on panics.
|
|
|
|
- Our previous guide published on our web site quickly bitrotted
away. This guide, however, is tested as part of Sequoia's test
suite, making sure that it stays in sync.
|
|
|
|
|
|
- This allows us to use sequoia-openpgp without compression support
reducing binary size and trusted computing base.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- A command line tool to interact with Sequoia. Useful for
debugging and development.
|
|
- Split up into six crates: buffered-reader, openpgp, sequoia-core,
sequoia-ffi, sequoia-net, and sequoia-store.
- Adjust imports accordingly.
|
|
- Use hyper for http, hyper-tls for https.
- Provide an easy constructor for the hkps pool.
- Add ffi glue.
|