- Package:
- gpg-from-sq
- Source:
- gpg-from-sq
- Submitter:
- Rene Engelhard
- Date:
- 2025-04-15 16:45:02 UTC
- Severity:
- normal
Version: 0.13.1-3
Severity: important
Justification: causing FTBFS in stuff using /usr/bin/gpg
Hi,
[ filing a bug per Holgers request ]
I got the following surprising test failure in libreoffice 4:25.2.3~rc1-1 uploaded to experimental[1]:
[build CUT] xmlsecurity_signing
S=/build/reproducible-path/libreoffice-25.2.3~rc1 && I=$S/instdir && W=$S/workdir && mkdir -p $W/CppunitTest/ && rm -fr $W/CppunitTest/xmlsecurity_signing.test.user && cp -r $W/unittest $W/CppunitTest/xmlsecurity_signing.test.user && rm -fr $W/CppunitTest/xmlsecurity_signing.test.core && mkdir $W/CppunitTest/xmlsecurity_signing.test.core && cd $W/CppunitTest/xmlsecurity_signing.test.core && ( MAX_CONCURRENCY=4 MOZILLA_CERTIFICATE_FOLDER=dbm: SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp LIBO_LANG=C LIBO_LD_PATH=$LD_LIBRARY_PATH LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs LO_RUNNING_UNIT_TEST=1 $W/LinkTarget/Executable/cppunittester $W/LinkTarget/CppunitTest/libtest_xmlsecurity_signing.so --headless "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" "-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/xmlsecurity_signing.test.user" "-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry xcsxcu:file://$W/unittest/registry-common xcsxcu:file://$W/unittest/registry-user-ui" "-env:UNO_TYPES=file://$I/program/types.rdb file://$I/program/types/offapi.rdb" "-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb file://$W/Rdb/services.rdb" -env:URE_BIN_DIR=file://$I/program -env:URE_INTERNAL_LIB_DIR=file://$I/program -env:LO_LIB_DIR=file://$I/program -env:LO_JAVA_DIR=file://$I/program/classes --protector $W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector --protector $W/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector --protector $W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector -env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}" "-env:CPPUNITTESTTARGET=$W/CppunitTest/xmlsecurity_signing.test" ) 2>&1
[_RUN_____] aaa_testODFX509CertificateChain::TestBody
aaa_testODFX509CertificateChain::TestBody finished in: 284ms
[_RUN_____] test96097Calc::TestBody
test96097Calc::TestBody finished in: 212ms
[_RUN_____] test96097Doc::TestBody
test96097Doc::TestBody finished in: 179ms
[_RUN_____] testDNCompatibility::TestBody
testDNCompatibility::TestBody finished in: 1ms
[_RUN_____] testDescription::TestBody
testDescription::TestBody finished in: 108ms
[_RUN_____] testDropMacroTemplateSignature::TestBody
testDropMacroTemplateSignature::TestBody finished in: 293ms
[_RUN_____] testECDSA::TestBody
testECDSA::TestBody finished in: 101ms
[_RUN_____] testECDSAOOXML::TestBody
testECDSAOOXML::TestBody finished in: 33ms
[_RUN_____] testECDSAPDF::TestBody
testECDSAPDF::TestBody finished in: 31ms
[_RUN_____] testImplicitScriptSign::TestBody
testImplicitScriptSign::TestBody finished in: 16ms
[_RUN_____] testInvalidZIP::TestBody
testInvalidZIP::TestBody finished in: 38ms
[_RUN_____] testODFBroken::TestBody
testODFBroken::TestBody finished in: 30ms
[_RUN_____] testODFBrokenDsigGPG::TestBody
testODFBrokenDsigGPG::TestBody finished in: 230ms
[_RUN_____] testODFBrokenStreamGPG::TestBody
testODFBrokenStreamGPG::TestBody finished in: 234ms
[_RUN_____] testODFDoubleX509Certificate::TestBody
testODFDoubleX509Certificate::TestBody finished in: 42ms
[_RUN_____] testODFDoubleX509Data::TestBody
testODFDoubleX509Data::TestBody finished in: 46ms
[_RUN_____] testODFGood::TestBody
testODFGood::TestBody finished in: 29ms
[_RUN_____] testODFGoodGPG::TestBody
./xmlsecurity/qa/unit/signing/signing.cxx:1259:testODFGoodGPG::TestBody
equality assertion failed
- Expected: 1
- Actual : 2
- 2
testODFGoodGPG::TestBody finished in: 233ms
[_RUN_____] testODFMacroDoubleX509Data::TestBody
testODFMacroDoubleX509Data::TestBody finished in: 70ms
[_RUN_____] testODFNo::TestBody
testODFNo::TestBody finished in: 31ms
[_RUN_____] testODFTripleX509Data::TestBody
testODFTripleX509Data::TestBody finished in: 33ms
[_RUN_____] testODFUnsignedTimestamp::TestBody
testODFUnsignedTimestamp::TestBody finished in: 35ms
[_RUN_____] testODFUntrustedGoodGPG::TestBody
testODFUntrustedGoodGPG::TestBody finished in: 97ms
[_RUN_____] testOOXMLAppend::TestBody
testOOXMLAppend::TestBody finished in: 14ms
[_RUN_____] testOOXMLBroken::TestBody
testOOXMLBroken::TestBody finished in: 33ms
[_RUN_____] testOOXMLDescription::TestBody
testOOXMLDescription::TestBody finished in: 32ms
[_RUN_____] testOOXMLPartial::TestBody
testOOXMLPartial::TestBody finished in: 33ms
[_RUN_____] testOOXMLRemove::TestBody
testOOXMLRemove::TestBody finished in: 9ms
[_RUN_____] testOOXMLRemoveAll::TestBody
testOOXMLRemoveAll::TestBody finished in: 5ms
[_RUN_____] testPDFAddVisibleSignature::TestBody
testPDFAddVisibleSignature::TestBody finished in: 100ms
[_RUN_____] testPDFBad::TestBody
testPDFBad::TestBody finished in: 98ms
[_RUN_____] testPDFGood::TestBody
testPDFGood::TestBody finished in: 107ms
[_RUN_____] testPDFHideAndReplace::TestBody
testPDFHideAndReplace::TestBody finished in: 131ms
[_RUN_____] testPDFNo::TestBody
testPDFNo::TestBody finished in: 90ms
[_RUN_____] testPreserveMacroTemplateSignature10::TestBody
testPreserveMacroTemplateSignature10::TestBody finished in: 582ms
[_RUN_____] testPreserveMacroTemplateSignature12_ODF::TestBody
./xmlsecurity/qa/unit/signing/signing.cxx:1374:testPreserveMacroTemplateSignature12_ODF::TestBody
equality assertion failed
- Expected: 1
- Actual : 2
- ./xmlsecurity/qa/unit/signing/signing.cxx:1401
testPreserveMacroTemplateSignature12_ODF::TestBody finished in: 260ms
[_RUN_____] testSignatureLineODF::TestBody
testSignatureLineODF::TestBody finished in: 47ms
[_RUN_____] testSignatureLineOOXML::TestBody
testSignatureLineOOXML::TestBody finished in: 4ms
[_RUN_____] testSigningMultipleTimes_ODT::TestBody
testSigningMultipleTimes_ODT::TestBody finished in: 173ms
[_RUN_____] testSigningMultipleTimes_OOXML::TestBody
testSigningMultipleTimes_OOXML::TestBody finished in: 85ms
[_RUN_____] testXAdES::TestBody
testXAdES::TestBody finished in: 105ms
[_RUN_____] testXAdESGood::TestBody
testXAdESGood::TestBody finished in: 33ms
[_RUN_____] testXAdESNotype::TestBody
testXAdESNotype::TestBody finished in: 17ms
signing.cxx:1259:Assertion
Test name: testODFGoodGPG::TestBody
equality assertion failed
- Expected: 1
- Actual : 2
- 2
signing.cxx:1374:Assertion
Test name: testPreserveMacroTemplateSignature12_ODF::TestBody
equality assertion failed
- Expected: 1
- Actual : 2
- ./xmlsecurity/qa/unit/signing/signing.cxx:1401
Failures !!!
Run: 43 Failure total: 2 Failures: 2 Errors: 0
make[3]: *** [/build/reproducible-path/libreoffice-25.2.3~rc1/solenv/gbuild/CppunitTest.mk:130: /build/reproducible-path/libreoffice-25.2.3~rc1/workdir/CppunitTest/xmlsecurity_signing.test] Error 1
make[3]: Leaving directory '/build/reproducible-path/libreoffice-25.2.3~rc1'
make[2]: *** [Makefile:301: build] Error 2
make[2]: Leaving directory '/build/reproducible-path/libreoffice-25.2.3~rc1'
make[1]: *** [/build/reproducible-path/libreoffice-25.2.3~rc1/debian/rules:2645: check] Error 2
make[1]: Leaving directory '/build/reproducible-path/libreoffice-25.2.3~rc1'
make: *** [debian/rules:2513: debian/stampdir/build-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2
There hasn't been any changes between 4:25.2-2-1 from sid and this which would explain this. A local
sbuild build even worked with 4:25.2.3~rc1-1.
libreoffice has
$ grep gpg control
gpg [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc !sparc64] <!nocheck>,
gpg-agent [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc !sparc64] <!nocheck>,
gpgconf [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc !sparc64] <!nocheck>,
libgpg-error-dev,
libgpgme-dev,
libgpgmepp-dev,
in Build-Depends-Arch:
The difference between both is that on the buildd gpg-for-sq 0.13.1-3 etc. got installed whereas in my local sbuild build gpg as in gpg 2.4.7-14 was installed,
and that one passed.
Indeed, after installing gpg-for-sq in a container which had a working build before makes it fail, removing it makes it work again.
That test is
https://cgit.freedesktop.org/libreoffice/core/tree/xmlsecurity/qa/unit/signing/signing.cxx?h=libreoffice-25-2-3#n1247
key material is
https://cgit.freedesktop.org/libreoffice/core/tree/test/signing-keys?h=libreoffice-25-2-3
I wonder whether it has to do with
// Our local gpg config fully trusts the signing cert, so in
// contrast to the X509 test we can fail on NOTVALIDATED here
but that "local gpg conf" is apparently simply what gpgconf outputs (but that said, gpgconf is from gpgconf,
and that one is not diverted).
Is that the explanation or is there some other incompatibility here?
I could do
diff --git a/changelog b/changelog
index 9dbe0778b..28785cba4 100644
--- a/changelog
+++ b/changelog
@@ -7,6 +7,9 @@ libreoffice (4:25.2.2-2) UNRELEASED; urgency=medium
- allow /etc/paperspecs (used by paperconf) (closes: #1100930)
* debian/po:
- add ca.po (closes: #1102089)
+ * debian/rules:
+ - add Build-Conflicts: gpg-from-sq <!nocheck> [$(OOO_CHECK_ARCHS)], since
+ xmlsecurity_signing fails with gpg being gpg-from-sq
-- Rene Engelhard <rene@debian.org> Sun, 30 Mar 2025 11:35:54 +0200
diff --git a/control b/control
index 38592e9f2..f96c04a65 100644
--- a/control
+++ b/control
@@ -247,6 +247,7 @@ Build-Depends-Indep: ant [!armel !armhf !hppa !kfreebsd-amd64 !kfreebsd-i386 !mi
symlinks
Build-Conflicts: amd-libopencl1,
clang [alpha hppa ia64 m68k mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64],
+ gpg-from-sq [amd64 arm64] <!nocheck>,
nvidia-glx-dev,
nvidia-glx-legacy-dev,
nvidia-libopencl1
diff --git a/rules b/rules
index a14f40dd3..447fef711 100755
--- a/rules
+++ b/rules
@@ -2354,6 +2354,10 @@ else
perl -pi -e "s/(Build-Conflicts: .*)/\1,clang [$(filter-out $(OOO_CLANG_SUPPORTED_ARCHS),$(OOO_ARCHS))],/" debian/control.new
endif
+ifeq "$(RUN_MAKE_CHECK)" "y"
+ perl -pi -e "s/(Build-Conflicts: .*)/\1,gpg-from-sq [$(OOO_CHECK_ARCHS)] <!nocheck>,/" debian/control.new
+endif
+
$(PYTHON) debian/scripts/joinctrl.py < debian/control.new > debian/control.tmp
mv debian/control.tmp debian/control.new
as a workaround, but...
Regards,
Rene
Hi, Am 13.04.25 um 20:34 schrieb Rene Engelhard: So that one should have been taken and wasn't due to whatever the resolver did. (This is probably helped by gpg-from-sq having a Provides: gpg...) And with gpg-from-sq "standing in" for gpg the failure happens. Buildlog: https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=amd64&ver=4%3A25.2.3~rc1-1&stamp=1744402240&raw=0 [...] Which I probably need to do anyway to fix the build in experimental if the gb picked up gpg-from-sq again. Regards, Rene
Hi Am 13.04.25 um 20:50 schrieb Rene Engelhard: I now decided to have it anyway, since it also fixes the theoretic case of people having gpg-from-sq installed for whatever reason manually, and that would "work" for B-D-A: given the Provides:. Not yet uploaded. Regards, Rene
Rene Engelhard <rene@debian.org> writes:
[..]
teythoon@europ /tmp/core/test/signing-keys (git)-[libreoffice-25-2-3] % /bin/gpg --export | sq cert lint
gpg: WARNING: unsafe permissions on homedir '/tmp/core/test/signing-keys'
Certificate C468A04FCA526A9F is not valid under the standard policy: No binding signature at time 2025-04-14T07:40:22Z
Certificate C468A04FCA526A9F contains a User ID (test key - only signing <libreoffice@lists.freedesktop.org>) protected by SHA-1
Certificate 96BDBA932A7D4D05 is not valid under the standard policy: No binding signature at time 2025-04-14T07:40:22Z
Certificate 96BDBA932A7D4D05 contains a User ID (test key - only for encryption <libreoffice@lists.freedesktop.org>) protected by SHA-1
Certificate 96BDBA932A7D4D05, key C914B3CC9B60A3FB uses a SHA-1-protected binding signature.
Examined 3 certificates.
0 certificates are invalid and were not linted. (GOOD)
3 certificates were linted.
2 of the 3 certificates (66%) have at least one issue. (BAD)
0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
3 of the non-revoked linted certificates have at least one non-revoked User ID:
2 have at least one User ID protected by SHA-1. (BAD)
2 have all User IDs protected by SHA-1. (BAD)
2 of the non-revoked linted certificates have at least one non-revoked, live subkey:
1 has at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
Error: 2 certificates have at least one issue
algorithms. Note that the signature extracted from
xmlsecurity/qa/unit/signing/data/goodGPG.odt is fine:
% sq packet dump sig
Signature Packet, old CTB, 380 bytes
Version: 4
Type: Binary
Pk algo: RSA
Hash algo: SHA512
Hashed area:
Signature creation time: 2017-12-06 12:04:15 UTC
Notation: issuer-fpr@notations.openpgp.fifthhorseman.net: 93F7584031D9B74A57BB89DFC468A04FCA526A9F
Unhashed area:
Issuer: C468A04FCA526A9F
Digest prefix: EFB3
Level: 0 (signature over data)
Therefore, an easy way to recover is to fix the certificates:
teythoon@europ /tmp/core/test/signing-keys (git)-[libreoffice-25-2-3] % /bin/gpg --export-secret-keys | sq cert lint --fix | /bin/gpg --import
gpg: WARNING: unsafe permissions on homedir '/tmp/core/test/signing-keys'
gpg: WARNING: unsafe permissions on homedir '/tmp/core/test/signing-keys'
Certificate C468A04FCA526A9F is not valid under the standard policy: No binding signature at time 2025-04-14T07:57:29Z
Certificate C468A04FCA526A9F contains a User ID (test key - only signing <libreoffice@lists.freedesktop.org>) protected by SHA-1
Certificate 96BDBA932A7D4D05 is not valid under the standard policy: No binding signature at time 2025-04-14T07:57:29Z
Certificate 96BDBA932A7D4D05 contains a User ID (test key - only for encryption <libreoffice@lists.freedesktop.org>) protected by SHA-1
Certificate 96BDBA932A7D4D05, key C914B3CC9B60A3FB uses a SHA-1-protected binding signature.
Examined 2 certificates.
0 certificates are invalid and were not linted. (GOOD)
2 certificates were linted.
2 of the 2 certificates (100%) have at least one issue. (BAD)
0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
2 of the non-revoked linted certificates have at least one non-revoked User ID:
2 have at least one User ID protected by SHA-1. (BAD)
2 have all User IDs protected by SHA-1. (BAD)
1 of the non-revoked linted certificates has at least one non-revoked, live subkey:
1 has at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
gpg: key C468A04FCA526A9F: "test key - only signing <libreoffice@lists.freedesktop.org>" 1 new signature
gpg: key C468A04FCA526A9F: secret key imported
gpg: key 96BDBA932A7D4D05: "test key - only for encryption <libreoffice@lists.freedesktop.org>" 2 new signatures
gpg: key 96BDBA932A7D4D05: secret key imported
gpg: Total number processed: 2
gpg: new signatures: 3
gpg: secret keys read: 2
gpg: secret keys unchanged: 2
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
teythoon@europ /tmp/core/test/signing-keys (git)-[libreoffice-25-2-3] % gpg-sq -k
gpg: WARNING: unsafe permissions on homedir '/tmp/core/test/signing-keys'
/tmp/core/test/signing-keys/pubring.cert.d
------------------------------------------
pub rsa2048 2017-05-30 [SC]
237167E1A762AE7096F1F72EAE8850B494DC4F32
uid [ unknown] <foo@bar.de>
sub rsa2048 2017-05-30 [E]
pub rsa2048 2017-12-06 [SC]
93F7584031D9B74A57BB89DFC468A04FCA526A9F
uid [ultimate] test key - only signing <libreoffice@lists.freedesktop.org>
pub rsa2048 2018-01-11 [SC]
BB87453F47FEBF396099210496BDBA932A7D4D05
uid [ultimate] test key - only for encryption <libreoffice@lists.freedesktop.org>
sub rsa2048 2018-01-11 [E]
Please let me know if you have more questions, or what I can do to help!
Best,
Justus
control: reassign -1 src:libreoffice control: severity -1 normal control: affects -1 gpg-from-sq thanks [...] [...] [...] thanks, reassigning accordingly.
clone -1 -2 retitle -2 test gpg keys use weak hash algorithm, breaking with gpg-from-sq reassign -1 gpg-from-sq thanks Hi, Am 14. April 2025 13:00:23 MESZ schrieb Holger Levsen <holger@layer-acht.org>: If you divert /usr/bin/gpg, IMHO you need to behave like gpg. This includes accepting what gpg accepts. Otherwise such surprises happen. Will try. (and keep pubring.gpg etc. since that is hardcoded in test setup copying) And this would need the PITA to maintain that in Debian (binary files changing...) and upstreams old baseline can also be a problem. Need to submit and see ... Will try to get it upstream, though for 25.8. Definitely not freeze material. Regards René
René Engelhard <rene@rene-engelhard.de> writes:
gpg doesn't behave like gpg. Just look at all the version-specific
hacks in GPGME if you don't take my word for it. Any code relying on a
specific behavior of gpg is broken.
What gpg accepts is unacceptable. Just to provide some context, here is
the second paragraph of https://en.wikipedia.org/wiki/SHA-1
Since 2005, SHA-1 has not been considered secure against well-funded
opponents;[11] as of 2010 many organizations have recommended its
replacement.[12][10][13] NIST formally deprecated use of SHA-1 in
2011 and disallowed its use for digital signatures in 2013, and
declared that it should be phased out by 2030.[14] As of 2020,
chosen-prefix attacks against SHA-1 are practical.[6][8] As such, it
is recommended to remove SHA-1 from products as soon as possible and
instead use SHA-2 or SHA-3. Replacing SHA-1 is urgent where it is
used for digital signatures.
It is sad that gpg let some LibreOffice contributor create a certificate
with SHA-1 binding signatures in 2017. Saying any replacement must be
as lenient as the software that let this happen in the first place makes
it really hard for anyone to improve the status quo.
I disagree. I have worked with many downstream test suites, and the
problem is having fixed cryptographic artifacts in them. They will go
stale. This is not a question of if, but when. Preferably, test
artifacts with cryptographic artifacts should be created during the test
suite run.
However, one often wants to anchor the implementation using
pre-generated artifacts as well, and one needs to be careful not to let
them go stale (and, not generate artifacts that are bad in the first
place, like it happened here).
Best,
Justus
Hi, Am 14. April 2025 13:43:20 MESZ schrieb Justus Winter <justus@sequoia-pgp.org>: I believe you... I know... 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. Regards René
GnuPG maintainer here. i have to say i'm sympathetic to Justus's
position, though i would have put it slightly differently.
There is no one single "gpg behavior", even among all currently
supported GnuPG releases. It gets even hairier if you go back in time
and look at the range of historical behaviors, even of all versions in
Debian stable releases.
Doing downstream maintenance of GnuPG means dealing with constant flux
and strange quirks, some of which upstream takes seriously when they're
discovered and some of which appear to just be the standard operating
procedure, with no explanation forthcoming.
the Sequoia Chameleon ("gpg-sq") has so far been fairly stable, and its
divergences from GnuPG are explicitly documented with what seem like
reasonable motivations to me:
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg#known-deliberate-divergences
The fact that it uncovered weak digest algorithms used in a relatively
recently created test suite does not seem like a bug in gpg-sq; rather,
it looks like part of a long overdue hardening of the ecosystem.
Regards,
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,
Hi, Am 14. April 2025 16:06:45 MESZ schrieb Daniel Kahn Gillmor <dkg@debian.org>: Will do. I know In theory. In practice that needs to a) move the original files away b) replace them with regenerated ones (or even regen itself which would involve a b-d on sq....) c) move the old ones back in rules for dpkg-source. Or opaquely do it in-place (and use include-binaries) and have it "hidden" in .debian.tar.xz which will be forgotten and lost somewhen. Since it affects the binary keyring files. Nope. gpmepp. Regards René
Hi, Am 14.04.25 um 16:06 schrieb Daniel Kahn Gillmor: https://gerrit.libreoffice.org/c/core/+/184170 Regards, Rene
Hi, Am 14.04.25 um 13:00 schrieb Holger Levsen: It's unfortunately not that easy. After updating the secring.gpg I get the exact same failure. I wouldn't rule out that's "just" because it's not a C/C++ binary and LO (and gpgme inside that LO process) is not able to call rust binaries... Asked upstream. (Though a--- snip --- #!/bin/sh gpg-sq $@
Ah, condolences, that is a complex and fiddly mechanism if the only things needed are signing (with known keys)and verification (with known certificates). ☹ hopefully they can move to more reliable and ergonomic OpenPGP mechanisms in the future.