Package: gpg-from-sq

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/(

Hi,

Am 13.04.25 um 20:34 schrieb Rene Engelhard:

$ 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.

To make it explicit: I don't use gpg-from-sq but B-D-A: on gpg.
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

I could do

[...]

as a workaround, but...

Which I probably need to do anyway to fix the build in experimental if the gb picked up gpg-from-sq again.


Regards,

Rene

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

Am 13.04.25 um 20:50 schrieb Rene Engelhard:

I could do

[...]

as a workaround, but...

Which I probably need to do anyway to fix the build in experimental if the gb picked up gpg-from-sq again.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rene Engelhard <rene@debian.org> writes:

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

[..]

key material is https://cgit.freedesktop.org/libreoffice/core/tree/test/signing-keys?h=libreoffice-25-2-3

Looking purely at the key material I see:

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

Is that the explanation or is there some other incompatibility here?

It is not incompatible, just that gpg-from-sq rejects weak hash
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

-----BEGIN PGP SIGNATURE-----

wsC7BAEBCgBvBYJn/MHACRCI3H4zOF95HUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfCSWKPsOosKI/1+3lUlG9CF47pYUKnNJ4UhImO7ZDl hBYhBCVqTlXkpy2XrSRo54jcfjM4X3kdAADZpwf+LJSGb8VeTPn/oPNjq820Yhxs CWbTgQ2i9k8Z3D06O3N34wPQ5ymFdsCh9lQlIVthw6pOy8Hio6FElVwHpNK2V1+Y NIabeY2PrCmtU/1hQbHcZSp7Y+P31adWM1YI6ZwaDzTXByHg7YouuVDhS6vNjZ7d v+fxLJ+t64unqbz6rib131q+0VAORip2930zE5cDHBtX/QF23lvtDm5h6gMrK3xS qeoaXH+49Gf2doUVbCEUxgLKnaFpMeRzzchsyXUh/8J7XXpeoD7W7jDOj0esAhVj PL6EzHpimOjG4YIsrdI2UKHwfVp6pqU7I60YfuX+QeDJo62L3PBUSCz/cGA0Ew==
=h3NY
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

control: reassign -1 src:libreoffice
control: severity -1 normal
control: affects -1 gpg-from-sq
thanks

On Mon, Apr 14, 2025 at 10:05:20AM +0200, Justus Winter wrote:

Looking purely at the key material I see:

[...]

It is not incompatible, just that gpg-from-sq rejects weak hash
algorithms. Note that the signature extracted from xmlsecurity/qa/unit/signing/data/goodGPG.odt is fine:

[...]

Therefore, an easy way to recover is to fix the certificates:

[...]

thanks, reassigning accordingly.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

The hardest part about defending against social engineering is that it
doesn't attack attack the weakness of a community. It attacks its
*strengths*: trust, collaboration, and mutual assistance. (Russ Allbery)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmf86scACgkQCRq4Vgaa qhw6MA//ab9ahk0jJlzWCZjJTwx5REvY6WLPXh/i0h551NKr8leF5pyRxaNCSTH2 QUKOeARxqlSHmzI58mCjfWH4dqgwYDU//wrhdTkQbZ2ISMSkma5yaskiLpLUN1AM qZaN9j9SPSPqfoUhSG7nH0syP3GOULR2hxMHNj1jHOV16yE+Kfq3d+MITSB87wtP gtqNhxJMrH9Gc8+8gA8aEcF8QtRSRz3Yjsr4zFSCCPJSQ0mKK2bcUYjfPuN586F2 1HY0JL665pC9KKUR25GxM1FlwPKuk4SiArXM4rCSAvvqa0/9htbKV3S4oALY8LYr YxTLIEGJeRFr8gLyl4xM2HjNHjpixmVzjSEh9GLqhtYee8J5YF0wudvqLCvj/xLV glg7u5CgmmWINdXZ8ibEIwLTMMIBPMb+uGZQYSWLuGmU62NYgjYeAGmrub/jaeA2 E5sTwuLMfXvV6e+HV8DM5qYMKZmIpY4W

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>: >On Mon, Apr 14, 2025 at 10:05:20AM +0200, Justus Winter wrote:

Looking purely at the key material I see:

[...]

It is not incompatible, just that gpg-from-sq rejects weak hash
algorithms.

If you divert /usr/bin/gpg, IMHO you need to behave like gpg. This includes accepting what gpg accepts.

Otherwise such surprises happen.

Therefore, an easy way to recover is to fix the certificates:

[...]

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é

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am 14. April 2025 13:43:20 MESZ schrieb Justus Winter <justus@sequoia-pgp.org>: >René Engelhard <rene@rene-engelhard.de> writes:

If you divert /usr/bin/gpg, IMHO you need to behave like gpg.

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. (...)

I believe you...

This includes accepting what gpg accepts.

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]

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é

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

René Engelhard <rene@rene-engelhard.de> writes:

If you divert /usr/bin/gpg, IMHO you need to behave like gpg.

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.

This includes accepting what gpg accepts.

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.

Otherwise such surprises happen.

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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

wsC7BAEBCgBvBYJn/PTZCRCI3H4zOF95HUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmdEs/1iao2tGAF/yTUWMS6hBJIFvyobzOuBWvD19DNj nhYhBCVqTlXkpy2XrSRo54jcfjM4X3kdAACbBwf/SivQxp/2egt/9K7rUBb3IYNa HqM32/MeaOQQvb+ACqRFne6BacKA+3ZzhJB+XJ6iMt/dDhUq6UcuGc3kK+98E1vG vUa1AD/0ZXRE7r2/ud5byR424Var+vvDl/XWCzzBTIUO2UuzjSM7Y1fxOoo33WTZ R2tCi58TvORCPGjS9meENRYzKXM1ONc4X/HNyfTUvIZ+p2QG+8127wkPFOsvqIWq eLDzmo7Ps5owhIL3Bn4tGLt7U6KgI7jWPA1lmq/2+MQp86XnUgpAh7opewSVKJvg 1NTa5+PI4DxbB5GpNUl8AwqxPIUm2740rv37DGUaHB6FOd/cOUNDiFaI+imQBw==0r6K
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 2025-04-14 13:43:20 +0200, Justus Winter wrote:

René Engelhard <rene@rene-engelhard.de> writes:

If you divert /usr/bin/gpg, IMHO you need to behave like gpg.

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.

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,

--dkg

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCZ/0TUwAKCRB4C4VO2cK0 ljSMAP9l+2r1/UU3y0jupgHuoIZw8DulwgaO/6sY99F1aVdiegEAlVIbGqPsp4E6 abNdq4WEnmdd7PLFkRC90bcc+AZKvQc=5gR1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 2025-04-14 16:26:07 +0200, René Engelhard wrote:

[ dkg wrote: ]

To the extent that LibreOffice's OpenPGP integration is all done in Java

Nope. gpgmepp.

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.

--dkg

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCZ/6BWAAKCRB4C4VO2cK0 lo7NAQCYEH5YsmZ1HHetJ1V/b9+r87ai1ruCdKQPZxOb3u43OgD+OMtsF87a4sD3 tKX4TeKfApA9cyi0BPM4D9wA6vu1nA0Kw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)