Bug 918156
| Summary: | nss hangs after receiving close_notify alert from vsftpd on FTPS data connection | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kamil Dudka <kdudka> | ||||
| Component: | nss | Assignee: | Elio Maldonado Batiz <emaldona> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Alicja Kario <hkario> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 6.4 | CC: | emaldona, eparis, fkrska, hkario, kdudka, kengert, rrelyea | ||||
| Target Milestone: | rc | Keywords: | Patch | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | nss-3.16.1-2.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1037606 (view as bug list) | Environment: | |||||
| Last Closed: | 2014-10-14 05:02:34 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 895339, 994246, 1037606, 1056252 | ||||||
| Attachments: |
|
||||||
|
Description
Kamil Dudka
2013-03-05 15:37:34 UTC
Filip, in the Fedora clone of this bug, you have reported the bug can no longer be reproduced using 3.15.4 Kamil, because you have originally reported this bug, can you confirm the issue is fixed with 3.15.4? If it does, that's another reason to rebase. Maybe you could test once Elio has a scratch build. Also: Should you find that NSS 3.15.4 indeed fixes the issue, it would be nice if the upstream bug mentioned in comment 7 (which Miloslav had filed originally) has gone away. Maybe some recent change in NSS 3.15.4 had the side effect to fix it? (In reply to Kai Engert (:kaie) from comment #10) > Kamil, because you have originally reported this bug, can you confirm the > issue is fixed with 3.15.4? If it does, that's another reason to rebase. Rebases are cool. Still I would like to see what the fix actually is. Using git-bisect, we are able to easily find the exact commit that fixed (or broke) something in projects like curl. Is something like that possible with nss? (In reply to Kamil Dudka from comment #12) > Still I would like to see what the fix actually is. Are you able to confirm that Filip is correct, and that the issue is indeed fixed? (In reply to Kai Engert (:kaie) from comment #13) > Are you able to confirm that Filip is correct, and that the issue is indeed > fixed? I already confirmed that the bug no longer occurs on Fedora 20: bug #1037606 comment #7 I did not verify that it was a nss update what fixed it. Even if it did, it does not mean that the fix will work on RHEL-6. We really need to understand the change better before making such conclusions. (In reply to Kamil Dudka from comment #14) > I already confirmed that the bug no longer occurs on Fedora 20: ok, thanks. > I did not verify that it was a nss update what fixed it. Even if it did, it > does not mean that the fix will work on RHEL-6. We really need to > understand the change better before making such conclusions. If you want to rule out the possibility that any other package could potentially be responsible for the bugfix: Could you downgrade your NSS package to an older version and check if it reintroduces the bug? Once we know for sure it is NSS, we should find out which version of NSS is the first one to fix it. Did it get fixed between 3.15.3 and 3.15.4? Once we know that, we can look at the list of bugs fixed between those NSS versions. (In reply to Kai Engert (:kaie) from comment #15) > Could you downgrade your NSS package to an older version and check if it > reintroduces the bug? At the first glance, it does not. I still cannot see curl hanging on f20 with: libcurl-7.32.0-4.fc20.x86_64 nss-3.15.2-3.fc20.x86_64 vsftpd-3.0.2-6.fc20.x86_64 (In reply to Kamil Dudka from comment #16) > (In reply to Kai Engert (:kaie) from comment #15) > > Could you downgrade your NSS package to an older version and check if it > > reintroduces the bug? > > At the first glance, it does not. I still cannot see curl hanging on f20 > with: > > libcurl-7.32.0-4.fc20.x86_64 > nss-3.15.2-3.fc20.x86_64 > vsftpd-3.0.2-6.fc20.x86_64 Strange, perhaps the server side vsftpd version matters as well. But in my case: Server side: vsftpd-2.2.2-11.el6_4.1.x86_64 Client side: curl-7.32.0-3.fc20.x86_64 Client command: curl -klsv --ftp-ssl-reqd ftp://rhel62/pub/ With nss-*3.15.3.1-1.fc20.x86_64 on client side and older the hang reproduces With nss-*3.15.4-1.fc20.x86_64 on client side no hang after retrieving the list No other changes than update/downgrade of nss nss-tools nss-sysinit packages on client were performed. Kai, could you look at the list of bugs fixed between those NSS versions? Is the rebase probable regardless of identifying the fix? (In reply to Filip Krska from comment #18) > With nss-*3.15.3.1-1.fc20.x86_64 on client side and older the hang reproduces > With nss-*3.15.4-1.fc20.x86_64 on client side no hang after retrieving the > list > > No other changes than update/downgrade of nss nss-tools nss-sysinit packages > on client were performed. > > Kai, could you look at the list of bugs fixed between those NSS versions? There were a lot of changes between 3.15.3.1 and 3.15.4 Upstream release notes: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.15.4_release_notes List of bugs fixed upstream: https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&classification=Components&query_format=advanced&target_milestone=3.15.4&product=NSS&list_id=10434063 Many of the changes were related to SSL/TLS. There's even one bugfix that talks about a hang with one particular hardware (923696). > Is the rebase probable regardless of identifying the fix? I assume RHEL 6.6 will get a rebase to NSS 3.16.1 because that's required for Firefox 31. (In reply to Kamil Dudka from comment #12) > Using git-bisect, we are able to easily find the exact commit that fixed (or > broke) something in projects like curl. Is something like that possible > with nss? The "hg" system used by the upstream NSS repository also offers the bisect command, it seems. But it would still be quite a lot of work to create NSS RPM builds and identify the change that caused the problem. I wouldn't invest that work, unless you're still able to reproduce the issue with the most recent NSS. Are you able to test the issue with the recent NSS 3.16.1 packages that Elio recently built for RHEL 6.6? Thanks to Hubert who provided automated tests. We ran the test four times, and all suceeded. I think we can conclude this issue has been fixed. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1378.html |