Re: [Tails-dev] [tails-dev] [#10972] Port Tails to arm platforms
Hi, intrigeri: > ... or look into > http://deb.tails.boum.org/dists/devel/main/source/Sources directly. Thanks a lot, that's it! And Grub seems to be ported (at least for uboot). I'll see the next days. > To understand more about our custom APT repository, start at > https://tails.boum.org/contribute/APT_repository/ :) I did, of course. But led me directly into the scrub of the git repository instad of http://deb.tails.boum.org/dists/devel/ - anyhow, I must get more familar with the debian package concept. -- Best Regards! n9iu7pk PGP pool.sks-keyservers.net 0x4D12FFCB 7426 4598 B5AD 4D12 1699 C710 D602 E331 4D12 FFCB intrigeri: > I think it's much simpler. > > Basically, the only custom APT suite we'll be using in next Tails > major release is the 'devel' one ⇒ just rebuild the packages that are > currently in there. What are these packages? > > Either get yourself a Debian system (debootstrap chroot, VM, Tails, > whatever) and add this APT source: > > deb-src http://deb.tails.boum.org/ devel main > > ... or look into > http://deb.tails.boum.org/dists/devel/main/source/Sources directly. > > You can even skip some packages that are currently not used (and might > not build on Jessie): gnome-theme-windows8, gnome-theme-xpluna, > gnome-xp-icon-theme, window-picker-applet and xp-cursor-theme. > > ⇒ we're talking of 12 source packages to rebuild. > > To understand more about our custom APT repository, start at > https://tails.boum.org/contribute/APT_repository/ :) ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] About the download and verification of test images
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 #7. 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
Re: [Tails-dev] Dynamically changing ISO URL in DAVE
intrigeri: >> Beside that, I think the JSON should be fetched every time the UI page >> is reloaded (of course obeying to server-side caching directives), just >> like we currently do with the IDF. > > I'm afraid I don't know under which circumstances the UI page is > reloaded, so I lack the background info to integrate this proposal > into my mental representation of the problem. > > @sajolida + @Giorgio: is this done as part of the Installation > Assistant or DAVE course of operation, or only due to external factors > (e.g. the user manually reloading the page, or restarting their > browser)? I *think* that Giorgio is only referring to a possible manual refresh from the user. Keep in mind that DAVE is supposed to follow up on download in the background and a user coming back to the download page after possibly closing the tab, or to survive a manual page refresh or browser restart. The only other issue I see that relates to my work on the assistant, is the fallback solution outside of DAVE so maybe that's off-topic here. >From the blueprint I wonder whether it's really worth writing a version of the JavaScript that works outside of DAVE. You're considering several cases outside of DAVE and BitTorrent: A. Release candidates. We're discussing in another thread the possibility of only relying on archive.torproject.org for these. I think we need HTTPS there so your JavaScript outside of DAVE might not be enough to replace this here. B. People with no JavaScript, wget, etc. It seems like we need the minimal DNS pool if we want to support these anyway. C. Direct download link, as proposed on #11024. These people should anyway be able to do OpenPGP verification on their own so it won't be advertised very prominently and maybe the minimal DNS pool you are proposing for (B) could be reused here. Also, having a constant URL might be nice for these people to bookmark it for example. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] About the download and verification of test images
sajolida wrote (13 Feb 2016 12:13:49 GMT) : > Ok, see #7. Shall I write to phobos, weasel, someone else? https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure says N/A in the Maintainers column ⇒ I would ask weasel (Cc Lunar, who helps a bit on the rsync side IIRC). phobos has left the Tor project. >> 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. The title of that ticket doesn't reflect what I wrote above, so I wonder if I conveyed what I meant clearly enough: it's not about "how many servers are behind archive.torproject.org" (that is trivially answered by a DNS query), but about whether all of them _actually serve our stuff_. >> 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? I would have said that it's about checking what needs to be done, coordinating it and making it happen :) I've had a look to help with the 1st part. Our release process doc already makes us generate a Torrent and its detached signature, even for RC:s (check for yourself: the "Generate the OpenPGP signatures and Torrents" seems to have no condition attached). It also makes us seed this Torrent unconditionally. So what needs to be done is: * in the "Update the website and Git repository" section: don't skip the Torrent publication steps when preparing a RC; also deal with cleaning RC:s' Torrent files later; indeed anonym or I would be the best placed to do that, although bertagaz should be able to do it too * on our call for testing (non-existing yet) "template": link to the Torrent, its signature, and the corresponding documentation; I guess that you (sajolida) would be better placed to handle it. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Dynamically changing ISO URL in DAVE
On 13/02/2016 13:49, sajolida wrote: > intrigeri: >>> Beside that, I think the JSON should be fetched every time the UI page >>> is reloaded (of course obeying to server-side caching directives), just >>> like we currently do with the IDF. >> I'm afraid I don't know under which circumstances the UI page is >> reloaded, so I lack the background info to integrate this proposal >> into my mental representation of the problem. >> >> @sajolida + @Giorgio: is this done as part of the Installation >> Assistant or DAVE course of operation, or only due to external factors >> (e.g. the user manually reloading the page, or restarting their >> browser)? > I *think* that Giorgio is only referring to a possible manual refresh > from the user. Keep in mind that DAVE is supposed to follow up on > download in the background and a user coming back to the download page > after possibly closing the tab, or to survive a manual page refresh or > browser restart. > Whenever a page matching the pattern for a possible UI page (i.e. "https://tails.boum.org/*;), DAVE currently fetches the IDF. This is basically the only way to fix https://labs.riseup.net/code/issues/10685, as noted in https://labs.riseup.net/code/issues/10685#note-5 Of course you can and should limit the actual network activity by properly using Chache-Control and/or ETag headers. The same should apply to mirrors, if you want to keep them up-to-date. -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Fallback download URL outside of DAVE [Was: Dynamically changing ISO URL in DAVE]
hi, [@u: I'd like to decide on a strategy by February 25, so if we decide to go find a very specific kind of mirrors we have time to do this by the end of March.] sajolida wrote (13 Feb 2016 12:49:46 GMT) : > The only other issue I see that relates to my work on the assistant, is > the fallback solution outside of DAVE so maybe that's off-topic here. Just a tiny bit :) Retitled this sub-thread accordingly. > From the blueprint I wonder whether it's really worth writing a version > of the JavaScript that works outside of DAVE. Thanks for raising this topic! I was wondering too. > You're considering several > cases outside of DAVE and BitTorrent: > A. Release candidates. We're discussing in another thread the > possibility of only relying on archive.torproject.org > for these. I think we need HTTPS there so your JavaScript > outside of DAVE might not be enough to replace this here. Sounds like a pretty simple matter of programming to me. Our new mirror pool design allows us to point to TLS-enabled (HTTPS) mirrors. I guess it would be easy to give the JS function a boolean argument that specifies whether non-TLS mirrors shall be used, and on calls for testing we can use that to pick a mirror among the ones the TLS-enabled ones only. Also note that my secret plan is to leverage this new mirror pool design to transition to TLS-enabled downloads only. With Let's Encrypt around, plus us allowing mirrors to use whatever virtualhost name they want, it looks like this could finally happen :) > B. People with no JavaScript, wget, etc. It seems like we need the > minimal DNS pool if we want to support these anyway. Sure, we will need this pool anyway. But the less we rely on that DNS pool, the better: the less load we put on it (i.e. the less users we send to it), the more reliable it is, and the less daily maintenance effort is required. This is especially true until we have recruited very fast and reliable mirrors to put into this pool. Now, indeed it may be more worth our time to go after such new mirrors, than writing code to workaround the lack thereof :) > C. Direct download link, as proposed on #11024. These people > should anyway be able to do OpenPGP verification on their own so it > won't be advertised very prominently and maybe the minimal DNS pool > you are proposing for (B) could be reused here. Also, having a > constant URL might be nice for these people to bookmark it for > example. Right, and same answer as for B. Let's add to this: D. Users of web browsers that DAVE does not support ... which is similar to B and C the way I see it. So, all in all: I'm now tempted to invest time into looking for a few very reliable and fast mirrors, and put aside the "dynamic mirror URL picked with JS outside of DAVE" idea for now. We can always come back to it, if the mirrors recruitment is not successful enough: we already have code that basically does the job, so it shouldn't be a big deal to switch back to this option at the last minute, if required. Thoughts, opinions? Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
