Closed kloczek closed 6 months ago
What version of NSS do you use? The error code (-8011) is SEC_ERROR_SIGNATURE_ALGORITHM_DISABLED. Likely your linux distro decided to disable SHA1. You should check your policy configs (e.g. check this link: https://linux.extremeoverclocking.com/man/1/nss-policy-check)
On xmlsec side, it should be possible to detect if a specific algo is disabled by NSS and not even enable it in xmlsec (thus skipping these tests). I will look into this a little bit later - it doesn't look very critical.
Note: it can be key size as well (i.e. tests might use smaller key size than it is allowed on the system):
Sorry missed this
(I'm using openssl 3.1.4)
And if you don't care about NSS, then you can just disable it with
./configure --without-nss [other options]
What version of NSS do you use?
3.94.0
@klocze Any chance you can try PR #734 in your environment? Expected result is that the tests are skipped and not failing
One sec ..
Cannot apply that PR on top of 1.3.2 + ffb32737
+ cd xmlsec1-1.3.2
+ rm -rf /home/tkloczko/rpmbuild/BUILD/xmlsec1-1.3.2/SPECPARTS
+ /usr/bin/mkdir -p /home/tkloczko/rpmbuild/BUILD/xmlsec1-1.3.2/SPECPARTS
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ /usr/lib/rpm/rpmuncompress /home/tkloczko/rpmbuild/SOURCES/xmlsec1-Fix-libxml2-v2.12.0-includes-729.patch
+ /usr/bin/patch -p1 -s --fuzz=0 --no-backup-if-mismatch -f
+ /usr/lib/rpm/rpmuncompress /home/tkloczko/rpmbuild/SOURCES/xmlsec1-xmlsec-nss-Added-runtime-check-for-the-enabled.patch
+ /usr/bin/patch -p1 -s --fuzz=0 --no-backup-if-mismatch -f
1 out of 1 hunk FAILED -- saving rejects to file docs/index.html.rej
Thank you for the test! Back to drawing board.
Glad to be able help 😋
@kloczek sorry to bug you but I can't reproduce this with nss 3.94.0, might be some config on your machine. I've updated the PR #734 with one more try -- any chance you can test it on your box? same issue with docs that might not apply clean if it is not master.
Also, what is the OS you use? May be I can try to repro if I get the exact OS right as well, not just nss version.
I was able to reproduce that with nss from Fedora rawhide.
Other way .. if you see any possibility how can I try to make any diagnostics to expose that issue please let me know.
It's some config in NSS that Fedora applied and I have no idea which config is that :)
Note that NSS support so called "crypto policies". It depends how NSS is build and then from host configuration. If I remember well with level set to future SHA1 is not acceptable.
Also regression / unit test could bypass those settings with an environment variable.
I got it reproduced with Fedora, seems like it is based on the key size limits so my patch didn't help (it was looking at algorithm). I will see if there are other options to fix those tests.
Note that NSS support so called "crypto policies". It depends how NSS is build and then from host configuration. If I remember well with level set to future SHA1 is not acceptable.
Fedora nss is not patched to use central host crypto policies https://src.fedoraproject.org/rpms/nss/blob/rawhide/f/nss.spec#_129
Tomasz KÅ‚oczko wrote:
Note that NSS support so called "crypto policies". It depends how NSS is build and then from host configuration. If I remember well with level set to future SHA1 is not acceptable.
Fedora nss is not patched to use central host crypto policies https://src.fedoraproject.org/rpms/nss/blob/rawhide/f/nss.spec#_129
Patched vs enabled?
May be this is related, quote from nss.spec: ....
export POLICY_FILE="nss.config"
export POLICY_PATH="/etc/crypto-policies/back-ends" ....
Roumen
Yep, exactly. Anyway, there is a way to disable all of this: PR #744. It works for me on Fedora (you need to install nss-tools
package as well though, no idea why Fedora splits everything in tiny packages).
I am going to close this issue since I cannot reproduce the failures on Fedora rawhide anymore with PR #744. Please re-open if it is still broken for you.
1.3.2 fails with latest libxml 2.12.x and as fix for that issue is already committed IMO it would be good to release new version.
BTW is it possible to change tagging convention from xmlsec_<version_with_underscores>
to just <version.with.dots>
? 🤔
Autogenerated from git tag tar ball has inside base directory formed out of <repo_name>-<git_tag>
so autogenerated from git tag tar ball https://github.com/lsh123/xmlsec/releases/download/xmlsec-1_2_39/xmlsec1-1.2.39.tar.gz has inside base directory xmlsec-xmlsec-1_2_39
and dist tar ball https://github.com/lsh123/xmlsec/releases/download/xmlsec-1_2_39/xmlsec1-1.2.39.tar.gz is not easy available because actual tag is using version string with underscores.
BTW it is not necessary to use separated dist tar ball signature as autogenerated can be signed using native github signs https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-tags And yet another link to github documentation: https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits
1.3.2 fails with latest libxml 2.12.x and as fix for that issue is already committed IMO it would be good to release new version.
Yeah, I was thinking about it since I just got 1.2.39 out for similar reasons.
BTW is it possible to change tagging convention...
I just have this system for ages and want to keep it consistent. I am not using github for generating tarballs anyway
So I am going to do two tags (old and new one) for a little bit. I published 1.3.3-rc1-- please try it out and let me know if you see any issues!
just have this system for ages and want to keep it consistent. I am not using github for generating tarballs anyway
Always it is possible to rename old tags as well 😋
Looks like test suite still fails. (I'm using openssl 3.1.4)