Re: [Tails-dev] Release schedule for Tails 1.3.1
On 06/03/15 21:28, BitingBird wrote: > anonym: >> On 06/03/15 15:34, anonym wrote: >>> Hi, >>> >>> I'll be the release manager for Tails 1.3.1, which currently is >>> scheduled to be released on 2015-04-07 [1]. However, Firefox 37, which >>> was supposed to ship that date, has been moved up one week, to >>> 2015-03-31 [2] to not coincide with Easter. I presume that the same goes >>> for the 31.6.0esr release and hence the next Tor Browser release (which >>> I've asked about on tbb-dev@ [3]). I'll continue with that assumption, >>> and that we too will change our release date for Tails 1.3.1 to >>> 2015-03-31, because otherwise it'll be open season on Tails users for >>> browser exploits for a week. >>> >>> Thoughts? I'll update the calendar [1] if I get an ACK for this new >>> release date. >> >> We just got an ACK that the next Tor Browser will release on 2015-03-31: >> >> https://lists.torproject.org/pipermail/tbb-dev/2015-March/000235.html >> > So this is a confirmation that the release date is changed? If so, > please change the calendar, I'll take care of the milestone in Redmine. > Please note that the next release is changed too, so our release should > be rescheduled now too. I'd like to just have some ACKs from some Tails developers/contributors/blah first too so I'm not taking this decision on my own (still, I don't expect any objections, but who know?). Sorry for not making that clear. It's also a good point that we should consider moving the 1.4 release date too now. So, the proposals are to do the following to sync the Tails release cycles with the Firefox release cycles: * Move the release date for Tails 1.3.1 to 2015-03-31. * Move the release date for Tails 1.4 to 2015-05-12. Any objections to any of these? Cheers! ___ 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] [Corrected!] Release schedule for Tails 1.3.1
On 06/03/15 15:34, anonym wrote: > Here's the preliminary release schedule: > > * 2015-03-28: > - All branches targeting Tails 1.3.1 must be merged into the 'stable' > branch by noon CET. > - Tor Browser 4.x, based on Firefox 31.6.0esr is *hopefully* out, so > we can import it. > - Build and upload Tails 1.3.1 ISO image and IUKs. > - Start testing Tails 1.3.1 during late CET if building the image > went smoothly. > > * 2015-03-31: > - Finish testing Tails 1.3.1 by the afternoon, CET. > - Release Tails 1.3.1 during late CET. > > So, testers, please let me know if you are available on: > > * 2015-03-28, late CET (only needed if image building went smoothly). > > * 2015-03-31, morning to afternoon, CET. Someone pointed out to me "what happens between 2015-03-28 and 2015-03-31? The 28th date was a mistake and should be the 30th! Argh! So, the updated updated preliminary release schedule is: * 2015-03-30: - All branches targeting Tails 1.3.1 must be merged into the 'stable' branch by noon CET. - Tor Browser 4.x, based on Firefox 31.6.0esr is *hopefully* out, so we can import it. - Build and upload Tails 1.3.1 ISO image and IUKs. - Start testing Tails 1.3.1 during late CET if building the image went smoothly. * 2015-03-31: - Finish testing Tails 1.3.1 by the afternoon, CET. - Release Tails 1.3.1 during late CET. So, testers, please let me know if you are available on: * 2015-03-30, late CET (only needed if image building went smoothly). * 2015-03-31, morning to afternoon, CET. Sorry for the inconvenience! ___ 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] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi, sajolida wrote: > Following-up on the ideas of: > > - Keeping the green onion as a permanent visual feedback on the desktop. > - Not breaking too much of what people have been used to unless we > have a good (UX) reason to do so (keeping what works in Vidalia). > - Integrating Tor Monitor nicely on the desktop. > - Considering the green onion and the list of circuits as part of the > same user task of "monitoring tool". > > I hereby propose to have the list of circuits accessible directly from > the green onion as it is the case now in Vidalia. But I'm not sure how > this fits with your architectural plans and related security implications. > What I see is : Top shell bar Onion | | v v [_Applications_Places__O_o_o_o_] A___ |Tor is ready| |Open Tor Monitor| ++ Disconnected: striked onion X X XX_./\._XX /XX XX\ / XX \ | XX XX | XX__XX X X Bootstraping: onion with dots (as when network is connecting) _./\._ / \ //\ /\ /\\ |\/ \/ \/| \/ Connected: full onion _./\._ / \ /\ || \/ Would this address your requirements? By the way, I'm not sure the onion should be green. For better integration into GNOME Shell I think it should perhaps be monochromatic. Cheers ___ 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] How to replace the green onion
Hi,
intrigeri wrote:
> Alan wrote (22 Feb 2015 01:48:28 GMT) :
> > intrigeri wrote:
> >> Alan wrote (20 Feb 2015 19:43:10 GMT) :
> >> > I'm not opposed to exposing a DBus interface in a future version of
> >> > TorMonitor to provide the "green onion" or other applications more
> >> > information that our hooks could. But I'm not sure it is the right
> >> > place to do it yet.
> >>
> >> What would be a better place to do it in your opinion?
> >>
> > In my opinion, the easiest method to replace vidalia's green onion
> > would be to write a very small GNOME Shell extension that would listen
> > to a very simple DBus service.
>
> Did I get it right that this extension will actually *provide* that
> DBus service? And then other stuff (see below) will connect to it to
> notify the extension that Tor is up?
>
It may indeed be the easiest to do, even it it sounds a bit reverse
logic.
> > The very same mechanism that currently
> > displays the "Tor is ready" notification in Tails would trigger a
> > notification to this DBus service that would update this onion. I admit
> > this would be very Tails specific.
>
> I think we can go this way (or similar) for the first iteration, that
> replaces what Vidalia gives us, including the buggy green onion.
> So I've created #9002, as a child ticket of #6841 ("Replace Vidalia").
>
> Now, in the first iteration, the information we want to convey to that
> Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
> is down" on network post-down).
Really? I though we wanted bootstrap progress too, that current
vidalia's onion provides (no onion/red > yellow > green)
> Using DBus to convey this information
> seems vastly overkill to me, to the point of being a little
> bit ridiculous.
>
If we only want a boolean status, I agree with you.
> If that saves us time for the next iterations, why not. But for the
> next iterations of that extension, the listening direction may change
> (I expect that something else will provide the DBus service that
> provides updates wrt. the status of Tor connectivity, and the Shell
> extension will connect to that service to get these updates), so
> perhaps it's really not useful to get DBus onboard before we have
> a clearer idea of the design for the next iterations.
>
> An alternative, for the initial iteration, is to do exactly what we're
> doing now: when we display "Tor is ready", simply enable the Shell
> extension that displays the green onion. And disable it when the
> network gets disconnected. This way, we don't even need any
> communication channel :)
>
This can be done by changing a GSetting. I do not find it very elegant
to change a setting at each network status change, but it may work. I
didn't found a DBus interface to enable/disable extensions. At first
glance, I think DBus might still be the more appropriate.
> > Please note that I'm not aware of such a concept of "connectivity
> > status" in Tor. If you know about it, don't hesitate to point me to
> > relevant documentation.
>
> No idea. Is it equivalent to having circuits open? I think Tor tries
> to maintain circuits open even when they're not requested by clients,
> so if there's no circuit open, perhaps Tor can be considered
> as disconnected?
>
Tor always tries to build circuits, so it has circuits in "launched"
state. We could consider Tor as "connected" as long as it has at least
one circuit in "built" state.
[...]
> > To sum up, I see three options (on order of complexity) to feed this
> > GNOME shell extension that would provide the onion:
>
> > 1. through the same mechanism that displays the "Tor is ready"
> >notification;
> > 2. through a DBus service that would be a separate process that the
> >Tor Monitor application (but managed in the same project);
> > 3. through a DBus service that would be tightly integrated in the Tor
> >Monitor application.
>
> I say let's go with (1) as far as #6841 is concerned.
>
I agree it's the easiest way to start with.
Cheers
___
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] review and merge feature/6999-compress-png
Hi, intrigeri wrote: > > Of course, this only make sense if we get a compression rate that is > > worth doing all that stuff... so maybe we should investigate c) before > > deciding on this and seem how the result affects the final ISO size. > > Exactly. I bet a couple doc branch reviews that the test results will > tell us that mksquashfs is simply good enough. > In my opinion, all this was a nice attempt, but unfortunately these compression things doesn't seem me worth it given the energy involved vs the expected gain. Cheers ___ 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] Release schedule for Tails 1.3.1
anonym: > On 06/03/15 15:34, anonym wrote: >> Hi, >> >> I'll be the release manager for Tails 1.3.1, which currently is >> scheduled to be released on 2015-04-07 [1]. However, Firefox 37, which >> was supposed to ship that date, has been moved up one week, to >> 2015-03-31 [2] to not coincide with Easter. I presume that the same goes >> for the 31.6.0esr release and hence the next Tor Browser release (which >> I've asked about on tbb-dev@ [3]). I'll continue with that assumption, >> and that we too will change our release date for Tails 1.3.1 to >> 2015-03-31, because otherwise it'll be open season on Tails users for >> browser exploits for a week. >> >> Thoughts? I'll update the calendar [1] if I get an ACK for this new >> release date. > > We just got an ACK that the next Tor Browser will release on 2015-03-31: > > https://lists.torproject.org/pipermail/tbb-dev/2015-March/000235.html > So this is a confirmation that the release date is changed? If so, please change the calendar, I'll take care of the milestone in Redmine. Please note that the next release is changed too, so our release should be rescheduled now too. https://wiki.mozilla.org/RapidRelease/Calendar Cheers, BitingBird PS: I'd like to have confirmation soon, as I'm supposed to publish the report this night and I'd like to have the correct date in 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] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
Giorgio Maone:
> On 04/03/2015 19:46, sajolida wrote:
>> I tried to interrupt a download of the ISO with Tor Browser and,
>> indeed, it's not possible to continue it.
>
> This seems due to a misconfiguration of your mirrors setup.
> Specifically, I've tried to manually resume an interrupted download from
> Firefox's download manager, which should have theoretically worked
> because the (initial) server (announcing itself as "Server: Apache")
> sent an "Accept-Ranges: bytes" header.
> Unfortunately when I sent the second request with "Range:
> bytes=37053248-", the second server I was dispatched to announcing
> itself as "Server: lighty") actually answered with
>
> HTTP/1.1 206 Partial Content
> Content-Range: bytes 37053248-954132479/954132480
> Content-Length:917079232
>
> i.e. correctly resumed the download, but the brower refused to go on
> because the first response (from Apache) carried an
>
> Etag: "7c08c-38dee800-50fcad82a1400"
>
> header, while the second one (from Lighttpd) had
>
> Etag: "1421032332"
>
> misrepresenting the payloads as two different entities.
>
> Now, the easiest solution seems to me preventing Etag headers from being
> sent in the ISO download HTTP responses (who's gonna *cache* a 1GB
> response anyway?).
Thanks for investigating all this! I created a parent ticket to work on
this, see #9022 and subtasks.
> Otherwise, you need to synchronize all the mirrors to serve the same
> Etag (e.g. I hit another server, announced as "nginx", with Etag:
> "54ebc9d0-38dee800"). For instance you could use
> "Tails-image-{SHA256_checksum}" to build an unique Etag valid for that
> specific ISO version.
>
>> So I might reconsider what I just said in my answer to intrigeri :P
>> Still, I like the idea of having the verification experience for
>> people downloading through HTTP and through BitTorrent being the same.
>> I also like the idea of making an explicit and intentional move to
>> verify the ISO (instead of making it happen automatically). I
>> understand from your proposal Giorgio that the extension could be able
>> to resume an interrupted or paused download, right?
>
> Yes it could, and I could probably work-around even the aforementioned
> mirror server misconfiguration by intercepting the http responses before
> they're examined by the browser forcibly filtering out the Etag headers,
> if necessary, but the ideal solution would be fixing it so anyone can
> use any browser or download manager to resume interrupted downloads.
I agree that we should rather fix that problem at its root.
>> Then I'll take good note of this and will try to take a decision
>> during our next UX sprint (when we should be able to finalize all the
>> UX side of things). For example, maybe the download process can be
>> done only if people choose HTTP download, and then the verification
>> process could still be done in the same way for everybody. But I'm
>> more worried about the security discussion for the moment.
>>> [...]
>
>>> Providing a menu item or an option button somewhere to browse the
>>> filesystem and manually choose the file to be verified is simple
>>> enough. Am I missing some other requirement for this feature which
>>> would add complexity?
>> Not that I can think of. But you are answering here one of the questions
>> I had for you, since you are saying that the extension would be allowed
>> to browser or any file on the file system (for example from a BitTorrent
>> download) and verify that as well. That's good news.
> Confirmed. Basically the extension can do anything the browser itself
> can do.
Understood.
>> So, from a security point of view, I think that pushing more content on
>> AMO doesn't solve the root of the problem: if someone is in control of
>> tails.boum.org (through MitM or exploit) then they can fool all those
>> newcomers with whatever rogue verification process even earlier in the
>> website. Even if I agree that AMO are in a better position to defend
>> themselves, visitors of tails.boum.org might be tricked not to install
>> the extension ever.
> Yes, I understand, and as a mitigation I'd advise to start deploying
> HPKP on tails.boum.org ASAP, see
> https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
Sure, I read more about that and understood that we should:
- First, deploy it ourselves, that's #9026.
- Then have our keys pinned in the Firefox preload list, that's #9027.
That sounds really worth it!
>> The only way we could mitigate such an attack (MitM or exploit on
>> tails.boum.org) is in the case of people following an external
>> documentation (for example from a book) that doesn't rely on
>> tails.boum.org at all. Then indeed it make sense, from a security point
>> of view, to do the verification in a native interface.
>
> ... or if a web search for "Installing Tails" or "Download Tails ISO"
> returned https://addons.mozilla.org/addon/tails-downloader, and the
> add-on description page provided very concise instruction
Re: [Tails-dev] Release schedule for Tails 1.3.1
anonym: > So, testers, please let me know if you are available on: > > * 2015-03-28, late CET (only needed if image building went smoothly). > > * 2015-03-31, morning to afternoon, CET. Neither of the two for me I'm sorry! -- sajolida ___ 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] Macbook Air EFI fixed
Hi, [redirecting to our support mailing-list; please drop tails-dev@ from the recipients list on reply, and maybe subscribe to tails-support: https://mailman.boum.org/listinfo/tails-support] Alan Kubiak wrote (06 Mar 2015 01:34:34 GMT) : > According to your support channel, you recommend a program to install the > Tails ISO on a USB drive. The recommended program does create a Tails/USB > drive but > it wont boot on a Macbook. Which exact set of instructions are you talking about? These ones: https://tails.boum.org/doc/first_steps/installation/manual/mac/ ? What's the exact Mac model you are testing with? (that would be e.g. something like "MacBook Pro 5,1") > The solution is to use a different program called Rufus 2.0 to create the > bootable > USB drive from the Tails ISO. Simply format as FAT32 and install the ISO > from RUFUS. > When booting from the Mac, just boot the Tails USB drive from the BIOS. Thanks for this report. Just one more question: did you see Rufus download syslinux from the Internet during the Tails installation process? (Our testing on Windows exposed this problem: https://labs.riseup.net/code/issues/7034) 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.
Re: [Tails-dev] review and merge feature/6999-compress-png
Hi, sajolida wrote (06 Mar 2015 17:40:16 GMT) : > How do I delete a branch on the remote directory? git push origin --delete feature/6999-compress-png >> Now, regardless of what we do with *existing* images, it would be good >> to have "something" that prevents poorly compressed images from being >> *added* to Git. >> >> There are a lot of candidate solutions, [...] > I must admit that I'm not really excited at over-engineered solutions > with hooks and all. Fair enough :) > I'll try to come up with two other possible low-fi > techniques but they would require adding two copies of each images to > Git (the uncompressed first, and then the compressed version and you > might not like them: > 1. Couldn't we say that we continue adding uncompressed images happily > like we did in the past and that on a regular basic (release time, once > a year, or anything else) we spot images that are in master and haven't > been compress yet (merged since the last time we compressed images for > example), and then compress those ones only. I dislike this one (surprise! :), because it will progressively ruin the effort we've put into making our Git repo smaller. But I could be fine with trying it, recompressing in 6-9 months, and at that point (*before* pushing to our repo, thanks), evaluating what's the impact on .git's size of storing these images twice, compared to what it would be if the optimized version had been pushed initially. I'm not volunteering to do this evaluation. > 2. We try our best to compress images before adding them. If the > compression process is manual and quite cumbersome, we should be able to > remember to specify in the commit messages if we did the compressing. > Then uncompressed images could be spotted based on that every now and > then and compressed. Works for me. This should be communicated very clearly to the people working on the test suite, as these days *they* are the ones who're adding lots of (probably poorly compressed) images to Git. I can do that latter part once the process is documented. > Of course, this only make sense if we get a compression rate that is > worth doing all that stuff... so maybe we should investigate c) before > deciding on this and seem how the result affects the final ISO size. Exactly. I bet a couple doc branch reviews that the test results will tell us that mksquashfs is simply good enough. 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.
Re: [Tails-dev] Macbook Air EFI fixed
Alan Kubiak: > There is supposedly a bug with booting Tails on Macbook Air or Macbook > Pro due to an EFI issue. Hi Alan, and thanks for reporting your findings. Booting Tails on Mac is high depends on the actual Mac version. And that's what makes supporting Mac so painful, their hardware compatibility changes all the time. See https://tails.boum.org/support/known_issues#index14h2 for what we know so far. But we're also sometimes reported total success on Mac! > According to your support channel, you > recommend a program to install the Tails ISO on a USB drive. Which one? Our documentation mentions the `dd` command which does an exact copy of the ISO onto the USB stick for Mac. See https://tails.boum.org/doc/first_steps/installation/manual/mac.html But this method is only a bootstrapping method to get a temporary Tails installed on the USB stick and as a way of then running Tails Installer from that onto a second USB stick. See https://tails.boum.org/doc/first_steps/installation.html Note that we very much insist on people using Tails Installer because it is the only technique that provides: - Persistence volume. See https://tails.boum.org/doc/first_steps/persistence.html - Automatic upgrades. See httos://tails.boum.org/doc/first_steps/upgrade.html > The > recommended program does create a Tails/USB drive but it wont boot on a > Macbook. Are you using one of the models mentioned on our known issue page? > The solution is to use a different program called Rufus 2.0 to create > the bootable USB drive from the Tails ISO. Simply format as FAT32 and > install the ISO from RUFUS. When booting from the Mac, just boot the > Tails USB drive from the BIOS. Does Rufus work on Mac? It don't see that on their homepage but that would be interesting. Once you're on that Tails installed from Rufus, can you try to install a second USB stick using Tails Installer. Do it boots? -- sajolida ___ 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] review and merge feature/6999-compress-png
intrigeri: > sajolida wrote (02 Mar 2015 14:53:20 GMT) : >> intrigeri: >>> Another option would be to have ikiwiki recompress these images when >>> building the wiki. This would be a bit costly, so likely not suitable >>> for local builds, but just fine on our production website I guess. >>> Is there any plugin that does something like that? If not, it should >>> be relatively trivial to write. > >> Maybe we need to make it more clear what's the objective. To me the >> objective is to reduce the impact of PNG images on the size of our ISO >> images. I don't care so much about online visits to the website, seeing >> that this only bring 15% compression overall. > > I didn't get this initially. Initially it was about website optimization you are right. But seeing we only get 20% compression on 2.4MB total data, I'm not sure it's worth it and though ISO image optimization made more sense as ISO image size have more implication that just on Internet download (size on the USB stick, isohybrid stuff, etc.). > How much do we gain on the resulting ISO size (with the default, slow > SquashFS compression settings), thanks to this recompression process? I didn't try that. I'll do that at some point but that's low prio to me. > Good catch. Yes, indeed. So what we gain on ISO images (that might be > downloaded without Tor), we lose it on IUKs (that are always > downloaded via Tor). So, we should really *not* recompress images at > ISO build time, right? Agreed. >> If we agree on this, then I'm very sorry to have polluted the Git repo >> with 2MB of compressed binaries right after you cleaned it... > > No problem: the improvement for the visitors of our web site still > seems worth it to me, as long as we don't do it again every 6 weeks. > > So, I see three options: > > a) Revert all changes to the release process doc, and merge this > branch to improve navigation (especially over Tor) on our website, > at the expense of a 3-4% bigger Git repository. > > b) Delete this branch and hope for Git garbage collection to give us > these 2MB back. I'd do that for the moment as this branch really have not really much work that is not documented fully on the ticket already. How do I delete a branch on the remote directory? > c) Refocus this effort on website navigation, and try the > web-optimized palette trick that I reported about on > #6999#note-1 (on the image I tested it on, back then I got a 60% > size reduction, compared to the 6.3% we got with optipng+advdef). I'd do that as well. But not myself as Naar as proved to be far more expert than me on this :) > Of course it's much more painful than the commands Naar and you > came up with, but in this case it's a one-shot effort, as opposed > to something that should be run for every release and needs to be > automated. Right, not that the compression that we are proposing here could also, in theory be a one-shot effort. The problem is actually to keep track whether it has been done already. > Then, if it gives substantially better results, then rewrite the > topic branch's history to replace commit 1a7beb4 with one that > compresses images even better... and merge it! Ack. > My (humble) opinion: > > * If someone is excited by (c), please go for it. I'll point the ticket to our discussion here. > * Else, I don't care much. (a) is good because we get an immediate > benefit from the great work that's been done. (b) is good — if it > actually works in terms of reclaiming space in Git — because it > leaves more room for someone doing (c) later without me > complaining that these images are already stored twice in .git. Let's do b) for the time being. If c) never happens or doesn't work, we can always rollback. > Now, regardless of what we do with *existing* images, it would be good > to have "something" that prevents poorly compressed images from being > *added* to Git. > > There are a lot of candidate solutions, such as documentation for doc > and automated test writers (will be regularly forgotten), a pre-commit > hook that ask you to confirm that you've optimized stuff whenever you > add or update a picture (only works for those who actually bother > setting up the pre-commit hook and reading what it tells them), adding > a check about that in our review'n'merge policy (won't work at all > I bet), or a hook on our main Git repo that tries to recompress > added/updated pictures and, if it can itself improve compression by > some factor, forbids the branch from being pushed (probably the only > really working solution, but it has to be written, and had better be > pretty robust and safe). I must admit that I'm not really excited at over-engineered solutions with hooks and all. I'll try to come up with two other possible low-fi techniques but they would require adding two copies of each images to Git (the uncompressed first, and then the compressed version and you might not like th
Re: [Tails-dev] Virtual appliance for the browser
Hi, everyone. Here's a rough overview of the virtual browser appliance I'm
working on for tails. Critical feedback is welcome.
Best regards,
Alex
** Guest overview
- Virtualbox VM running barebones debian with the same window manager
as tails. Constructed using debian live.
- Does not share clipboard through vbox at all.
- Shares the ~/.tor-browser, ~/.mozilla, "~/{,Persistence/}Tor Browser"
directories with the host as Virtualbox shared folders.
- Does not share the tor browser binary/libraries with the host, but
they can be essentially the same as in tails, using the host tor
daemon via ports 9050/9051.
- When the guest wm is ready to start a browser, drops a file in a
shared folder to indicate this to the host.
- A guest daemon watches the guest [[
http://www.pygtk.org/pygtk2reference/class-gtkclipboard.html][clipboard]]
for changes and saves
them to a file in a shared folder.
** Host overview
- Guest is run on a host-only network. Ports 9050/9051 are forwarded
over iptables or something similar.
- Guest boots from a virtual optical disk so it's the same code
starting every time.
- Guest VM is displayed using virtualbox's seamless mode, so that its
browser windows appear in standalone windows on the host desktop.
- Host checks for hardware virtualization support by running "sudo
modprobe kvm_{intel,amd}, and checking dmesg output for "kvm: no
hardware support" or "kvm: disabled by bios." If it finds either
of these messages, warns user on browser start that it's
downgrading to unvirtualized browser, and everything runs the way
it does now.
- Host also checks whether it's running under virtualization with
"/usr/sbin/dmidecode -s system-product-name". If it is, check
whether any CPU flags in /proc/cpuinfo suggest support for nested
virtualization, and if not, same warning.
- Otherwise, all browser defaults are set to a script which
1) starts the guest VM if it's not already up, removing any stale
indication that the guest is ready to start a browser,
2) waits for indication from the guest that it's ready to start a
browser, and starts one with the supplied CL arguments, using
VboxManage guestcontrol
- Host has up and down buttons in the task bar which transfer the
contents of the clipboard from guest to host and vice versa.
*** Notes
Could the guest be tails?
If you disabled the firewall and greeter, you could possibly use the
tails image itself for the guest, which would save a little space.
I think that has potential for confusion, though. Probably best to
make it the minimal image needed to get the job done.
Using the same window manager as tails means that the browser
windows will appear the same in seamless mode.
Clipboard
Making the user explicitly move objects from one clipboard to the
other is a hit to useability, but probably better security.
Perhaps there should also be an optional mode which turns on
bidirectional sharing.
On Sun, Feb 22, 2015 at 4:52 PM, Alex Coventry wrote:
> Hi, intrigeri. Sorry it's taken a while to respond, you gave me a lot
> to think about. The potential lack of VT-x/d implies that any
> virtualization solution should be based around tor browser or whatever
> you're currently using, which I am fine with. I think it will be
> feasible to run the tor browser in a virtualbox which is connected to
> tails's tor via a virtualbox host-only network.
>
> > Disregarding the hardware support issue I've talked about above, there
> > is at least one major problem to solve, which is... usability.
> >
> > Users need to send files to the browser and back. We support
> > persistent bookmarks, and may support persisting more browser settings
> > in the future.
>
> Is there any problem with presenting the persisted config files via vbox
> shared folders?
>
> Another usability issue is the clipboard. You don't really want the
> clipboard working in either direction, unless the user explicitly asks
> for it. I was thinking this could be done with a couple of buttons in
> the taskbar to explicitly transfer from one clipboard to another.
>
> > Also, interacting with a browser that's itself running in a window
> > manager in a VM may be weird, so this needs serious integration work.
> > Here too, see what Qubes OS does.
>
> Virtualbox's seamless mode seems pretty good for this. If you run it
> with a window manager which doesn't provide taskbars, each guest window
> simply shows up on your host desktop.
>
> Best regards,
> Alex
>
> On Wed, Feb 11, 2015 at 6:14 PM, intrigeri wrote:
>
>> Hi Alex,
>>
>> Alex Coventry wrote (11 Feb 2015 22:14:39 GMT) :
>> > vulnerability, but both firefox holes and linux privilege escalations
>> are
>> > relatively common, and it seems likely that as Tails gets more popular
>> it
>> > must be getting more attractive to
Re: [Tails-dev] How to replace the green onion
intrigeri: > sajolida wrote (05 Mar 2015 17:03:04 GMT) : >> I hereby propose to have the list of circuits accessible directly from >> the green onion as it is the case now in Vidalia. But I'm not sure how >> this fits with your architectural plans and related >> security implications. > > It should be no problem: assuming the green onion thingie is a GNOME > Shell extension (this seems to be the only reasonable way to do it > IMO), then it'll run as the `amnesia' users, who should be able to > start Tor Monitor anyway. Cool! >> Alan, I'm not sure what are the implications of the deprecation of >> System Tray Icons as I couldn't find anything about that in the GNOME >> HIG. > > The HIG apparently doesn't capture everything that the code does. > Let me provide some background. In previous versions of GNOME, there > were two different things: > > * proper panel applets (e.g. NM's one) > * icons in the notification area (that very often were things that > should really be applets, but their authors were lazy and they > hijacked the notification area -- that's what we did for our own > OpenPGP applet, oops) Understood. > While with GNOME Shell: > > * the notification area isn't displayed by default anymore; Yeah, I've seen the redesign for 3.16 that you sent me. > * a third-party extension (topIcons) can be used to restore the old > notification area icons placement; no idea how long this hack will > work; That's #8309. > * what used to be "proper panel applets" can now be implemented as > GNOME Shell extensions. > >> But in Tails Jessie we still have various custom widgets in the top >> bar that expend to more features when you act on them: the Florence >> keyboard and the OpenPGP Applet. So I guess this is still acceptable... > > That's a temporary hack, made possible only via a third-party GNOME > Shell extension, and I'd like to get rid of as soon as possible > (https://labs.riseup.net/code/issues/8309). Adding more stuff there > would add to the list of things that we'll have to > rewrite/replace later. Ok, so that confirms what I understood already. We can still put *some* stuff in the top bar (without much change for the user) but that needs to be done as GNOME Shell extensions. That's more of a infrastructure and code change than a UX change in the end. Good news. -- sajolida ___ 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] Release schedule for Tails 1.3.1
On 06/03/15 15:34, anonym wrote: > Hi, > > I'll be the release manager for Tails 1.3.1, which currently is > scheduled to be released on 2015-04-07 [1]. However, Firefox 37, which > was supposed to ship that date, has been moved up one week, to > 2015-03-31 [2] to not coincide with Easter. I presume that the same goes > for the 31.6.0esr release and hence the next Tor Browser release (which > I've asked about on tbb-dev@ [3]). I'll continue with that assumption, > and that we too will change our release date for Tails 1.3.1 to > 2015-03-31, because otherwise it'll be open season on Tails users for > browser exploits for a week. > > Thoughts? I'll update the calendar [1] if I get an ACK for this new > release date. We just got an ACK that the next Tor Browser will release on 2015-03-31: https://lists.torproject.org/pipermail/tbb-dev/2015-March/000235.html Cheers! ___ 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] Release schedule for Tails 1.3.1
Hi, I'll be the release manager for Tails 1.3.1, which currently is scheduled to be released on 2015-04-07 [1]. However, Firefox 37, which was supposed to ship that date, has been moved up one week, to 2015-03-31 [2] to not coincide with Easter. I presume that the same goes for the 31.6.0esr release and hence the next Tor Browser release (which I've asked about on tbb-dev@ [3]). I'll continue with that assumption, and that we too will change our release date for Tails 1.3.1 to 2015-03-31, because otherwise it'll be open season on Tails users for browser exploits for a week. Thoughts? I'll update the calendar [1] if I get an ACK for this new release date. [1] https://tails.boum.org/contribute/calendar/ [2] https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates [3] https://lists.torproject.org/pipermail/tbb-dev/2015-March/000234.html For the list of tickets targeting Tails 1.3.1, have a look at: https://labs.riseup.net/code/projects/tails/issues?query_id=175 That's 88 open tickets, and it seems we have one week less to work on this. Dammit! We better start cranking code/docs/translations/etc ASAP! :) Here's the preliminary release schedule: * 2015-03-28: - All branches targeting Tails 1.3.1 must be merged into the 'stable' branch by noon CET. - Tor Browser 4.x, based on Firefox 31.6.0esr is *hopefully* out, so we can import it. - Build and upload Tails 1.3.1 ISO image and IUKs. - Start testing Tails 1.3.1 during late CET if building the image went smoothly. * 2015-03-31: - Finish testing Tails 1.3.1 by the afternoon, CET. - Release Tails 1.3.1 during late CET. So, testers, please let me know if you are available on: * 2015-03-28, late CET (only needed if image building went smoothly). * 2015-03-31, morning to afternoon, CET. Cheers! ___ 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.
