Chlorinedev@（也就是 Secondary UID）显示在 Primary UID 前面。以为是最新签名问题，遂请帝兵（TailsOS、离线主密钥），把 Primary 标记在两个 UID 之间横跳了一下来刷新状态。
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🔥
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:
@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:
Clemens
atopia
David Sardari❯ 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
OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. This document specifies a method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via DNSSEC.
🤚 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.
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.
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".
Jesus Michał "Le Sigh" 🏔 (he)
Jezus Michał "Le Wzdych" (on)
Marcus Adams