keys.openpgp.orgHello world, this is the #OpenPGP #keyserver service at https://keys.openpgp.org!
This account provides a low-volume channel for updates about the service.
Hello world, this is the #OpenPGP #keyserver service at https://keys.openpgp.org tooting!
This account provides a low-volume channel for updates about the service.
feroxibHey y'all.
Just finished setting up my PGP appearance.
Verify here:
https://keys.openpgp.org/vks/v1/by-fingerprint/693DA7FA76F1D0D5EF7B22784FD295C91D2FD033
or here:
https://openpgpkey.nderl.es/openpgpkey/nderl.es/hu/fzzd5wfkthb6hd6e5r5rx4z6to8h6e1e
Testing allowed and appreciated!
feroxib
rabln#OpenPGP #SMIME
Fuer mich ist OpenPGP die richtige Wahl. Aber viele nutzen 'iOS' von Apple und haben mehr oder weniger nur die Option S/MIME, wenn es um das Verschluesseln von eMails geht.
Deshalb hier kurz der Tip fuer iOS-User. Auf volksverschluesselung.de bekommt ihr kostenlose S/MIME-Zertifikate fuer den privaten Gebrauch. Einziger Nachteil: Zum Erstellen benoetigt ihr ein Windows-System und einen Perso mit Digitalfunktion (Stichwort: AusweisApp) 😠
Fuer mich ist OpenPGP die richtige Wahl. Aber viele nutzen 'iOS' von Apple und haben mehr oder weniger nur die Option S/MIME, wenn es um das Verschluesseln von eMails geht.
Deshalb hier kurz der Tip fuer iOS-User. Auf volksverschluesselung.de bekommt ihr kostenlose S/MIME-Zertifikate fuer den privaten Gebrauch. Einziger Nachteil: Zum Erstellen benoetigt ihr ein Windows-System und einen Perso mit Digitalfunktion (Stichwort: AusweisApp) 😠
Delta Chat@triskelion
Proton Mail uses #OpenPGP standard and it is possible to send and receive encrypted messages between Delta Chat and Proton Mail. It is not straightforward currently but we work on making it easier by allowing to share the keys in vCards. Delta Chat cannot be used as a client for Proton Mail because Proton Mail does not allow the clients to use SMTP and IMAP to directly access mailboxes.
Tuta cannot be used to send and receive encrypted e-mail because it does not support OpenPGP.
JensIch hab jetzt seit einiger Zeit die #openpgp_verschlüsselung in #thunderbird eingerichtet. Ich habe noch keinen gefunden, der auch verschlüsselt, also den öffentlichen Schlüssel auf einem #openpgp #schlusselserver ablegt. Macht das niemand oder muss ich auch andere Schlüsselserver hinterlegen?
daltux"The treta has been planted."
@
Sid
apt-listchanges: News
---------------------
gnupg2 (2.4.7-4) experimental; urgency=medium
The upstream GnuPG project now explicitly and deliberately diverges from
the OpenPGP standard. Debian's own workflows rely heavily on OpenPGP,
and we ship several different OpenPGP implementations, so
interoperability via standardization is a priority for the project.
While Debian still has significant dependencies on GnuPG, the version of
GnuPG shipped in Debian will default to emitting only OpenPGP-compatible
artifacts if at all possible. As of 2.4.7-4, the default
is --compliance=openpgp, and we apply several patches to ensure that
this mode is respected.
If you observe GnuPG in Debian emitting a non-OpenPGP artifact in a
scenario where a standard OpenPGP artifact is intended or expected,
please open a critical bug report in the Debian BTS.
If you want Debian's GnuPG to emit non-standardized artifacts, in line
with upstream's deliberate divergence, you can explicitly pass
--compliance=gnupg (or set the corresponding option in
~/.gnupg/gpg.conf). If you revert to compliance with upstream defaults,
do not expect the material you produce to be interoperable with other
OpenPGP implementations.
-- Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 07 Feb 2025 23:35:29 -0500
#Debian #GnuPG #GPG #OpenPGP #GNU
@
Sidapt-listchanges: News
---------------------
gnupg2 (2.4.7-4) experimental; urgency=medium
The upstream GnuPG project now explicitly and deliberately diverges from
the OpenPGP standard. Debian's own workflows rely heavily on OpenPGP,
and we ship several different OpenPGP implementations, so
interoperability via standardization is a priority for the project.
While Debian still has significant dependencies on GnuPG, the version of
GnuPG shipped in Debian will default to emitting only OpenPGP-compatible
artifacts if at all possible. As of 2.4.7-4, the default
is --compliance=openpgp, and we apply several patches to ensure that
this mode is respected.
If you observe GnuPG in Debian emitting a non-OpenPGP artifact in a
scenario where a standard OpenPGP artifact is intended or expected,
please open a critical bug report in the Debian BTS.
If you want Debian's GnuPG to emit non-standardized artifacts, in line
with upstream's deliberate divergence, you can explicitly pass
--compliance=gnupg (or set the corresponding option in
~/.gnupg/gpg.conf). If you revert to compliance with upstream defaults,
do not expect the material you produce to be interoperable with other
OpenPGP implementations.
-- Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 07 Feb 2025 23:35:29 -0500
#Debian #GnuPG #GPG #OpenPGP #GNU
🔗 David SommersethSo I've given @mailfence a very quick test on their Free tier.
That seems to be quite reasonable alternative for e-mail services. In som parts it's what I would expect @mailbox_org being. Except of one thing: Unencrypted incoming e-mails will not be stored encrypted.
Since I'm on the free tier currently, I've not tested the IMAP integration.
The weakness of #Mailfence and #Mailbox are that the PGP setup requires some efforts to happen. The "settings" panel on Mailfence is cleaner and better organized than mailbox.org, but the latter one is capable of ensuring all received e-mails are stored encrypted - regardless if it was encrypted at arrival or not.
PGP key management is still not as easy as it should be for non-tech users. "It should just happen automatically", is my stance here. It's close to being good, but you need to explicitly enable encryption on each mail you send - unless you reply to an already encrypted mail. This will confuse users and it will result in more unencrypted mails sent than intended.
Neither Mailfence nor mailbox.org will decrypt encrypted Subject fields.
I've briefly tested the WebDAV integration, which seems to work. But WebDAV is not end-to-end-encrypted, so uploaded data will not be stored in so-called "zero access" mode. This means the Mailfence people managing their servers can access and read your data. This will be the same for CalDAV/CardDAV too (calendar and contacts synching)
Mailbox.org recently announced they will upgrade their login system - which is long overdue. Their OTP setup is currently just confusing and very far from user friendly. Here Mailfence is very straight forward.
Both Mailfence and #mailbox_org still got quite a long way to provide a properly privacy enabled service. They're on a good path, but currently far from the capabilities of @protonprivacy, even on the most basic features in e-mail.
Some of you may have heard of #simplex which likes to elevate itself as "the first messenger without user-ids" ... a goal, similar to ours, of not letting the transport layer know about who talks. Only we are doing it in the email system, fully interoperable with tens of thousands of existing email servers and other #openpgp endpoints. The email system is much more than SMTP/IMAP or even openpgp btw ... there is plenty of room for radical shifts and new takes. We are just starting :)
#openpgp traditions and #signal both bind a cleartext identifier, phone number or email address, to a cryptographic key. It opens up attack vectors as the servers/orgs controlling this binding can interfere.
#deltachat avoids such cleartext identity bindings by creating random #chatmail addresses, as transport only. The cryptographic key becomes the identifier and we want it hidden from the transport layer. Only people being in end-to-end encrypted chat need to identify each other, after all.