wiktor

wiktor, 30 days ago

Based on their Cargo.toml (https://github.com/stalwartlabs/mail-server/blob/e10083651b4bf58d4a78c49f285efac9c5bad4e2/crates/jmap/Cargo.toml#L48) it seems they’re using experimental cryptographic backend which is not "considered mature enough for general consumption": https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?ref_type=heads#experimental-and-variable-time-cryptographic-backends

Additionally it looks like they’re not using the recommended way of importing Sequoia: https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?ref_type=heads#how-to-select-crypto-backends-in-crates

I don’t have any personal association with Stalwart but maybe it'd be a good idea to report that at https://github.com/stalwartlabs/mail-server/issues ?

👋

wiktor, 2 months ago

I thought you were a bit exaggerating but check this out: https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 (CTRL+F "Aside from its documented change")

Whitespace has been used to activate and deactivate the malware! 🤯

If only the project has been using consistent whitespace formatter this just wouldn’t pass basic checks.

wiktor, 3 months ago

Both of them really have different strengths and weaknesses:

Sequoia is definitely more feature-complete (for example it supports multiple crypto backends) but sometimes the complexity shows (e.g. selecting crypto backends https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?ref_type=heads#how-to-select-crypto-backends-in-crates or the type names: https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/amalgamation/struct.ValidComponentAmalgamationIter.html).

rpgp is basically an extension of RustCrypto, and as such is a bit more integrated in the Rust ecosystem but has been lagging a bit on compatibility until Heiko submitted a couple of PRs and now is on the top: https://tests.sequoia-pgp.org/ (rpgpie).

Glad that you like the Sequoia documentation: quite a lot of work has gone into polishing it… :)

wiktor, 7 months ago

I’ve made a couple of small apps to fill in the gap (eg. https://gitlab.com/wiktor/git-gpg-shim) and they work well for me (pass-based passwords, git commit signing) and they work but it’s definitely quite a chore to set it up.

Just recently I’ve migrated to git SSH commit signing (with per-device TPM-stored signing keys) and the experience is better out of the box (no custom tooling necessary at all).

wiktor, 7 months ago

I feel like you’re replying to a point I haven’t made (I was mentioning just commit signing where SSH works better for me) but just for the sake of the thread let me reply to your question.

Nope, SSH cannot be used for e-mails but based on what I’m seeing on the mailing lists OpenPGP won’t be usable there too soon. Or rather, OpenPGP will split into two: v5 supported by RNP (Thunderbird) and GnuPG; and v6 supported by Sequoia and OpenPGP.js (ProtonMail). And now it’s entirely conceivable that your v5 e-mails won’t be readable by, say, Sequoia’s Careful E-mail client (hypothetical example).

See: https://mailarchive.ietf.org/arch/msg/openpgp/BLgKYP9CbGtMsIJRV3Ws9jh57Tw/

wiktor, 7 months ago

Yes, I’ve read Kai’s e-mail about putting user’s first, it was very good. But consider the fact that OpenPGP facilities in Thunderbird are provided by RNP and their last known position on the matter doesn’t leave much room for interpretation: https://mailarchive.ietf.org/arch/msg/openpgp/EgILWBGqU_qvbRLLdbR3jxvMZyc/

wiktor, 1 year ago

Yep, I can totally relate. The mechanics are not well written anywhere in an easy to digest format (ping https://fosstodon.org/@hko ).

I’ll use this toot to provide info you may find useful:

OpenPGP keys (or as some call them “certificates") are in reality append-only data structures (think git repositories). You never actually "remove” anything, rather create a new thing (where the version is specified by creation time) that has properties you’re interested in. Even if you revoke User ID or a subkey in reality this only adds yet another signature with a flag that “this key is revoked now”.

There are some exceptions… or rather edge cases… if you never publish a piece of data you can totally remove that locally and it would be as if it has never existed (think git rebase is OK on not published commits) also some newer keyservers such as https://keys.openpgp.org allow selective User ID publishing (so you can remove User ID from their copy). Of course removing User ID there would do nothing to copies of your key you (or others) store elsewhere.

HTH 👋

wiktor, 1 year ago

That would mean all these commits would become “unverified” and would show verification errors when someone would try to do that. In reality probably it wouldn’t have any bigger impact anyway.

I suggest replacing your entire key only when you want to change cryptography of the primary key (say you were using DSA) or security of the primary key private key material (say you generated in a shared computer but since then started to wear tinfoil hat and only offline, airgapped machine is OK).

And that’s I think it, everything else can just be achieved by amending what you already have. (Just skimming this thread and I don’t see anything, even changing primary key from [SC] to [C] is possible afterwards: https://unix.stackexchange.com/a/707006).

wiktor, 1 year ago

Hmm… that’s interesting. SM-collection of algorithms are government cryptographic standards so I guess it implies that there are some people in Chinese government that use OpenPGP. This is similar to Brainpool for some EU countries. It also means that we probably won’t know the real users since it’s top secret or something 🤷