Bug #17531

Upgrade to Tor 0.4.2.7 (TROVE-2020-002, TROVE-2020-004)

Added by intrigeri 2020-03-18 16:36:38 . Updated 2020-03-21 14:17:58 .

Status:
Resolved
Priority:
Elevated
Assignee:
CyrilBrulebois
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description


Subtasks


Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by intrigeri 2020-03-18 16:37:01

#2 Updated by intrigeri 2020-03-18 16:38:17

@CyrilBrulebois, I’ve created this ticket as I would normally do with my FT “frontdesk” hat on. I understand the target version might become 4.4.1.

#3 Updated by CyrilBrulebois 2020-03-19 04:54:48

  • Assignee set to CyrilBrulebois

Yep, thanks.

For the record, 0.4.2.7 packages for buster seem to be available already.

Taking the ticket for the time being, I’ll check what’s happening on the Tor Browser side. But I might start merging Tor into a feature branch for stable shortly (yet another process I haven’t followed yet).

#4 Updated by CyrilBrulebois 2020-03-20 16:07:02

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|20162596347aa4a25a698f3b9e49bb03bc942636.

#5 Updated by CyrilBrulebois 2020-03-21 05:15:16

  • Target version changed from Tails_4.5 to Tails_4.4.1

#6 Updated by CyrilBrulebois 2020-03-21 05:22:09

Jenkins results for the +force-all-tests run:

Failing Scenarios:
cucumber features/usb_install.feature:125 # Scenario: Installing Tails with GNOME Disks from a USB image
cucumber features/usb_install.feature:133 # Scenario: The system partition is updated when booting from a USB drive where a Tails USB image was copied
cucumber features/encryption.feature:34 # Scenario: Symmetric encryption and decryption using OpenPGP Applet
cucumber features/thunderbird.feature:23 # Scenario: Thunderbird can send emails, and receive emails over IMAP

218 scenarios (4 failed, 214 passed)
1629 steps (4 failed, 12 skipped, 1613 passed)
349m22.850s

I’m investigating.

#7 Updated by intrigeri 2020-03-21 08:45:18

Hi!

Just a friendly reminder, as a safety net: we need to bump the expiration date for the snapshot of the “torproject” archive that we’re switching to here (https://tails.boum.org/contribute/APT_repository/time-based_snapshots/#bump-expiration-date) :)

#8 Updated by CyrilBrulebois 2020-03-21 09:01:25

Thanks.

Then if upgrading Tor itself is not just a matter of bumping the snapshot (which I figured out by looking at earlier commits), I think it deserves having a few lines somewhere?

#9 Updated by CyrilBrulebois 2020-03-21 09:23:19

All scenarios failing on Jenkins pass locally.

intrigeri: should I just go ahead and merge the branch myself into stable@ (like I would for e.g. Tor Browser), or am I expected to go through review’n’merge?

#10 Updated by intrigeri 2020-03-21 09:52:43

Hi,

> Then if upgrading Tor itself is not just a matter of bumping the snapshot (which I figured out by looking at earlier commits), I think it deserves having a few lines somewhere?

Sure, this makes sense to me!
Here’s a first iteration: https://tails.boum.org/contribute/tor/ (commit:9f5f7497dd7cc64f6beec809b6b2655b1d08d7e1)
Could you please take a look? If it ends up being more complicated than “LGTM”, I’ll file a dedicated issue to track the next steps.

#11 Updated by intrigeri 2020-03-21 10:08:01

> All scenarios failing on Jenkins pass locally.

:)

> should I just go ahead and merge the branch myself into stable (like I would for e.g. Tor Browser), or am I expected to go through review’n’merge?

In the general case we would go through a review’n’merge but in this case I think we can skip that and you can merge yourself, because:

  • You’re preparing an unscheduled Tails release precisely to get this fix in.
  • It’s a tor bugfix release with minimal changes.
  • The only source change is bumping the APT snapshot.
  • I understand you’ve verified that the impact on the resulting packages list is limited to what we would expect here.

#12 Updated by CyrilBrulebois 2020-03-21 10:21:41

intrigeri wrote:
> Sure, this makes sense to me!
> Here’s a first iteration: https://tails.boum.org/contribute/tor/ (commit:9f5f7497dd7cc64f6beec809b6b2655b1d08d7e1)
> Could you please take a look? If it ends up being more complicated than “LGTM”, I’ll file a dedicated issue to track the next steps.

LPTM, thanks!

#13 Updated by CyrilBrulebois 2020-03-21 10:23:36

intrigeri wrote:
> In the general case we would go through a review’n’merge but in this case I think we can skip that and you can merge yourself, because:
>
> * You’re preparing an unscheduled Tails release precisely to get this fix in.
> * It’s a tor bugfix release with minimal changes.
> * The only source change is bumping the APT snapshot.
> * I understand you’ve verified that the impact on the resulting packages list is limited to what we would expect here.

Yes to all. I probably wouldn’t have suggested that if it hadn’t been a “+1” on the last digit.

[2020-03-20 16:14:51] kibi:
-tor    0.4.2.6-1~d10.buster+1
-tor-geoipdb    0.4.2.6-1~d10.buster+1
+tor    0.4.2.7-1~d10.buster+1
+tor-geoipdb    0.4.2.7-1~d10.buster+1

#14 Updated by CyrilBrulebois 2020-03-21 10:28:40

CyrilBrulebois wrote:
> intrigeri wrote:
> > Sure, this makes sense to me!
> > Here’s a first iteration: https://tails.boum.org/contribute/tor/ (commit:9f5f7497dd7cc64f6beec809b6b2655b1d08d7e1)
> > Could you please take a look? If it ends up being more complicated than “LGTM”, I’ll file a dedicated issue to track the next steps.
>
> LPTM, thanks!

I take that back. :)

I’ll call it “almost perfect” instead: I’ve never needed to bump the expiration date, so I have no idea by how much it should be bumped. Enough to get the release out, and it’s going to be postponed some more during some steps of the release process (that I do mechanically and which results I’m only checking at the very end with the big shell snippet), or a few month to get the appropriate validity period at once?

#15 Updated by intrigeri 2020-03-21 11:07:22

> I take that back. :)

:)

> I’ll call it “almost perfect” instead: I’ve never needed to bump the expiration date, so I have no idea by how much it should be bumped. Enough to get the release out, and it’s going to be postponed some more during some steps of the release process (that I do mechanically and which results I’m only checking at the very end with the big shell snippet), or a few month to get the appropriate validity period at once?

commit:135c97f70474dc56fa481c20dcfe6635830c4406 ← better?

After trying a number of other approaches, this is the simplest way I’ve found to document this: it ensures the branch preserve expiration properties of the torproject snapshot.

#16 Updated by CyrilBrulebois 2020-03-21 12:55:34

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset commit:tails|c51091b5e79fb394b800d695179de76ecb4073f0.

#17 Updated by CyrilBrulebois 2020-03-21 14:10:07

  • File <del>missing: 0001-Add-tip-to-determine-the-right-number-of-days-refs-1.patch</del> added
  • % Done changed from 100 to 0

LGTM; any objection to this extra addition?

#18 Updated by intrigeri 2020-03-21 14:15:03

> File 0001-Add-tip-to-determine-the-right-number-of-days-refs-1.patch added
> LGTM; any objection to this extra addition?

Go ahead!

#19 Updated by CyrilBrulebois 2020-03-21 14:15:44

  • File deleted (0001-Add-tip-to-determine-the-right-number-of-days-refs-1.patch)

#20 Updated by CyrilBrulebois 2020-03-21 14:17:58

Thanks, pushed a fixed version (I renamed things a little, failed to adjust all variables at once).

And <https://time-based.snapshots.deb.tails.boum.org/torproject/dists/buster/snapshots/2020032002/Release> was bumped successfully (except I should have added a +1 somewhere because of the integer division).