summaryrefslogtreecommitdiffstats
path: root/openpgp/src/packet/userid/mod.rs
AgeCommit message (Collapse)Author
2019-11-25OpenPGP User ID convention is "de facto" not "de factor"Daniel Kahn Gillmor
I'm not even sure if we even need to use "de facto" when we're also saying "convention", but i'm just doing a targeted fix here. The fact that this one string was copied around in a dozen places makes me a bit sad. If there are other changes to make in this boilerplate text, they'll also have to be made in a dozen places. I don't know enough about how sequoia is designed to be able to suggest a plausible boilerplate reduction strategy though. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-11-25openpgp: Fix regular expression.Neal H. Walfield
- A non-capture group is indicated by '?:', not ':?'.
2019-11-21openpgp: When parsing User IDs, recognize URIs.Neal H. Walfield
- Restore the functionality removed in 8693a005 when replacing the RFC 2822 mailbox parser.
2019-11-18Fix more spellingDaniel Kahn Gillmor
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-11-06openpgp: Replace RFC 2822 parser with a de factor parserNeal H. Walfield
- 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.
2019-10-25rfc2822,openpgp: Move rfc2822 crate to be a private mod in openpgpNeal H. Walfield
- 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.