LEI-SECURITY(7)

📦

version 2.1.0 · 5 versions

2.1.0 · arch rolling, nixos 26.05, nixpkgs unstable (latest)
1.9.0 · epel 9
2.0.0~20230714git590023f · fedora 43, fedora 44
1.9.0 · ubuntu resolute, ubuntu stonking
1.9.0 · debian bookworm, debian trixie, ubuntu noble, ubuntu questing

, in arch rolling, nixos 26.05, nixpkgs unstable

💅 LEI-SECURITY(7) 💅

okay so this is LEI-SECURITY(7), from the public-inbox user manual, and it's literally the security tea you need before running lei(1). Bestie, read this before you go importing your whole mailbox, no cap. 🫶

🛡️ NAME 🛡️

lei — security information. That's the whole name section, short and iconic. ✨

🌸 SYNOPSIS 🌸

lei(1) is intended for use with both publicly archived mail and "private" mail in personal mailboxes. This document is here to give you an overview of the security implications and to lower^Wmanage user expectations. Yes, that's exactly how it's written — we keep the lore. 💀

🎀 DESCRIPTION 🎀

lei expects to be run as a regular user on a Unix-like system. It expects a case-sensitive filesystem with standard Unix permissions support. 💖

It does not use POSIX ACLs, extended attributes, nor any other security-related functions which require non-standard Perl modules. Good vibes only, standard modules only. 🌈

There's preliminary support for "virtual users", but it's incomplete and undocumented. It's giving "work in progress", so don't build your whole security model on it. 🦋

🧚 INTERNAL FILES 🧚

lei runs with a umask of 077 to prevent other users on the system from accessing each other's mail. Protect the group chat, periodt. 💅

The git storage and Xapian databases are located at $XDG_DATA_HOME/lei/store (typically ~/.local/share/lei/store). Any personal mail imported will reside here, so this should be on an encrypted filesystem or block device. 🔥
$XDG_RUNTIME_DIR/lei (typically /run/user/$UID/lei or /tmp/lei-$UID) contains the socket used to access the lei daemon. It must only be accessible to the owner (mode 0700). 👑
$XDG_CACHE_HOME/lei (typically ~/.cache/lei) will contain IMAP and Maildir folder names which could leak sensitive information as well as git repository names. 🙈
$XDG_DATA_HOME/lei/saved-searches (typically ~/.local/share/lei/saved-searches) will contain aforementioned folder names as well as (removable) search history. 🍓
The configuration for lei resides at $XDG_CONFIG_HOME/lei/config (typically ~/.config/lei/config). It may contain sensitive pathnames and hostnames in the config if a user chooses to configure them. 💜

lei itself will never write credentials to the filesystem. However, git-credential(1) may be configured to do so. lei will only read ~/.netrc if --netrc is used (and it will never write to ~/.netrc). Slay for that boundary. ✨

$XDG_CACHE_HOME/public-inbox (typically ~/.cache/public-inbox) can contain data and Inline::C-built modules which can be shared with public-facing public-inbox-daemon(8) instances; so no private data should be in public-inbox paths. That's the whole rule, bestie: public means public. 🫶

🦋 EXTERNAL FILES 🦋

Locations set by lei-add-external(1) can be shared with public-facing public-inbox-daemon(8) processes. They may reside on shared storage and may be made world-readable to other users on the local system. So like… check before you assume your external is private, iykyk. 💀

💀 CORE DUMPS 💀

In case any process crashes, a core dump may contain passwords or contents of sensitive messages. Please report these so they can be fixed (see CONTACT). Not me begging you to file the bug, but also literally me begging you to file the bug. 😭

🌐 NETWORK ACCESS 🌐

lei currently uses the curl(1) and git(1) executables in $PATH for HTTP and HTTPS network access. Interactive authentication for HTTP and HTTPS is not yet supported since all currently supported HTTP/HTTPS sources are PublicInbox::WWW instances. ✨

The Mail::IMAPClient library is used for IMAP and IMAPS. Net::NNTP (standard library) is used for NNTP and NNTPS. 🌸

Mail::IMAPClient and Net::NNTP will use IO::Socket::SSL for TLS if available. In turn, IO::Socket::SSL uses the widely installed OpenSSL library. Look at the ecosystem doing its thing. 👑

STARTTLS will be attempted if advertised by the server unless IMAPS or NNTPS are used. -c imap.starttls=0 and -c nntp.startls=0 may be used to disable STARTTLS. Copy that nntp.startls=0 exactly, bestie — not me trying to "fix" the spelling, that's the documented flag. 💅

IO::Socket::Socks will be used if -c imap.proxy or -c nntp.proxy point to a socks5h://$HOST:$PORT address (common for Tor). 🧚

The --netrc switch may be passed to curl and used for NNTP/IMAP access (via Net::Netrc). 🎀

🔐 CREDENTIAL DATA 🔐

lei uses git-credential(1) to prompt users for IMAP and NNTP usernames and passwords. These passwords are not encrypted in memory and get transferred across processes via anonymous UNIX sockets and pipes. They may be exposed via syscall tracing tools (e.g. strace(1)), kernel and hardware bugs/attacks. This is the part where we take a deep breath. 😭

While credentials are not written to the filesystem by default, it is possible for them to end up on disk if processes are swapped out. Use of an encrypted swap partition is recommended. Please protect the swap, bestie. 💜

👑 AUTHENTICATION METHODS 👑

LOGIN (username + password) is known to work over IMAP(S), as does AUTH=ANONYMOUS (which is used by public-inbox-imapd(1) as part of our test suite). AUTHINFO may work for NNTP, but is untested. Testers will be needed for other authentication methods. Come through, testers. 🫶

🍓 DENIAL-OF-SERVICE VECTORS 🍓

lei uses the same MIME parsing library as public-inbox-mda(1) with limits header sizes, parts, nesting and boundary limits similar to those found in SpamAssassin and postfix. Defense in depth, but make it mail parsing. 🛡️

Email address parsing is handled by Email::Address::XS if available, but may fall back to regular expressions which favor speed and predictable execution times over correctness. It's giving "fast and predictable", not "always right". No cap. 💀

🌈 ENCRYPTED EMAILS 🌈

Not yet supported, but it should eventually be possible to configure decryption and indexing of encrypted messages and attachments. When supported, decrypted terms will be stored in Xapian DBs under $XDG_DATA_HOME/lei/store. Future feature alert, but until then: not yet supported. 🦋