Description of problem: fedpkg new-sources hangs Version-Release number of selected component (if applicable): 3.14-1 How reproducible: Always Steps to Reproduce: 1. install nss 3.14-1 2. fedpkg clone <packagename> 3. cd packagename 4. fedpkg new-sources file.tar.gz hang Workaround: yum downgrade nss nss-utils fixes the problem instantly.
What version of libcurl are you using? $ rpm -q libcurl
libcurl-7.27.0-3.fc19.x86_64 for me on rawhide where I can observe the same problem.
[dan@localhost ~]$ rpm -qa libcurl libcurl-7.27.0-4.fc18.x86_64
I think I know the cause, when I nerged from master into f18 I din't to reenable a patch patch in spec file as I should have. $ grep cbc nss.spec Patch29: nss-ssl-cbc-random-iv-off-by-default.patch $ grep patch29 nss.spec #%patch29 -p0 -b .770682 A build with the patch reactivated is coming soon.
I have tagged nss-3.14-3.fc18 into the f18 buildroot override. Dan, could you please confirm that 'fedpkg new-sources' now works? Thanks.
Bad news, though the changes are needed they don't fix the bug. I created a dummy sources test file so I can upload it and thus verify that the nss build no longer causes a hang in fedpkg 'new-sources' or 'fedpkg update'. When I tried it" $ fedpkg upload dummy-sources-for-testing Uploading: 90921e15a47f5c935a7c13bb4b3d2349 dummy-sources-for-testing ... It still hangs! The problem is somewhere else.
Until I have a fix it's now unpushed from updates-testing.
Thank you for your prompt attention to this matter.
I am afraid that F18 is broken anyway :( http://koji.fedoraproject.org/koji/taskinfo?taskID=4648975
Probably this override should be expired? https://admin.fedoraproject.org/updates/override/edit?build=nss-3.14-3.fc18&_csrf_token=d68928de14fdd93a7f448ba288a48776060f3578
(In reply to comment #4) > Patch29: nss-ssl-cbc-random-iv-off-by-default.patch This could hardly take an effect because libcurl controls this explicitly by calling SSL_OptionSet(model, SSL_CBC_RANDOM_IV, ...). (In reply to comment #6) > Bad news, though the changes are needed they don't fix the bug. I created a > dummy sources test file so I can upload it and thus verify that the nss > build no longer causes a hang in fedpkg 'new-sources' or 'fedpkg update'. > When I tried it" > > $ fedpkg upload dummy-sources-for-testing > Uploading: 90921e15a47f5c935a7c13bb4b3d2349 dummy-sources-for-testing I am not sure if a real upload is necessary. The following minimal example also fails with the new version of nss: curl -svo/dev/null \ --cert $HOME/.fedora.cert \ --cacert $HOME/.fedora-upload-ca.cert \ 'https://koji.fedoraproject.org/koji/login' I suspect that handling of client certificates is somehow broken.
This is a double lock PK11_Sign(). I am looking how to fix it... 747│ session = pk11_GetNewSession(slot,&owner); 748│ if (!owner || !(slot->isThreadSafe)) PK11_EnterSlotMonitor(slot); 749│ crv = PK11_GETTAB(slot)->C_SignInit(session,&mech,key->pkcs11ID); 750│ if (crv != CKR_OK) { 751│ if (!owner || !(slot->isThreadSafe)) PK11_ExitSlotMonitor(slot); 752│ pk11_CloseSession(slot,session,owner); 753│ PORT_SetError( PK11_MapError(crv) ); 754│ return SECFailure; 755│ } 756│ /* PKCS11 2.20 says if CKA_ALWAYS_AUTHENTICATE then 757│ * do C_Login with CKU_CONTEXT_SPECIFIC 758│ * between C_SignInit and C_Sign */ 759├> if (SECKEY_HAS_ATTRIBUTE_SET(key,CKA_ALWAYS_AUTHENTICATE)) { 760│ PK11_DoPassword(slot, PR_FALSE, key->wincx, PR_TRUE); 761│ }
I meant a double _in_ PK11_Sign(), of course. Is the indentation broken intentionally to highlight the location of the bug?
(In reply to comment #10) I expired the override. I hope you don't mind. It should contain all of nss, nss-softokn and nss-utils. But since it seems that nss-3.14-3.fc18 is not the "right" version anyway, I hope it is OK and I'll be able to build my packages.
Created attachment 637038 [details] proposed fix
Comment on attachment 637038 [details] proposed fix It makes a lot of sense to me, exit the monitor once you sign always -not just just error and enter always before signing. Thank you Kamil.
Comment on attachment 637038 [details] proposed fix r- Kamil had definitely identified the real problem. PK11_EnterSlotMonitor is poorly named, since it implies a monitor, not a lock (monitors allows the same thread to enter it twice). Unfortunately the fix needs to be more complex. Doug Ebert's patch (https://bugzilla.mozilla.org/show_bug.cgi?id=357025) appearently has 2 problems: 1) we need to login on the session used for signing. 2) we need to make sure we handle locking correctly. I suggest removing the CKA_ALWAYS_AUTHENTICATE line (you can tell the newly added line because the indents are wrong. We have the same problem in pk11_PrivDecryptRaw(). bob
In the mean time, what should someone do who is running F18 who needs to upload new bits into Fedora rawhide?
Nevermind. Just saw the comment about downgrading nss things... Which does the trick just fine.
Created attachment 637191 [details] Fix locking issue. Also authenticate on the correct session
Note that this is also broken in rawhide. I am having the same issue with nss-3.14-7.fc19.
Comment on attachment 637191 [details] Fix locking issue. Also authenticate on the correct session Thank you Bob not only for the patch but also for the various explanations that help me a lot with the review. I have verified, with builds with this patch applied, that 'fedpkg new-sources' and 'fedpkg update' no longer hang on Rawhide and F-18.
Comment on attachment 637191 [details] Fix locking issue. Also authenticate on the correct session Thank you Bob, not just for the fix but for your explanations which helped a lot so I cauld review the patch. Besides the code review, I have verified that this patch does solve the reported problem on both rawhide and f18
nss-softokn-3.14-1.fc18, nss-3.14-5.fc18, nss-util-3.14-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-17351/nss-3.14-5.fc18,nss-softokn-3.14-1.fc18,nss-util-3.14-1.fc18
Package nss-softokn-3.14-1.fc18, nss-3.14-5.fc18, nss-util-3.14-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nss-softokn-3.14-1.fc18 nss-3.14-5.fc18 nss-util-3.14-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17351/nss-3.14-5.fc18,nss-softokn-3.14-1.fc18,nss-util-3.14-1.fc18 then log in and leave karma (feedback).
verified fixed
Package nss-softokn-3.14-1.fc18, nss-util-3.14-1.fc18, nss-3.14-6.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nss-softokn-3.14-1.fc18 nss-util-3.14-1.fc18 nss-3.14-6.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17351/nss-3.14-6.fc18,nss-softokn-3.14-1.fc18,nss-util-3.14-1.fc18 then log in and leave karma (feedback).
Package nss-util-3.14-1.fc18, nss-3.14-7.fc18, nss-softokn-3.14-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nss-util-3.14-1.fc18 nss-3.14-7.fc18 nss-softokn-3.14-5.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17351/nss-3.14-7.fc18,nss-softokn-3.14-5.fc18,nss-util-3.14-1.fc18 then log in and leave karma (feedback).
nss-util-3.14-1.fc17,nss-softokn-3.14-5.fc17,nss-3.14-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/nss-util-3.14-1.fc17,nss-softokn-3.14-5.fc17,nss-3.14-7.fc17
nss-util-3.14-1.fc18, nss-3.14-7.fc18, nss-softokn-3.14-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
nss-util-3.14-1.fc17, nss-softokn-3.14-5.fc17, nss-3.14-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.