Hide Forgot
Description of problem: At least, not how it's used for 'make upload'. Example: curl -k --cert <your fedora cert> --fail -F name=<some package> -F md5sum=<some md5sum> -F filename=<some file> https://cvs.fedoraproject.org/repo/pkgs/upload.cgi With 7.16.4-2.fc8 (openssl) this works. With 7.16.4-3.fc8 (NSS) this fails with a 403 error. Version-Release number of selected component (if applicable): 7.16.4-3.fc8 How reproducible: Every time! Marking as Fedora 8 blocker since it makes building new packages hard. CC'ing nss maintaner.
The problem could be caused by the fact, that curl is still configured to use /etc/pki/tls/certs/ca-bundle.crt, is there an equivalent cert bundle provided by nss? If yes, we can switch to use that one. Daniel, is there needed to do something special except this to make the curl nss support work as expected? I can revert the nss switch immediatelly to make the source uploading work again until we manage to make the nss support work.
Rob Crittenden of Redhat is the one who brought the NSS support to (lib)curl and I bet he knows far more than me about particular details such as this. AFAIU, NSS uses a ca cert database file somewhere...
NSS uses its own cert db format. The workaround is (you need certutil and pkcs12util for that): Create .nss subdir in your home: mkdir ~/.nss Init NSS db there (if you enter a password you'll need to add it to curl command line): certutil -N -d ~/.nss Convert .fedora.cert to PKCS12 format: openssl pkcs12 -export -in .fedora.cert -out .fedora.p12 -n <nickname> Import PKCS12 into the NSS db: pk12util -i .fedora.p12 -d ~/.nss curl -k --cert <nickname> --cacert ~/.nss ... If you initialized the NSS db with a password you'll have to add '--pass <the password>' to the curl command line.
So basically - curl+NSS does work, but differently.
(In reply to comment #3) > openssl pkcs12 -export -in .fedora.cert -out .fedora.p12 -n <nickname> There is typo here - the last option is -name <nickname>
But requiring all of this means that curl has incompatibly changed with the switch to nss. And not for users of the libcurl API (which would be bad, but not unheard of), but instead for people using the command-line program. Which kind of sucks
I agree that it sucks. The problem with OpenSSL->NSS conversion is that the philosophy behind the two libraries is quite different so it is pretty hard to make the ported apps to behave in 100% compatible way. The dependence on NSS cert db is something which simply cannot be removed without thorough rewriting of NSS. For loading the client cert from PEM file there is a PKCS#11 module in the works but I don't know what is its current status and whether it will make it 100% compatible with the OpenSSL way of loading client certs. Also for the FIPS-140-2 Level 2 certification to be still valid there might be some restrictions as to whether this mentioned module would be allowed or not.
We should have a version of libcurl+nss that works with PEM files shortly. We already solved the problem generally in nss_compat_ossl. Libcurl did the conversion directly, though. bob
The nss patch which was applied in curl-7.16.4-3.fc8 has also caused a program of mine to stop working properly. This program uses libcurl to retrieve a gzip-compressed http:// url, but the decoding of the gzip data fails since curl-7.16.4-3.fc8. libcurl only returns the compressed data instead of the expected decompressed data.
I reverted the default to use NSS back to OpenSSL to avoid breakages. We can reenable it as soon as curl users will be prepared for it and a clear HOWTO will be present. I'm letting this bug open to track any changes in the NSS curl support so that it could be enabled later.
For comment #9 if you aren't using SSL then this change should not affect you. I have 2 SRPMS ready for testing. This requires some changes to the nss package to incorporate the PKCS#11 module needed for importing PEM files. I also wrote a patch against the curl NSS module to change the command-line to load the PKCS#11 module and import PEM files. It should also work if you have an existing NSS database and certificates/keys. You can get the two SRPMS from: http://rcritten.fedorapeople.org/files/ To test the Fedora infrastructure once you've built and installed these, find or create a file you want to upload to your project. In my case this is nss_compat_ossl. Do an md5sum of the file, then run something like: curl -k --cert ~/.fedora.cert --fail -F "name=nss_compat_ossl" -F "md5sum=1dcca23355272056f04fe8bf20edfce0" -F "file=@test" https://cvs.fedoraproject.org/repo/pkgs/upload.cgi Here I'm uploading to nss_compat_ossl the file "test" with an md5sum of 1dcca23355272056f04fe8bf20edfce0. The @ before the filename is important. I tested with the -v argument to curl to get more output. You have to use the -k argument because: 1. You probably don't have the CA that signed the cert installed 2. The certificate is expired (April 5, 2006!) 3. The CN of the certificate is cvs.fedora.redhat.com, not cvs.fedoraproject.org
Packages built in koji that address the problem: nss-3.11.7-9 http://koji.fedoraproject.org/koji/buildinfo?buildID=18013 curl-7.16.4-5 http://koji.fedoraproject.org/koji/buildinfo?buildID=18049
Closing RAWHIDE as the NSS support in curl shouldn't break things and it's enabled now. Please reopen if you see something odd with curl related to NSS.
*** Bug 570231 has been marked as a duplicate of this bug. ***