intrigeri:
> Also, I'm concerned that so few of us have time to spend on this
> questions from the technical/security PoV, which hasn't been
> motivating me to reply promptly. I'll be the one to do it once more,
> because hey, our dear UX/web/design/doc people will have to make
> a decision anyway, so better have at least another pair of eyes with
> a different skillset look at it. I'd love to see us improve the UX/dev
> interface in the future, though. I think that all parties have
> something to learn, something to gain, and some things to improve on
> this topic. Time to re-read the notes from our 2015 summit about
> it? :)
+1 :)
> sajolida wrote (12 Jan 2016 15:47:16 GMT) :
>> As part of our work on integrating the new installation assistant and
>> ISO verification extension in the rest of the website, we need to decide
>> how to advertise the download and verification of test ISO images as
>> these ones won't be available through the ISO verification extension
>> (the extension only allows downloading the latest official ISO image).
>
>> Until now we were using buttons to the direct download of ISO images and
>> their signature. See for example
>> https://tails.boum.org/news/test_2.0-beta1/index.en.html.
>
> [snipping bits about OpenPGP verification -- anyone who cares, this is
> now #11027, that is a related but quite broader topic]
>
>> Does this sound reasonable to you for test images?
>
> When reading this initially I didn't understand what was the actual
> proposal, and am still struggling to find it in the message I'm
> replying to. But it's my bad in the end: I've asked clarifications to
> sajolida last month about it, and failed to take note of his reply, so
> I'm kinda back to square one. Oops, sorry!
>
> So please take my comments with a grain of salt, it's entirely
> possible that I misunderstood what is the exact proposal we
> should discuss.
Until now the proposal was, from the calls for testing, to we point to:
1. a direct download link on
https://archive.torproject.org/
2. a Torrent file on
https://tails.boum.org/
3. a detached OpenPGP signature on
https://tails.boum.org/
4. whatever OpenPGP verification instructions we might have (open
question dealt with elsewhere but we'll have *something*)
> In principle, I'm totally fine with _not_ integrating test images into
> the installation assistant (IA). I have three half-good reasons to think
> it's OK:
>
> * We clearly state that such images are not as trustworthy as actual
> releases, which (I guess) implies that most users who choose to
> test them entrust them with sensitive data, which implies that
> a poor verification process is no big deal in most cases.
>
> * Our dear IA/DAVE team has already spent much more time than planned
> on producing the great thing that is live on our website.
>
> * I expect mostly power-users to try our test images, so hopefully
> they will be able to download, verify and install them in some
> other way:
> - download: direct link to the ISO is enough
> - verify: see below
> - install: I think it's fair enough to assume that the majority of
> thetarget user base of these test images will know how to do
> this; I'll leave it as an exercice for our dear sajolida to find
> out how to nicely convey this message in calls for testing we
> issue :)
>
> From my perspective, none of these reasons would be fully convincing
> in itself, but all added up the conclusion totally makes sense to me.
Cool, I'm agree we agree on this as this would have been the most
problematic point if we disagreed.
> I find it important that we preserve the ability, for skilled users
> who desire so, to verify such an image with a proper cryptographic
> trust path leading from Tails developers to the end-user. I don't mean
> to interfere with the IA/DAVE team's work, in terms of how exactly
> this is implemented, so I'll stick to phrase what I think we should do
> at this abstraction level. For the mere purpose of illustrating why
> I say "preserve" above, not meaning the need has to be satisfied
> exactly this way forever and ever: currently we provide this ability
> thanks to a detached OpenPGP signature, made with a key whose security
> and usage policy is well thought and advertised, and that is pretty
> well linked to the OpenPGP web-of-trust.
I propose to keep the OpenPGP signature as we do it know. See point 4 of
the proposal.
>> As an improvement, shall we point people to
>> https://archive.torproject.org/ when downloading these?
>
> If the administrators of this service are fine with it, why not: it
> will give better download verification for non-power-users. But then
> these very same people might be stuck with a nice ISO image and no
> documentation about how to install it (see above).
Ok, see #11117. Shall I write to phobos, weasel, someone else?
> There's certainly
> a set of Tails users who know by heart how to install an ISO without
> any doc, but don't know how to use the WoT, and are keen to try our
> test images, but all in all I'm not sure the advantage it's worth the
> effort. I say: your time+energy, your call.
I think we should tell people that in doubt they can follow the
instructions of the assistant but with the ISO image downloaded from the
call for testing. That's #11118.
> Minor implementation detail: last time I checked carefully, only one
> of the two mirrors behind this hostname was serving our stuff, which
> is why (last time I checked) only one of those was in our round-robin
> pool of HTTP mirrors. If it's still the case, then we cannot do what
> you propose. This situation may very well have changed, I dunno.
I'll check before writing to archive.torproject.org then. Now #11120.
> sajolida wrote (13 Jan 2016 11:55:33 GMT) :
>> Now I see that anonym reported #10915: "Consider publishing torrents for
>> betas and RCs" which would work great to solve the basic download
>> verification problem. I'm all for it.
>
> Indeed, this would be another way to improve security for the "set of
> Tails users who know by heart how to install an ISO without any doc,
> but don't know how to use the WoT, and are keen to try our test
> images". And regardless, as we see on #10915 we have good reasons to
> do so anyway. Let's do it. sajolida, will your team take it as part of
> the question this thread is about, or shall we organize
> things differently?
If I understand correctly, this would mean adjust the release process
document to add instructions to create Torrents for release candidates
as well, right? If so, then I think anonym might be the best candidate
as I never created a Torrent myself, he was the one to propose this in
#10915, and he's the main user of the release process. I'll propose him
and see how it goes.
