« encrypted “emails” within Tuta, which cannot extend beyond their walled garden, are not really emails at all: they are encrypted messages using a proprietary format »
@thunderbird Better to take some more time to prepare a proper release – looking forward to it and kudos for keeping Thunderbird on @fdroidorg.
Still, any news about future encryption options, especially via #OpenPGP? Pretty much all #Android email clients rely on #Openkeychain to manage all your keys. Sadly it is still unmaintained and desperately needs a replacement or someone to take over development. Look at issues like this: https://github.com/open-keychain/open-keychain/issues/2856 #Thunderbird for Android will also rely on this unmaintained app.
「 The major implementers of the OpenPGP standard as specified by RFC-4880 came together and agreed that the planned updates of the IETF to RFC-4880 are harmful for the existing deployment of OpenPGP software. The majority of its users are expecting long-term stability and a real world focus instead of disruptive changes as recently been proposed [by] the IETF OpenPGP working group#Cybersecurity 」
1/ 🎉 Big news in the #OpenPGP world! Our team's labor of love, "OpenPGP for Application Developers," is now live! Check it out: https://openpgp.dev/. 🚀📚 Our mission? Make OpenPGP accessible, enjoyable, and a go-to tool for devs! #cryptography#security
4/ 📣 Join us in refining and expanding “OpenPGP for Application Developers”! Open-source at heart! Developed on https://codeberg.org/openpgp/notes/ and shared under CC-BY-SA-4.0. We'd love your insights! Let's collaborate and grow the #OpenPGP#cryptography ecosystem together!
Exciting news for #OpenPGP enthusiasts and learners! 🚀 "OpenPGP for Application Developers" is now live! 📘 Whether you're a seasoned pro or just starting, learn the best ways to add OpenPGP into your development toolkit. #cryptography#security 🌐🔐
Following funky usage of OpenPGP, I found a user using GitHub gist to send encrypted messages. The keyid is the correlation value from an AIL project instance.
However, in my case, I'm using my #OpenPGP setup also for #mutt email workflows and file encryption outside of Emacs. With that, I do have some advantages when using only one encryption keyring from #gnupg.
YMMV
If there would be an Emacs-specific alternative, I'd still switch to it I guess. (Depends on the implementation details.)
The project leader of #gnupg has announced a fork of the #openpgp standard, justifying it with a list of accusations against the #IETF working group that fall apart under scrutiny. #pgp is being threatened with destruction over a personal grievance. We strongly urge de-escalation.
The pgpkeys.eu test swarm (a set of four containerised hockeypuck keyservers) is now running the hockeypuck 2.2 development branch, to test eventual consistency. Waiting to see if they will stabilise overnight. 🤞
Hockeypuck 2.2 will include several updates:
drop support for deprecated algorithms (and therefore sync compatibility with sks-keyserver)
Dropping sks-keyserver backwards compatibility should get rid of several long-running sync issues. Hockeypuck validates self-sigs but sks-keyserver does not, and maintaining sync consistency with sks-keyserver means storing and propagating unverifiable self-sigs made with unsupported algorithms (in particular elGamal/RSA encrypt-and-sign, which are long deprecated). This has never worked reliably, and sks-keyserver compatibility is no longer a priority for the keyserver operators. Removing this support also significantly simplifies the code.
Dropping support for images will reduce the storage footprint of a keyserver, and will eliminate an obvious abuse vector.
Hard (i.e. retrospective) revocation of a key (e.g. by publishing the revocation certificate saved at key generation time) will cause all User IDs attached to that key to be deleted. This allows key owners to remove their personal information from the entire keyserver network without having to contact individual operators (which can still be done, your rights are not affected).
The timestamp-aware merge strategy will allow key owners to remove spammy third-party signatures from their published key by creating a fresh self-signature (e.g. by updating the expiry date) and republishing. This works similarly to attestation signatures, but is compatible with clients that don’t yet support attestations.
v5 (GnuPG) and v6 (RFC9760?) signatures will soon start appearing in the wild. Several changes will need to be made in the codebase to enable support to be added in the future.
These vital developments will help keep the #openpgp keyserver network stable, relevant, and compliant, into the foreseeable future.
#Encrypted notification #emails are going away on December 5. This means that, soon, emails you receive from Facebook will no longer be encrypted.
If you have previously set up a #PublicKey, you can still view it under settings on Facebook (or in the Accounts Center under Password and security) until December 5.
I haven't been very good with posting/writing about what I'm working on, so here's a 1,200+ word post about how we replaced[1] the GPG code backed by a library aptly called "pretty-bad-protocol" with a Rust library named after trees, Sequoia-OpenPGP.
This is the first written-here Rust code that will be shipped by SecureDrop \o/
#openpgp#gpg#gnupg Does anyone know if there is any sort of plugin you can enable for mastodon that will attempt to automatically verify signed fediverse posts?
Or if not something right in mastodon server. . . maybe a browser plugin that runs locally? That might even be more secure.
We released version 1.17.0 of sequoia-openpgp! It includes new fuzzing infrastructure, a secret key leak detector, and integration with sequoia git, which enforces a signing policy. Read our release announcement for more details.