Bug 1102127
| Summary: | tor: security update | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vasyl Kaigorodov <vkaigoro> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | carnil, jorti, pfrields, pwouters, s |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | tor 0.2.4.22 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-03 14:32:24 UTC | Type: | --- |
| 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: | 1102132, 1102134, 1102136 | ||
| Bug Blocks: | |||
|
Description
Vasyl Kaigorodov
2014-05-28 14:26:33 UTC
Created tor tracking bugs for this issue: Affects: fedora-all [bug 1102132] Affects: epel-all [bug 1102136] Created tor-arm tracking bugs for this issue: Affects: fedora-all [bug 1102134] (In reply to Vasyl Kaigorodov from comment #2) > Created tor-arm tracking bugs for this issue: > > Affects: fedora-all [bug 1102134] tor-arm is not the same thing as tor, so it would not be vulnerable to this. It's a monitor for tor, not tor itself. The link given in the bugzilla is a comment from OpenSUSE packager that hasn't cited any sources. I am not aware of any official message from upstream that 0.2.3.25 is deprecated. The Tor network still has many nodes running 0.2.3.25 and they have not been removed from the Tor directory list. There are no known vulnerabilities in Tor related to Heartbleed, other than the fact that some nodes ave been blacklisted that *may* have had their private key compromised. The Heartbleed related patches add blacklist logic (client-side) to ignore nodes with keys that may have been compromised. There are 9 keys in this blacklist. These patches have been backported to the 0.2.3 branch and I imagine there will be a 0.2.3.26 release at some point. Our options are: 1) Update to 0.2.4.22 on all branches 2) Remain at 0.2.3.25 but use the backported patches 3) Do nothing and wait for 0.2.3.26 release I'm tempted to update to 0.2.4.22 on all branches. I expect the 0.2.3.x branch will be deprecated by upstream long before RHEL 6 is EOL, or even before End of Production 1 Phase, so it may be inevitable that we will need to update Tor beyond 0.2.3.x branch. On the other hand, the Fedora packager side of me wants to adhere to packaging policy and avoid major version bumps. This is why I haven't updated to 0.2.4.22 on all branches as yet. Were it not for our update policy, I would have updated already. Co-maintainer Paul Wouters is discussing with upstream to ask best action to take. I'm awaiting Paul's response. Also, my assessment above may not be correct. Paul or upstream do not necessarily share the same view. I'm happy to be overridden by a Proven Packager in the meantime (all that is needed is a merge from f21 to all branches). I understand that this package is very sensitive, so that's why I'm getting advice from Paul and upstream before doing anything. (In reply to Jamie Nguyen from comment #4) > The link given in the bugzilla is a comment from OpenSUSE packager that > hasn't cited any sources. > > I am not aware of any official message from upstream that 0.2.3.25 is > deprecated. The Tor network still has many nodes running 0.2.3.25 and > they have not been removed from the Tor directory list. > > There are no known vulnerabilities in Tor related to Heartbleed, > other than the fact that some nodes ave been blacklisted that *may* have > had their private key compromised. The Heartbleed related patches add > blacklist logic (client-side) to ignore nodes with keys that may have been > compromised. There are 9 keys in this blacklist. These patches have been > backported to the 0.2.3 branch and I imagine there will be a 0.2.3.26 > release at some point. > > Our options are: > > 1) Update to 0.2.4.22 on all branches This is really the only good option IMO, despite the fact that lots of people are uncomfortable with it because of the way packaging guidelines work. Tor doesn't really provide an ABI which is consumed by other projects throughout the distro so I wouldn't worry too much about breaking ABI. > 2) Remain at 0.2.3.25 but use the backported patches There's really no way to viably do this. 0.2.3.x was released almost two years ago at this point so there'd be a number of patches which would need backport. Seems like a lot of work for no gain over the first option. > 3) Do nothing and wait for 0.2.3.26 release Is there actually going to be a 0.2.3.26 release? > > I'm tempted to update to 0.2.4.22 on all branches. I expect the 0.2.3.x > branch will be deprecated by upstream long before RHEL 6 is EOL, or even > before End of Production 1 Phase, so it may be inevitable that we will > need to update Tor beyond 0.2.3.x branch. > > On the other hand, the Fedora packager side of me wants to adhere to > packaging policy and avoid major version bumps. This is why I haven't > updated to 0.2.4.22 on all branches as yet. Were it not for our update > policy, I would have updated already. > > Co-maintainer Paul Wouters is discussing with upstream to ask best action to > take. I'm awaiting Paul's response. tor-0.2.4.22-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. tor-0.2.4.22-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. tor-0.2.4.22-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. |