#sequoiapgp — Public Fediverse posts

@simontatham I agree in principle, but sometimes "new and improved" really is better.

Often, even when it's time to change the foundations, it's possible to keep the old façade as a compatibility layer, as #SequoiaPGP has done with chameleon, https://debconf24.debconf.org/talks/16-chameleon-the-easy-way-to-try-out-sequoia-openpgp-written-in-rust/

We have a long way ahead of us before PQC-resilient #OpenPGP smartcards are available for the normal user. Does #sequoiapgp plan to support the combination of currently available smartcards with PQC-keys stored on disk, similar to what GnuPG offers?
https://lists.gnupg.org/pipermail/gnupg-users/2025-May/067602.html

@kushal My OpenPGP private key ist stored on my two Yubikeys. I always sign with GnuPG when I commit with git. And, I check my release tarballs and zip files before I sign them:
https://codeberg.org/duxsco/gentoo-installation/src/branch/main/assets/check_sign_release.sh

I publish information on how to fetch my public key:
https://www.duxsco.de/my_openpgp_public_key/

I’d love to use only sequoia-pgp, but I think this will not happen in the foreseeable future due to the use of rust and the difficulties to package sequoia-keystore due to that:
https://bugs.gentoo.org/965482

#gnupg #sequoiapgp

Por lo visto las claves generadas por Proton añaden a los datos de identidad el correo sin respetar los guiones y los puntos del usuario (pero no del dominio) a las claves disponibles en su servidor.

Es decir, si mi dirección es "[email protected]" o "[email protected]", la clave PGP tendrá asociada "[email protected]". Y si el correo asociado a la llave pública y la del destinatario no coinciden, otros clientes PGP se negarán a usarla.

En otras palabras: generad vuestras *propias claves*. Proton sigue permitiendo subir a sus servidores claves autogeneradas btw.

#Proton #OpenPGP #GPG #OpenKeychain #SequoiaPGP #Mozilla #Thunderbird

Also, here's a recording of the demo showing a successful #PQC signature: https://youtu.be/svtu1yJpfEg

#FOSDEM #fosdem2026 #distributions #RPM #Sequoia #SequoiaPGP #PKCS11

A lot of us have have been complaining about GnuPG for years but https://gpg.fail/ takes no prisoners on all sides🔥

#39c3 #gnupg #gpgfail #sequoiapgp

@iuvi @GnuPG

if Kyber also available in Kleopatra? Thanks

IMHO below:

Who cares? It's often said that the videotape format war and the high-definition optical disc format war were won by whatever the porn industry favoured. I don't know whether this claim about video format wars is true, but I would argue that the LibrePGP vs. RFC 9580 "war" will be won by whatever is favoured by the predominant public key distribution platform.

Currently, that platform is https://keys.openpgp.org which I don't expect to support LibrePGP anytime soon, because it relies on sequoia-openpgp which I don't expect to support the RFC behind LibrePGP as long as it's just an Active Internet-Draft. At least, Sequoia-PGP supported RFC 9580 after it was released in July 2024 (link). So, why should they handle LibrePGP any differently? tbh, even if the RFC behind LibrePGP has the status of a "RFC - Proposed Standard" which I expect it to never get, I don't think Sequoia-PGP will support it.

I for once will rotate my keypair and opt for Sequoia-PGP once this Gentoo bug has been solved. My reasons:

1. I expect for RFC 9580 to remain favoured on the predominant public key platform.
2. I cannot rely on the GnuPG manpage (link).

#GnuPG #sequoiapgp

@Velocifyer @andrewg That's the reason for my plans to switch from #GnuPG to #sequoiapgp, not the #LibrePGP vs #RFC9580 mess. If a RTFM doesn't suffice and it comes down to RTFC (...Code), I am out.

See GnuPG manpage:

❯ gpg --version | head -n 1
gpg (GnuPG) 2.5.13
❯ man gpg | sed -n '/^[[:space:]]*dane/,/^$/p'
              dane   Locate a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt.

... and:

The lookup result MUST pass DNSSEC validation; if validation reaches any state other than "Secure", the verification MUST be treated as a failure.

Source: https://datatracker.ietf.org/doc/html/draft-ietf-dane-openpgpkey-05#section-5

🤚 Free Saturday
👉 Saturday spent working on Free Software

Highlights from #Gentoo:
• #Gemato is now compatible with #FreePG and mostly compatible with #SequoiaPGP chameleon.
• Prepared patches to support FreePG and SequoiaPGP chameleon as "gpg" symlink providers.
• #FlexiBLAS is now enabled by default on ~arch.
• Finally finished working on #PkgCheck check for missing #PyPI provenance checks.
• gpy-list-pkg-impls now includes "does this package have tests?" state, can optionally include PythonCompatUpdate results from PkgCheck and output mIRC colors. In other words, our IRC bot will now tell us when dependencies let us port new packages to #Python 3.14, and whether these packages have tests.

🤚 Wolna sobota
👉 Sobota z pracą nad Wolnym Oprogramowaniem

Nowości w #Gentoo:
• #Gemato wspiera #FreePG i w większości #SequoiaPGP chameleon.
• Przygotowałem wsparcie FreePG i SequoiaPGP chameleon jako dostawców "gpg".
• #FlexiBLAS jest teraz używany domyślnie w ~arch.
• W końcu dokończyłem sprawdzanie nieużywanych podpisów paczek #PyPI w #PkgCheck.
• gpy-list-pkg-impls teraz uwzględnia "czy ta paczka ma testy?", może opcjonalnie włączać wyniki PythonCompatUpdate z PkgCheck i stosować kolorki mIRC-a. Innymi słowy, nasz bot IRC-owy będzie podpowiadał nam, kiedy zależności będą umożliwiać portowanie kolejnych paczek na Pythona 3.14, i czy te paczki mają testy.

Observation. When using symmetric (password) encryption on files, #GPG is MUCH faster then #SequoiaPGP, at least when using the default CLI interface for each utility on Debian.

No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.

Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.

Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.

Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.

https://bugs.gentoo.org/963069

Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.

So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.

Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.

So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".

https://bugs.gentoo.org/963069

@ber @fasnix @Tutanota @mailbox_org @delta @lennybacon

#OpenPGP darf nicht verschwinden. Ich werde aber zu #SequoiaPGP wechseln, sobald es von Haus aus Smartcards unterstützt.

Bei #GnuPG fühle ich mich nach LibrePGP&RFC9580 nicht mehr wohl.

Auch mag ich das Vorgehen vom GnuPGP bzgl. DANE nicht. Denn es wurde eine RFC (auch wenn es experimentell ist) nicht komplett umsetzt. Dann soll man erst garnicht mit der Implementierung von DANE in GnuPG anfangen oder zumindest die Implementierung in der Manpage als unvollständig hervorheben:

• Statement von Werner: https://dev.gnupg.org/T4618#135528
• Anforderung aus RFC 7929, die von GnuPG ingnoriert wurde:

The DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than "Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be treated as a failure.

Quelle: https://datatracker.ietf.org/doc/html/rfc7929#section-5

Sequoia PGP hat zumindest DANE nicht halbgar implementiert:
https://gitlab.com/sequoia-pgp/sequoia/-/blob/0b60b92482f3ea183385a9cf4751a1aca46457ea/net/src/dane.rs#L52-53

apt (2.9.19) unstable; urgency=medium

This release switches to Sequoia for OpenPGP verification on supported Debian platforms.

🎉 #sequoiaPGP #pgp #debian

PGP mal anders. Für unseren @ct_Magazin Newsletter Open Source Spotlight hab ich mit @nwalfield von @sequoiapgp gesprochen. Denn das #SequoiaPGP hat diese Woche Version 1.0 ihres Kommandozeilentools sq veröffentlicht. Was sq anders macht und warum Neal & Co. an einer neuen PGP-Implementierung arbeiten, erfahrt ihr in #OpenSourceSpotlight.

Abonniert unseren Newsletter, dann bekommt ihr die aktuelle Ausgabe mit dem Interview zugeschickt: https://www.heise.de/newsletter/anmeldung.html?id=ct-opensource&wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege

#OpenPGP #PGP #OpenSource

#SequoiaPGP project has announced version 1.0 of the #sq command-line tool for managing #OpenPGP encryption and signatures. It also provides a decentralized public key infrastructure (PKI), and key management facilities. This is the first stable release since development began on the project in 2017.

Sequoia #PGP: A Sapling Matures: Meet sq 1.0 https://sequoia-pgp.org/blog/2024/12/16/202412-sq-1.0/ #itsec #security #surveillance #privacy

I decided to Kick Ass and now sequoia-octopus-librnp is now in openSUSE Tumbleweed repo.

#opensuse #opensusetumbleweed #sequoiapgp #thunderbird

Does anyone have suggestions that can do #cryptographic signature verification of streaming data (as in a pipe)? The problem with #gpg in this case is that it will emit all the data out the pipe, only indicating with an exit code if the signature was good - at which point most of the data may have been processed. #SequoiaPGP is slightly better, withholding the last 25MB until things are fully verified.

I suspect I need something that signs blocks of the input. Does it exist? #askFedi

LWN.net weist auf eine drohende Spaltung der #OpenPGP -Welt hin, woran eigentlich niemand Interesse haben kann (siehe auch deren Posting). Soweit ich es verstanden habe, geht es um die Aktualisierung von RFC 4880. Eine Working Group, der auch Werner Koch (Autor von #GnuPG )  angehörte, hat an einer Aktualisierung jahrelang gearbeitet und, so die Aussage, zu einem Konsens gebracht. Nun soll von einer anderen Gruppierungist ein anderer Vorschlag überraschend eingebracht worden sein (see comment from [email protected])  wurde ein neuer Vorschlag eingebracht. Unter anderem Werner Koch wehrt sich dagegen, beispielsweise sieht er Kompatibilitätsprobleme. Ein Blick auf die Diskussion auf der Mailingliste zeigt, dass es hier neben den rein technischen Abwägung auch um persönliche Differenzen und vielleicht auch um strategischen Erwägungen (GnuPGP vs. Sequoia-PGP?) geht.

Die beiden unterschiedlichen Drafts:
- Vorschlag: #^https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-02.txt
- Neuer Vorschlag: #^https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

Stand scheint zu sein, dass sich auf der Mailingliste der neue Vorschlag („Crypto Refresh“) durchgesetzt hat, unter anderem auch Phil Zimmermann  hat sich dafür ausgesprochen. Für Werner Koch und andere scheint diese Entscheidung aber nicht tragbar zu sein. Sie propagieren darum einen Gegenentwurf unter dem Namen #LibrePGP.

Das blöde an der Sache: Für eine Software wie GnuPGP ist es nicht einfach herauszubekommen, nach welchem Standard die Verschlüsselung vorgenommen worden ist. Das bedeutet für beispielsweise das E-Mail-Ökosystem, das es noch schwieriger werden wird, E-Mail-Verschlüsselung für Anwender:innen einfach und fehlerfrei umzusetzen. Für eine stärkere Verbreitung von E-Mail-Verschlüsselung ist das also so hilfreich wie Fußpils zu haben.

Hier geht es zum LWN.net-Artikel: #^https://lwn.net/SubscriberLink/953797/b1701e578f357ba8/

#E-Mail #Verschlüsselung #Sequoia-PGP

I just released version 0.1.5 of the simple experimental standalone SSH agent for #OpenPGP cards (https://crates.io/crates/openpgp-card-ssh-agent/).

This is a minor update in terms of functionality.

However, it marks a move of the crate to the @Codeberg platform (including an integration test in Codeberg's Woodpecker CI, testing the agent against a virtual OpenPGP card: https://ci.codeberg.org/openpgp-card/ssh-agent/pipeline/31)

#OpenSSH #OpenPGPCard #SequoiaPGP

The #SequoiaPGP team has released version 1.5.0 of https://crates.io/crates/sequoia-octopus-librnp, the Sequoia-based alternative #OpenPGP backend for #Thunderbird.

This release fixes support for Thunderbird 102.7, and contains a big overhaul for Web of Trust calculations, which automatically set Thunderbird's "acceptance" of OpenPGP certificates based on published certifications and the trust roots the user configured in their GnuPG subsystem.

#Octopus

@macst3r Und ewig dauert der Build auch noch:Beispielsweise braucht #SequoiaPGP auf meinem Rechner fast eine dreiviertel Stunde. Die Tests kann ich nicht mal laufen lassen, weil dann der Speicher ausgeht, weil Cargo soviel overhead Dateien erzeugt. (Build läuft im Container in /tmp)

@thunderbird
When will #Thunderbird use #SequoiaPGP instead of the buggy rnp library? Esp. since sequoia is written in rust.

When will #Thunderbird implement easy encryption be default with automatic key-roll-over, like #pEp #prettyEasyPrivacy does? Or simply make pEp default part of TB?

@jesse_m @boilingsteam I prefer Sequoia PGP, also in #Rust
https://sequoia-pgp.org
#sequoiapgp #openpgp