Bug #12171

Cannot bump expiry of the torproject APT snapshot archive

Added by anonym 2017-01-24 21:29:53 . Updated 2017-03-02 08:34:45 .

Status:
Rejected
Priority:
High
Assignee:
Category:
Build system
Target version:
Tails_2.11
Start date:
2017-01-24
Due date:
% Done:

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

I ran:

ssh reprepro-time-based-snapshots@incoming.deb.tails.boum.org tails-bump-apt-snapshot-valid-until torproject 2017012403 94


but I still get

Origin 'torproject' uses snapshot '2017012403' which expires on: Fri, 03 Feb 2017 12:46:15 UTC


(using the shell script in the “Prepare for the next release” in release_process.mdwn)

So, this has to be resolved before February 3.

Subtasks

History

#1 Updated by anonym 2017-01-24 21:31:23

While you are at it, is the use of ${RELEASE_BRANCH:?} in the following code correct:

EXPIRY="$(curl --silent "http://time-based.snapshots.deb.tails.boum.org/debian/dists/${RELEASE_BRANCH:?}/snapshots/${SERIAL:?}/Release" | sed -n 's/^Valid-Until:\s\+\(.*\)$/\1/p')"


It felt surprising now that I saw it, and I don’t recall how I concluded it was the right thing to do when I wrote the above code.

#2 Updated by anonym 2017-01-25 09:01:39

  • Subject changed from Cannot bump expiry of torproject 2017012403 to Cannot bump expiry of the torproject APT snapshot archive

Ok, so the torproject snapshot used for 2.10~rc1, 2017011202, has now been garbage collected. Since I apparently managed to bump the expiry of the debian archive, I should have followed the instructions for bumping all archives, including the torproject one.

So actually: bumping the expiry of any serial of the torproject archive is broken! I just tried bumping the expiry of archive debian serial 2017011203 by 1 day, and it worked just fine. Bumping archive torproject with any serial I have tried has failed so far.

#3 Updated by intrigeri 2017-01-25 10:14:59

I’ll look into it best case on Friday, worst case early next week, and in any case before Feb 3.

#4 Updated by intrigeri 2017-01-27 08:42:37

> While you are at it, is the use of ${RELEASE_BRANCH:?} in the following code correct:

This code feels wrong for two reasons:

  • It suggests something wrong (i.e. that we particularly care about Debian stable when working on a release on our stable branch, and about Debian testing when working on a release on our testing branch). Now, it happens to work because we handle expiry of all snapshots in a given archive (such as debian) the same way. It would be less misleading to use a dist that depends on the archive rather than on $RELEASE_BRANCH.
  • Regardless of the archive the code pretends to be be looking it, at actually looks at expiry time for the debian archive, so the output can be wrong in some cases.

Feel free to fix all that directly on the master branch and ask me a review afterwards (preferably on XMPP or anywhere but here since this is kinda off-topic :)

#5 Updated by intrigeri 2017-01-27 08:47:26

  • Assignee changed from intrigeri to anonym
  • QA Check set to Info Needed

> So actually: bumping the expiry of any serial of the torproject archive is broken!

I cannot reproduce this:

$ ssh reprepro-time-based-snapshots@incoming.deb.tails.boum.org tails-bump-apt-snapshot-valid-until torproject 2017012403 94
$ curl --silent https://time-based.snapshots.deb.tails.boum.org/torproject/dists/jessie/snapshots/2017012403/Release | sed -n 's/^Valid-Until:\s\+\(.*\)$/\1/p' 
Mon, 01 May 2017 08:43:06 +0000

… seems very much like the exact expected behaviour.

Also, https://time-based.snapshots.deb.tails.boum.org/torproject/dists/jessie/snapshots/2017012403/ tells me that the files have indeed been modified around the time when I’ve run tails-bump-apt-snapshot-valid-until.

Might it be that you’ve simply been confused by the output of a buggy expiry date checking script?

#6 Updated by anonym 2017-02-18 16:05:28

  • Assignee changed from anonym to intrigeri
  • % Done changed from 0 to 50
  • QA Check changed from Info Needed to Ready for QA

intrigeri wrote:
> Might it be that you’ve simply been confused by the output of a buggy expiry date checking script?

Yes, I used the snippet you pointed out is wrong (in Bug #12171#note-4) which explains this ticket. I’ve fixed it in commit:dec93a98b64f22157d663b679edd3542db4542c2 and if you are happy with it you may close/reject this ticket.

#7 Updated by intrigeri 2017-03-02 08:34:45

  • Status changed from Confirmed to Rejected
  • Assignee deleted (intrigeri)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

LGTM!