On Mon 2025-04-14 13:53:16 +0200, René Engelhard wrote: > It's still only test keys to test whether signing/verify works, not real > world keys. > > But yeah, they need to be updated, will propose upstream. It's > definitely too late for Trixie though, will try to get it upstream > for forky.
Thanks for proposing the fix upstream. please follow up here with the pointer to the upstream issue. Fwiw, if the change needed to clear this up is simply to replace the OpenPGP artifacts used for the libreoffice test suite with artifacts that contain reasonable algorithm choices, that doesn't seem like an outlandish change to propose for Trixie, whether it's in 13.0 or a subsequent point release. As you propose improvements to LibreOffice's use of OpenPGP, i recommend considering use of the stateless OpenPGP interface, of which we have several distinct interoperable implementations in debian. To the extent that LibreOffice's OpenPGP integration is all done in Java, they might be particularly interested in the sop-java interface (debian package "libsop-java-java") and its implementation by PGPainless (debian package libpgpainless-sop-java). pgpainless is a robust participant in the OpenPGP interoperability test suite (https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html) GnuPG's opaque and tricky statefulness has been an ongoing source of bugs and vendor lock-in that has kept the OpenPGP ecosystem from evolving in safer and stronger directions. Even more problematically, GnuPG has decided to stop supporting OpenPGP going forward in favor of a non-standardized variant. This means any GnuPG user's hope for interoperability with other OpenPGP implementations is at risk. In Debian, we're trying to mitigate these risks by carrying patches to ensure that GnuPG emits OpenPGP-compatible artifacts by default, but i can't guarantee how long that kind of patching will hold. Regards, --dkg
signature.asc
Description: PGP signature
