xmlsec 1.2.35

[lsh123]

The XML Security Library 1.2.35 release includes the following changes:

• Migration to OpenSSL 3.0 API (based on PR by @snargit). Note that OpenSSL engines are disabled by default when XMLSec library is compiled against OpenSSL 3.0. To re-enable OpenSSL engines, use "--enable-openssl3-engines" configure flag (there will be a lot of deprecation warnings).
• The OpenSSL before 1.1.0 and LibreSSL before 2.7.0 are now deprecated and will be removed in the future versions of XMLSec Library.
• Refactored all the integer casts to ensure cast-safety. Fixed all warnings and enabled "-Werror" and "-pedantic" flags on CI builds.
• Added configure flag to use size_t for xmlSecSize (currently disabled by default for backward compatibility).
• Moved all CI builds to GitHub actions.
• Several other small fixes (more details).

Thanks to everyone who contributed patches and filed bugs!

Aleksey

[vmiklos]

Hi Aleksey,

We (libreoffice) ran into one problem with this release: NSS 3.50.1 and NSPR 4.25.1 is now required, which is a bit of a problem on Ubuntu LTS versions that ship NSS 3.49 currently. To calm down the angry mob :-) I currently lower these requirements downstream:

https://github.com/LibreOffice/core/blob/master/external/xmlsec/old-nss.patch.1

My understanding is that this is good enough if you bundle xmlsec as a library and you don't run the tests anyway.

Now the question: should I just carry this patch downstream (till LTS distros used by people update NSS) or would it be OK to lower the versions in xmlsec itself?

I get that you need the newer version for the new test data. The question is if configure should fail in case the actual library works fine with an older version as well.

Thanks,

Miklos

[lsh123]

Argh... let me try and see what's going to fail with 3.49

[vmiklos]

I'm not personally affected (both RHEL and SLE ship a newer NSS), but it seems the pain point is Ubuntu 20.04 LTS, which is still supported till 2025 and ships with NSS 3.49, it seems.

[lsh123]

I don't see any problems with 3.49 so: #424

[lsh123]

Should be fixed in 1.2.36 I just published

[vmiklos]

Thanks a lot! :-)

[reneengelhard]

Hi,

I noticed that xmlsec1 1.2.35 removed symbols, which would theoretically (it seems that nothing in Debian uses it...) break stuff using these. That should have probably been a SONAME bump - which you plan to do in #354 anyway I hope but the breakage is there already - ...

(1.2.31->1.2.32 did, too, didn't check back further):

1.2.31 to 1.2.32:

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/libxmlsec1-nss/DEBIAN/symbols doesn't match completely debian/libxmlsec1-nss.symbols
--- debian/libxmlsec1-nss.symbols (libxmlsec1-nss_1.2.32-1_amd64)
+++ dpkg-gensymbolsPJ8WEv       2022-11-09 16:37:08.075089298 +0000
@@ -69,7 +69,7 @@
  xmlSecNssTransformEcdsaSha256GetKlass@Base 1.2.31
  xmlSecNssTransformEcdsaSha384GetKlass@Base 1.2.31
  xmlSecNssTransformEcdsaSha512GetKlass@Base 1.2.31
- xmlSecNssTransformHmacMd5GetKlass@Base 1.2.31
+#MISSING: 1.2.32-1# xmlSecNssTransformHmacMd5GetKlass@Base 1.2.31
  xmlSecNssTransformHmacRipemd160GetKlass@Base 1.2.31
  xmlSecNssTransformHmacSha1GetKlass@Base 1.2.31
  xmlSecNssTransformHmacSha224GetKlass@Base 1.2.31
@@ -80,8 +80,8 @@
  xmlSecNssTransformKWAes192GetKlass@Base 1.2.31
  xmlSecNssTransformKWAes256GetKlass@Base 1.2.31
  xmlSecNssTransformKWDes3GetKlass@Base 1.2.31
- xmlSecNssTransformMd5GetKlass@Base 1.2.31
- xmlSecNssTransformRsaMd5GetKlass@Base 1.2.31
+#MISSING: 1.2.32-1# xmlSecNssTransformMd5GetKlass@Base 1.2.31
+#MISSING: 1.2.32-1# xmlSecNssTransformRsaMd5GetKlass@Base 1.2.31
  xmlSecNssTransformRsaPkcs1GetKlass@Base 1.2.31
  xmlSecNssTransformRsaSha1GetKlass@Base 1.2.31
  xmlSecNssTransformRsaSha224GetKlass@Base 1.2.31

1.2.34 to 1.2.35 (uninteresting hunks edited out):

--- debian/libxmlsec1.symbols (libxmlsec1_1.2.35-1_amd64)
+++ dpkg-gensymbolsY2kjfo       2022-11-09 16:45:26.528864737 +0000
@@ -205,10 +211,10 @@
  xmlSecInit@Base 1.2.31-1
  xmlSecIsEmptyNode@Base 1.2.31-1
  xmlSecIsEmptyString@Base 1.2.31-1
- xmlSecKWAesDecode@Base 1.2.31-1
- xmlSecKWAesEncode@Base 1.2.31-1
- xmlSecKWDes3Decode@Base 1.2.31-1
- xmlSecKWDes3Encode@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecKWAesDecode@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecKWAesEncode@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecKWDes3Decode@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecKWDes3Encode@Base 1.2.31
  xmlSecKeyAdoptData@Base 1.2.31
  xmlSecKeyCopy@Base 1.2.31
  xmlSecKeyCreate@Base 1.2.31
--- debian/libxmlsec1-gnutls.symbols (libxmlsec1-gnutls_1.2.35-1_amd64)
+++ dpkg-gensymbolssFF44r       2022-11-09 16:45:26.740864643 +0000
@@ -78,21 +78,23 @@
  xmlSecGnuTLSTransformSha256GetKlass@Base 1.2.31
  xmlSecGnuTLSTransformSha384GetKlass@Base 1.2.31
  xmlSecGnuTLSTransformSha512GetKlass@Base 1.2.31
- xmlSecGnuTLSX509CertBase64DerRead@Base 1.2.31
- xmlSecGnuTLSX509CertBase64DerWrite@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecGnuTLSX509CertBase64DerRead@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecGnuTLSX509CertBase64DerWrite@Base 1.2.31
  xmlSecGnuTLSX509CertDebugDump@Base 1.2.31
  xmlSecGnuTLSX509CertDebugXmlDump@Base 1.2.31
+ xmlSecGnuTLSX509CertDerWrite@Base 1.2.35
  xmlSecGnuTLSX509CertDup@Base 1.2.31
  xmlSecGnuTLSX509CertGetIssuerDN@Base 1.2.31
  xmlSecGnuTLSX509CertGetIssuerSerial@Base 1.2.31
  xmlSecGnuTLSX509CertGetKey@Base 1.2.31
- xmlSecGnuTLSX509CertGetSKI@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecGnuTLSX509CertGetSKI@Base 1.2.31
  xmlSecGnuTLSX509CertGetSubjectDN@Base 1.2.31
  xmlSecGnuTLSX509CertRead@Base 1.2.31
- xmlSecGnuTLSX509CrlBase64DerRead@Base 1.2.31
- xmlSecGnuTLSX509CrlBase64DerWrite@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecGnuTLSX509CrlBase64DerRead@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecGnuTLSX509CrlBase64DerWrite@Base 1.2.31
  xmlSecGnuTLSX509CrlDebugDump@Base 1.2.31
  xmlSecGnuTLSX509CrlDebugXmlDump@Base 1.2.31
+ xmlSecGnuTLSX509CrlDerWrite@Base 1.2.35
  xmlSecGnuTLSX509CrlDup@Base 1.2.31-1
  xmlSecGnuTLSX509CrlGetIssuerDN@Base 1.2.31
  xmlSecGnuTLSX509CrlListGetKlass@Base 1.2.31
--- debian/libxmlsec1-nss.symbols (libxmlsec1-nss_1.2.35-1_amd64)
+++ dpkg-gensymbolsRJXPZx       2022-11-09 16:45:26.844864598 +0000
@@ -69,7 +69,7 @@
  xmlSecNssTransformEcdsaSha256GetKlass@Base 1.2.31
  xmlSecNssTransformEcdsaSha384GetKlass@Base 1.2.31
  xmlSecNssTransformEcdsaSha512GetKlass@Base 1.2.31
- xmlSecNssTransformHmacMd5GetKlass@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecNssTransformHmacMd5GetKlass@Base 1.2.31
  xmlSecNssTransformHmacRipemd160GetKlass@Base 1.2.31
  xmlSecNssTransformHmacSha1GetKlass@Base 1.2.31
  xmlSecNssTransformHmacSha224GetKlass@Base 1.2.31
@@ -80,8 +80,8 @@
  xmlSecNssTransformKWAes192GetKlass@Base 1.2.31
  xmlSecNssTransformKWAes256GetKlass@Base 1.2.31
  xmlSecNssTransformKWDes3GetKlass@Base 1.2.31
- xmlSecNssTransformMd5GetKlass@Base 1.2.31
- xmlSecNssTransformRsaMd5GetKlass@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecNssTransformMd5GetKlass@Base 1.2.31
+#MISSING: 1.2.35-1# xmlSecNssTransformRsaMd5GetKlass@Base 1.2.31
  xmlSecNssTransformRsaPkcs1GetKlass@Base 1.2.31
  xmlSecNssTransformRsaSha1GetKlass@Base 1.2.31
  xmlSecNssTransformRsaSha224GetKlass@Base 1.2.31

[reneengelhard]

Also note that there is
Debian Bug 1023038 and Debian Bug 1023039.

Didn't look into the latter but the former seems to be a subtle difference in xmlsec 1.2.35....

[lsh123]

There are a few things:

• xmlSecNssTransformHmacMd5GetKlass (and other MD5 functions): looks like the build was done with MD5 disabled (which is not a bad idea at all nowdays). You can try to use ./configure --enable-md5

• xmlSecKWAesDecode (and several other functions) are private and use internal XMLSec stuff. They should not (and actually cannot) be used externally.

• Bug 1023038 and bug 1023039: these are the changes in the output of xmlsec, there is no guarantee that the output stays as-is and the only guarantee is that the result signatures are valid (this is what xmlsec test suite is verifying btw).

[reneengelhard]

Hi,

thanks for your quick reply.

xmlSecNssTransformHmacMd5GetKlass (and other MD5 functions): looks like the build was done with MD5 disabled (which is not a bad idea at all nowdays). You can try to use ./configure --enable-md5

I see, thanks. While I agree removing MD5 might make sense I'll opt to try to keep the symbols.
Unfortunately --enable-md5 seems to be default according to configure --help but even with an explicit --enable-md5 I still have them missing.

xmlSecKWAesDecode (and several other functions) are private and use internal XMLSec stuff. They should not (and actually cannot) be used externally.

OK, so it's correct that they are gone? Good to know.

Bug 1023038 and bug 1023039: these are the changes in the output of xmlsec,

Yeah, I know, especially 1023038

there is no guarantee that the output stays as-is and the only guarantee is that the result signatures are valid (this is what xmlsec test suite is verifying btw).

Hmm, ok

[lsh123]

• MD5: There is also compile time check to see if the crypto library (e.g. openssl supports it). So changes in OpenSSL might have impacted it as well

• Internal functions: I am not 100% sure but this also might be change in how compiler / linker works. I didn't check all the functions from this list but a couple I looked at is still in the code and nothing change about that. So a simple change in linker from "export all non static functions" to "export only functions with export" keyword might have caused this. But I am not 100% sure honestly.

• Output changes: it is really impossible to have stable output all the time. For example, if there is a random session key or IV generated for encryption, the output will be different on different invocations by design.

[reneengelhard]

I see, thanks. While I agree removing MD5 might make sense I'll opt to try to keep the symbols.
Unfortunately --enable-md5 seems to be default according to configure --help but even with an explicit --enable-md5 I still have them missing.

Thinking about it (since it's only nss affected for md5) - If it matters: ii libnss3:amd64 2:3.83-1 amd64 Network Security Service libraries. Maybe nss disabled md5 themselves, "propagating" down to xmlsec1..?

[reneengelhard]

MD5: There is also compile time check to see if the crypto library (e.g. openssl supports it). So changes in OpenSSL might have impacted it as well

Yeah, saw that one, but that one says "yes" (though it checks openssl as that one is the "default crypto library":

[....]
checking for default crypto library... yes ("openssl")
checking for MD5 support... yes
[...]

)

Thanks so far, though, will look more thouroughly

[lsh123]

Sorry I was traveling and was not able to check this. None of the functions in the list were public (i.e. in the xmlsec includes):

> xmlsec1-1.2.34$ grep -r xmlSecKWAesDecode include/
> xmlsec1-1.2.34$ grep -r xmlSecKWAesEncode include/
> xmlsec1-1.2.34$ grep -r xmlSecKWAesDecode include/
> xmlsec1-1.2.34$ grep -r xmlSecKWAesEncode include/
> xmlsec1-1.2.34$ grep -r xmlSecGnuTLSX509CertBase64DerRead include/
> xmlsec1-1.2.34$ grep -r xmlSecGnuTLSX509CertBase64DerWrite include/
> xmlsec1-1.2.34$ grep -r xmlSecGnuTLSX509CertGetSKI include/
> xmlsec1-1.2.34$

Not sure why exactly they aren't visible in the build anymore but as I said nobody should be affected by this.

Also, the ./configure script that you've mentioned:

checking for MD5 support... yes

is just checking for the flag "--enable-md5" (it's true by default).

Looks like NSS disabled MD5 in 3.27.1 about 5 years ago. Of course, it could have been kept around by the distros longer.