| luis220413 | I would like to prepare a security update for Tor but the 0.4.2 series, to which the version in Focal belongs, is no longer supported upstream. For Bionic I will package 0.3.5.18. | 20:29 |
|---|---|---|
| luis220413 | Note that Trisquel has regular updates for Tor: https://ftp.caliu.cat/pub/distribucions/trisquel/packages/pool/main/t/tor/ | 20:29 |
| luis220413 | Trisquel is a Ubuntu derivative without any nonfree software. | 20:30 |
| Unit193 | Pretty sure the bionic version will no longer really be useful. Depending on the version, obfs4proxy would be a good candidate too for jammy. | 20:34 |
| luis220413 | Looking at the Trisquel repositories, I will package version 0.4.7.8 to Bionic, Focal and Jammy as an SRU. | 20:37 |
| luis220413 | Unit193: OK, I will also package obfs4proxy if there are vulnerabilities or other major bugs. | 20:40 |
| Unit193 | It's golang, needed new stuff, sooo... | 20:44 |
| Unit193 | !info obfs4proxy jammy | 20:45 |
| ubottu | obfs4proxy (0.0.13-1, jammy): pluggable transport proxy for Tor, implementing obfs4. In component universe, is extra. Built by obfs4proxy. Size 1,871 kB / 5,433 kB | 20:45 |
| Unit193 | .13 is fine, actually. | 20:45 |
| luis220413 | Unit193: 0.3.5 seems not to be supported upstream. | 20:53 |
| luis220413 | Tor 0.3.5 | 20:54 |
| rbasak | luis220413: just because something isn't supported upstream doesn't automatically disqualify it from receiving a cherry-pick. The norm is for upstreams not to have any specific support promises for the vast majority of packages anyway. | 20:55 |
| rbasak | And yet distributions patch their packages for security updates normally by cherry-picking. | 20:55 |
| Unit193 | rbasak: The difference here is that it's privacy focused software, and needs to connect to the Tor network. | 20:56 |
| rbasak | Yeah so if that's a reason to need a major version bump then that's fine. | 20:56 |
| rbasak | But then that would be the justification, not "not supported upstream". | 20:56 |
| rbasak | "Updates that need to be applied to Ubuntu packages to adjust to changes in the environment, server protocols, web services, and similar, i. e. where the current version just ceases to work." - but that's an exception available should it be required. Not the norm, especially when a cherry-pick would work. | 20:58 |
| rbasak | (from https://wiki.ubuntu.com/StableReleaseUpdates#High-impact_bugs) | 20:58 |
| rbasak | "Not supported upstream" is starting to trigger me. It's not a justification. That would be the cart leading the horse. | 20:59 |
| luis220413 | rbasak: Ignore that. A good justification is that protocol changes require Tor to be updated (and it is even explicitly listed in that wiki page) | 20:59 |
| rbasak | luis220413: sure, but to be clear, is Tor actually broken on Focal already because protocol changes have broken it? | 21:00 |
| Unit193 | https://lists.torproject.org/pipermail/tor-relays/2022-March/020446.html - https://lists.torproject.org/pipermail/tor-relays/2022-March/020447.html - https://lists.torproject.org/pipermail/tor-relays/2022-April/020470.html for some useful mailing list posts. | 21:01 |
| luis220413 | rbasak: That will require deeper testing. | 21:02 |
| luis220413 | rbasak: Is there an exception to allow upgrades to the latest upstream release for Tor? | 21:02 |
| luis220413 | Unit193: OK. Should I proceed with the upgrade to 0.4.7.8 for all Ubuntu releases? | 21:04 |
| rbasak | luis220413: not specifically, though Tor is an example given in the policy. I think you'd still need to demonstrates that the tor package no longer work, or will shortly stop working, or has some similar major flaw, when connecting to the Tor network. | 21:04 |
| rbasak | So if for example there's an upstream schedule with a deadline for rejecting that version of the Tor client, then that might be reasonable. | 21:05 |
| luis220413 | rbasak: See bug 1837793 | 21:05 |
| ubottu | Bug 1837793 in tor (Ubuntu) "This version of Tor (0.3.2.10) is not recommended" [Undecided, In Progress] https://launchpad.net/bugs/1837793 | 21:05 |
| Unit193 | luis220413: At the very least a backport, I'd say. Given how terrible Ubuntu's rep is in the Tor community, it can't hurt to get *something* *somewhere*. | 21:05 |
| rbasak | However, if upstream routinely runs a schedule that makes it impossible to keep up with for the lifetime of an Ubuntu release, perhaps it'd be better to remove Tor from the (deb) archive entirely and rely on snaps or something. | 21:06 |
| rbasak | IMHO, "not recommended" isn't really good enough. So many upstreams make that claim nowadays, when really they just disagree fundamentally with distribution's stable release policies. | 21:07 |
| luis220413 | rbasak: It is maintainable for the lifetime of an Ubuntu release. See https://ftp.caliu.cat/pub/distribucions/trisquel/packages/pool/main/t/tor/ (repository of an Ubuntu derivative, maintained for the LTS period) and bug 1982224 for my SRU (without patches). | 21:07 |
| ubottu | Bug 1982224 in tor (Ubuntu) "[SRU] Upgrade to 0.4.7.8 for Bionic, Focal and Jammy" [Undecided, New] https://launchpad.net/bugs/1982224 | 21:07 |
| rbasak | OTOH if there's some specific reason that it needs updating, like some specific vulnerability or threat that can be articulated directly, then SRU policy already allows a major version bump. | 21:08 |
| rbasak | I suppose what I really object to here is tenuous claims of "not recommended" or "not supported" instead of specific technical reasons such as "CVE-2022-XYZ" or "the protocol change X was made for reasons Y which means clients older than Z will no longer work with the network". | 21:09 |
| rbasak | Maybe Tor should have a further exception because of its nature. That's be up to the TB and SRU teams to figure out I guess. | 21:10 |
| rbasak | That would raise questions about the best place for the package (main archive vs. backports vs. snaps) and who would maintain it and how, etc. | 21:10 |
| sarnold | eg https://bugs.launchpad.net/ubuntu/+source/bitcoin/+bug/1260602 was when bitcoin was removed, because it could no longer participate in the network | 21:11 |
| ubottu | Launchpad bug 1260602 in bitcoin (Ubuntu) "bitcoin should be removed from the archive (and blacklisted)" [Medium, Fix Released] | 21:11 |
| rbasak | To be clear, if there's an urgent need because of a security issue or it completely breaking against a protocol change, then we already make an exception. | 21:12 |
| rbasak | But I would expect the security team to require a cherry-pick if that's feasible. | 21:12 |
| sarnold | that's definitely preferred, yes | 21:12 |
| luis220413 | rbasak, sarnold: There are 11 CVEs in this source package marked as unfixed in the Ubuntu CVE Tracker. | 21:13 |
| Unit193 | The newer version is supposed to mitigate a DoS attack, so...sort of yeah. | 21:13 |
| rbasak | And I'm not sure if "contributor prefers major version bump over a feasible cherry-pick" is a reasonable justirication, even if we do value the contribution. | 21:13 |
| sarnold | luis220413: yeah, as Unit193 said, no one's been tending to this one.. | 21:13 |
| Unit193 | luis220413: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SupportPolicy might be useful reading too. | 21:14 |
| Unit193 | https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases has the support status. | 21:15 |
| luis220413 | I will return in 15 minutes. | 21:17 |
| Unit193 | FWIW, Tor is very good about supporting older distro releases, it's one of the only packages in buster-backports-sloppy and whatnot. Anywho, hopefully I didn't derail the discussion with links. | 21:18 |
| rbasak | Links are useful! | 21:19 |
| rbasak | Especially if this leads to a request for a wider exception. | 21:19 |
| rbasak | And to be clear, I welcome such a discussion. The above is both my view and I think mostly the view of the project, but contributors are welcome to seek to change it | 21:20 |
| Unit193 | I sure wouldn't mind helping out there, I'm fond of Tor (I run 4 relays.) | 21:20 |
| Unit193 | rbasak: -backports is a lot easier, but I have no idea if users know how to use it, and I don't think there's any data on that at all. :/ | 21:21 |
| rbasak | One issue with backports is that it's opt-in, and requires the package to be in the development release, which means it'd make it into stable releases. | 21:21 |
| rbasak | So users would end up using the not-backports package by default, which I think is undesirable here? | 21:22 |
| rbasak | If tor were only in backports and not in Ubuntu releases, then that would work, but currently I think that's against backports policy for a bunch of quality reasons that we probably don't want to break. | 21:22 |
| Unit193 | Not in the case of Tor, no. Some usage data could be nice, but that type of tracking is generally not preferred. :P | 21:26 |
| luis220413 | I have returned. | 21:31 |
| luis220413 | rbasak: There is a specific technical reason. From the first mailing list post: "Alright, I just pushed a commit to get relays rejected by fingerprint which are still running an unsupported Tor version" and "We'll run further rejection rounds in the coming weeks to deal with new relays/bridges popping up with unsupported Tor versions." | 21:39 |
| luis220413 | rbasak: I believe Tor should have a further exception, if it does not meet the bulleted requirements in https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases | 21:40 |
| luis220413 | sarnold: If a volunteer is available to maintain bitcoin, it can return to the Ubuntu repositories. See my 2 comments in bug 1862002 (for another Bitcoin-related package) | 21:46 |
| ubottu | Bug 1862002 in electrum (Ubuntu) "[needs-packaging] Please sync electrum from Debian Sid" [Wishlist, Confirmed] https://launchpad.net/bugs/1862002 | 21:46 |
| luis220413 | rbasak: As mentioned in the first mailing list post, the Tor network excludes relays based on the reported version of Tor. Reporting a higher version when cherry-picking fixes would create false expectations in the Tor network, and therefore a regression. | 21:49 |
| luis220413 | rbasak, sarnold: Can I proceed with the update to 0.4.7.8 for all stable releases? It fixes 11 CVEs and this fatal bug for relays in Bionic and Focal. | 21:50 |
| luis220413 | sarnold: Can you (or another member of the security team) triage CVEs in Tor? | 21:52 |
| luis220413 | Such that I can go to the Tracker (the CVE pages on ubuntu.com have been with problems in the last weeks) and see which CVEs are fixed by the new upstream release for each Ubuntu release. | 21:53 |
| luis220413 | Unit193: "The newer version is supposed to mitigate a DoS attack, so...sort of yeah." What DoS attack? | 22:06 |
| Unit193 | TROVE-2022-001 - CVE-2022-33903 | 22:09 |
| ubottu | Tor 0.4.7.x before 0.4.7.8 allows a denial of service via the wedging of RTT estimation. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33903> | 22:09 |
| luis220413 | Unit193: This CVE is fixed by my SRU | 22:10 |
| Unit193 | Yes. | 22:10 |
| luis220413 | rbasak, sarnold: Can I proceed with the update to 0.4.7.8 for all stable releases? It fixes 11 CVEs and this fatal bug for relays in Bionic and Focal. | 22:10 |
| luis220413 | I will leave now but I will see your replies in this channel's logs. | 22:11 |
| Unit193 | No version of Ubuntu ships the affected Tor for that specific CVE, note it's for 0.4.7.x and Jammy has 0.4.6.10. | 22:12 |
| sarnold | luis220413: for a version jump like that, rather than targetted updates, we'd probably rather prefer the package go through the SRU process and be copied to -security after it's gotten more scrutiny | 22:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!