| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
- Debian unstable currently ships regex 1.2.1 -- while we might
upgrade it to 1.3.1, sequoia-openpgp doesn't appear to actually
need anything special from 1.3.1 specifically, and just uses the
stable interface from 1.x. So this dependency can be relaxed.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
|
|
- In sq and sqv, use chrono to interface with the user.
- Fixes #341.
|
|
- RFC 4880 says that "by convention, [a User ID Packet] includes an
RFC 2822 [RFC2822] mail name-addr." This is not the actual
convention, and attempting to parse User IDs using an RFC 2822
parser means that many common User IDs cannot be parsed.
- Disparities between the actual convention and the stated
convention include:
- Neither users nor the software they use to create keys
correctly quotes User IDs:
- 'Nachname, Vorname <name@example.org>' is not valid, because
it contains an unquoted comma. It should be 'Nachname\,
Vorname <name@example.org>' or '"Nachname, Vorname"
<name@example.org>'. (The same goes for dots, single
quotes, etc.)
- 'user@example.org <user@example.org>' is not valid, because
it contains an unquoted at symbol.
- 'Bj=?utf-8?q?=C3=B6?=rn <bjoern@example.net>' is encoded
using RFC 2047, which is what RFC 2822 mandates when using
non-ASCII characters, but no OpenPGP software would decode
this User ID. In practice, everyone just uses UTF-8 (in
this case: 'Björn <bjoern@example.net>').
- There are many examples of User IDs containing raw email
addresses ('user@example.org'). But, these are not
"name-addr"s. At best, they are RFC 2822 "mailbox"es.
- Some User IDs only contain a name (e.g, "Frank PGP").
- RFC 2822 also includes a lot of complexity that no one uses or
needs. For instance, CFWS (comments and folding whitespace) can
be placed everywhere, and the rules for parsing them are
complex.
- Instead of continuing to bend the RFC 2822 parser to our will, we
instead accept reality.
- This patch replaces the RFC 2822 parser with a significantly
simpler parser, which is based on actual convention (i.e., User
IDs in the wild).
- This parser is based on dkg's mail to the OpenPGP working group
mailing list.
Message-ID: <87woe7zx7o.fsf@fifthhorseman.net>
https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI
- This initial version has one notable regression with respect to
the RFC 2822 parser: it doesn't handle User IDs holding URIs.
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
- Version 0.10.1 removes support for the base64::MIME configuration.
That means, that we have to strip whitespace on our own.
- Our implementation tries hard to not double buffer.
- Closes #280.
|
|
|
|
|
|
|
|
|
|
- 0.5.6 fixes cross-building from macOS for Android.
- Fixes #284.
|
|
- Closes #281
|
|
|
|
- Provide a function to return a normalized email address, which is
appropriate when comparing email addresses for equality.
|
|
- Don't decode base64 data that definitely can't possibly contain a
valid OpenPGP message.
|
|
- Also bump rfc2822 to 0.6.0. After all, we create tags for the
versions.
|
|
- Provide an interface to query the name, comment and email address
of RFC 2822 name-addr and addr-spec encoded User IDs.
|
|
|
|
- Fixes #24.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Using `crypto::Signer`s has several benefits. First, it shifts
the decision which key to use to the caller, moving policy out of
the caller. Second, it forces the caller to deal with encrypted
keys. Finally, it allows us to use remote keys like smart cards
in the future.
- Fixes #142.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
