Tails

#2 Updated by intrigeri 2018-12-07 17:54:44

> 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® 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 Anonymous 2018-12-11 18:44:21

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® 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.