Learn more about these different git repos.
Other Git URLs
Building of the same src.rpm passed on fedora 27
build.log:
Running test 001-keyiread... OK Running test 001-keyiread-rsa... OK Running test 002-keygen... FAIL --- expected.out 2018-01-03 00:00:03.000000000 +0100 +++ actual 2018-01-03 12:27:27.968082336 +0100 @@ -44,9 +44,9 @@ keyi4096 keyi4096 (candidate (next)) [nss:rosubdir] -Failed to save NSS:${tmpdir}/rosubdir: need fs permissions. +Failed to save NSS:${tmpdir}/rosubdir, don't know why. [nss:rwsubdir] -Failed to save NSS:${tmpdir}/rwsubdir: need fs permissions. +Failed to save NSS:${tmpdir}/rwsubdir, don't know why. [openssl:1024] OK. OK (RSA:1024). make[1]: *** [Makefile:1085: check] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/certmonger-0.79.5/tests' make: *** [Makefile:460: check-recursive] Error 1
I suspect this is related to rawhide switching the default NSS database type to sqlite.
I can see where it is failing, I think, but not why.
I think it is failing to detect or translate bad permissions into something certmonger can properly grok.
Metadata Update from @rcritten: - Issue assigned to rcritten
Have run into a potentially serious issue in test 030-rekey and the sqlite database.
The certsave code isn't working as expected. It adds the new certificate ok but the private key for that cert is either being removed or not being added.
It does seem to be properly cleaning up old certs with the same nickname.
It is failing NSS Shutdown, likely due to a dangling reference somewhere. This also happens in the dbm case so it may not be critical but it could also be masking some other issue.
I've narrowed it down a bit by manually running the steps of the test case on an F-27 system and a rawhide system.
Things are fine until the certsave step which is what adds the updated certificate to the database and is supposed to set the trust.
The cert seems to have been added ok but it has no trust, so the issue is either in CERT_ImportCerts() which seems unlikely since the cert is there or in CERT_ChangeCertTrust().
Or it could be related to the shutdown issue where perhaps the database isn't being synced properly.
At least I'm closer, though I have no real reproducer for the NSS team other than modifying the test to stop before certsave to get the environment needed.
The core of the issue is in NSS bug https://bugzilla.redhat.com/show_bug.cgi?id=1532188
CERT_ImportCerts() isn't setting up the keys properly in sqlite databases. Kai has a workaround that look good with initial tests.
The rest of the test issues center around the switch from dbm as the default to sqlite as the default and differences in some return values.
OK feel free to close as invalid/notabug
This is definitely a bug. There were some sql tests in the tree but quite a few were run only against the then-default dbm database. There are real failures to fix.
The NSS bug will be worked around in the short-term.
On (10/01/18 13:15), Rob Crittenden wrote:
This is definitely a bug. There were some sql tests in the tree but quite a few were run only against the then-default dbm database. There are real failures to fix. The NSS bug will be worked around in the short-term.
Thank you for explanation.
LS
@cheimes and I have done some testing in the IPA context and the changes seem to to basically working. At least it doesn't blow up the install any more.
Additional changes may be necessary to make certmonger more flexible when it comes to the database scheme but that will be handled elsewhere.
https://pagure.io/certmonger/pull-request/91
This was resolved but I forgot to close it.
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.