Project

General

Profile

Bug #16200

Allow verifying different versions of Tails (older versions, testing versions, etc.)

Added by u 11 months ago. Updated 5 months ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Verification Extension

Description

Using our new JSON format and the extension in version 2, we might be able to publish older versions in the JSON file. Or any other ISO/IMG file plus checksum that we want to have in there.

Currently the extension will not check if the version that the user wants to verify is the current one because we publish only the current one, so no mistake can be made here.

But if we decide to publish older versions, we should add a version check and alert the user that they are verifying an old image, and we can even tell them which one, and still allow them to verify the checksum of the old image.

I think this might be useful if we want to allow users to verify RC images for example.


Related issues

Related to Tails - Bug #15995: Have Tails Verification handle IDFs with several Tails installation paths (ISO/IMG) Resolved 09/28/2018

History

#1 Updated by u 11 months ago

  • Related to Bug #15995: Have Tails Verification handle IDFs with several Tails installation paths (ISO/IMG) added

#2 Updated by intrigeri 11 months ago

But if we decide to publish older versions, we should add a version check and alert the user that they are verifying an old image, and we can even tell them which one, and still allow them to verify the checksum of the old image.

I'm curious: why would we do that? We currently remove obsolete images from our mirrors for a reason, but if there's a good reason to allow verifying old images, then perhaps we should change that and leave obsolete images on mirrors for a while. Either way, that's interesting because it raises the question of "is version X supported?", and highlights the fact the IDF v2 format allows us to tell which version we've just verified (woohoo!), which is relevant for similar use cases:

I think this might be useful if we want to allow users to verify RC images for example.

It would be awesome if we allowed users to use Tails Verification to verify newer, tentative images, such as alpha/beta/RC releases, and not just the latest stable release!

Thinking aloud, either we keep the current semantics:

  • For any supported version, i.e. that will have automatic upgrades and security support, such as RCs and some 3.0~betaN in the past: using /install/v2/Tails/amd64/stable/latest.json feels right. And I think the current algorithm (does one of the allowed hashes match?) is good enough because what we want to check here is "is this a currently supported version?". We can probably do that whenever we want, without any code change: we "just" (sic!) need to seriously modify our process to generate IDFs and our template for announcing RCs.
  • For any unsupported version, e.g. a random alpha or call for testing, to avoid breaking the semantics, we need to use a different IDF, that is /install/v2/Tails/amd64/alpha/latest.json if we keep following the UDF road. And then the download page for this alpha release needs to communicate to the extension the fact it's an alpha and a different IDF shall be used. I think that would be nice but I'm not sure about the cost/benefit. Apart of that, no same as above, the current verification algorithm is good enough IMO.
  • Obsolete versions would be listed in /install/v2/Tails/amd64/obsolete/latest.json and the extension would fetch this file and check its hashes if it did not manage to verify the image using stable/latest.json; and then, warning users totally makes sense to me. I've no idea about the benefits yet.

Or we change the semantics, we list all versions we want to let people use in one single IDF (/install/v3/Tails/amd64/latest.json), and we add a field for each item of installations to indicate its status (stable, alpha, obsolete). I guess that requires less coding work in the extension, which makes it tempting, but it also makes it more difficult to update this large(r) single IDF (⇒ more coding work elsewhere and probably more work for RMs).

I wonder if I should have written this in a new "Allow using the Verification Extension to verify alpha/beta/RC releases too" ticket. Happy to create it if you think it makes sense, to avoid taking over your ticket with off-topic ideas :)

#3 Updated by u 11 months ago

intrigeri wrote:

But if we decide to publish older versions, we should add a version check and alert the user that they are verifying an old image, and we can even tell them which one, and still allow them to verify the checksum of the old image.

I'm curious: why would we do that? We currently remove obsolete images from our mirrors for a reason, but if there's a good reason to allow verifying old images, then perhaps we should change that and leave obsolete images on mirrors for a while. Either way, that's interesting because it raises the question of "is version X supported?", and highlights the fact the IDF v2 format allows us to tell which version we've just verified (woohoo!), which is relevant for similar use cases:

Exactly, it tells us which version we've verified :) That's where I wanted to go.

I think this might be useful if we want to allow users to verify RC images for example.

It would be awesome if we allowed users to use Tails Verification to verify newer, tentative images, such as alpha/beta/RC releases, and not just the latest stable release!

Yes! :)

Thinking aloud, either we keep the current semantics:

  • For any supported version, i.e. that will have automatic upgrades and security support, such as RCs and some 3.0~betaN in the past: using /install/v2/Tails/amd64/stable/latest.json feels right. And I think the current algorithm (does one of the allowed hashes match?) is good enough because what we want to check here is "is this a currently supported version?". We can probably do that whenever we want, without any code change: we "just" (sic!) need to seriously modify our process to generate IDFs and our template for announcing RCs.

Entirely correct.

  • For any unsupported version, e.g. a random alpha or call for testing, to avoid breaking the semantics, we need to use a different IDF, that is /install/v2/Tails/amd64/alpha/latest.json if we keep following the UDF road. And then the download page for this alpha release needs to communicate to the extension the fact it's an alpha and a different IDF shall be used. I think that would be nice but I'm not sure about the cost/benefit. Apart of that, no same as above, the current verification algorithm is good enough IMO.

Ack. I'm not sure it's worth the hassle.

  • Obsolete versions would be listed in /install/v2/Tails/amd64/obsolete/latest.json and the extension would fetch this file and check its hashes if it did not manage to verify the image using stable/latest.json; and then, warning users totally makes sense to me. I've no idea about the benefits yet.

Or we change the semantics, we list all versions we want to let people use in one single IDF (/install/v3/Tails/amd64/latest.json), and we add a field for each item of installations to indicate its status (stable, alpha, obsolete). I guess that requires less coding work in the extension, which makes it tempting, but it also makes it more difficult to update this large(r) single IDF (⇒ more coding work elsewhere and probably more work for RMs).

I prefer the latter proposal: indicating the status. It requires indeed less coding work in the extension. I'm not sure about the benefits either, as it would also keep the IDF growing...

I wonder if I should have written this in a new "Allow using the Verification Extension to verify alpha/beta/RC releases too" ticket. Happy to create it if you think it makes sense, to avoid taking over your ticket with off-topic ideas :)

No no, that's not off-topic at all, this is what this ticket is about :) Please rename it if you consider that it makes sense.

#4 Updated by sajolida 9 months ago

  • Subject changed from Tails Verification Extension: add ISO/IMG version check to Allow verifying different versions of Tails (older versions, testing versions, etc.)

#5 Updated by u 5 months ago

  • Assignee deleted (u)
  • Start date deleted (12/07/2018)

Also available in: Atom PDF