[Tails-dev] Macbook Air EFI fixed
There is supposedly a bug with booting Tails on Macbook Air or Macbook Pro due to an EFI issue. 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. 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. ___ 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] Reducing attack surface of kernel and tightening firewall/sysctls
intrigeri wrote (18 Jan 2015 21:45:15 GMT) : > I see this thread has been quiet for a bit more than a month. > Maybe it's time for someone to sum up whatever consensus was reached, > and whatever disagreement may still be remaining? > Jake, maybe? Ping? The next major release is scheduled for May 19, with a freeze early in May I guess, so we have almost two months to get whatever solution we choose in a mergeable state. 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, [edit: you might want to jump straight to the part about IUKs.] 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. How much do we gain on the resulting ISO size (with the default, slow SquashFS compression settings), thanks to this recompression process? (It might be that our extreme SquashFS compression settings already give us just the same as what recompressing images would. We're talking of a mere 300-400kB anyway.) > If we agree on that, then maybe that could be hooked in the ISO > build process (and not in the wiki build process). Could that go in > auto/build right after build-wiki? Agreed * 2, except: > But then, how would that interfere with IUKs? Would non-deterministic > builds of those images always end up in IUKs? 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? > But I guess that this does not depend on whether this is done at ISO > or wiki build time... Indeed, it doesn't. > 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. 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). 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. 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! My (humble) opinion: * If someone is excited by (c), please go for it. * 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. 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). Thoughts? 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] How to replace the green onion
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. > 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) While with GNOME Shell: * the notification area isn't displayed by default anymore; * a third-party extension (topIcons) can be used to restore the old notification area icons placement; no idea how long this hack will work; * 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. 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] How to replace the green onion [was: What do we miss to replace Vidalia]
Alan: > intrigeri wrote: >> Alan wrote (20 Feb 2015 19:43:10 GMT) : >>> On Thu, 19 Feb 2015 14:23:03 + >>> sajolida wrote: intrigeri: > sajolida wrote (18 Feb 2015 11:32:17 GMT) : >> intrigeri: >>> [About the green onion] >> >> but would it be conceivable to have Tor Monitor >> appear as green onion on the desktop as Vidalia does until now? > >>> I don't think it's the way to go: >> >>> - I'd like Tor Monitor to stay a generic application, with a clear >>> focus on being a monitor for Tor and showing whatever icon on the >>> desktop doesn't look like the same task for me. >> >> IMO the "providing feedback regarding Tor connectivity status" feature >> fits pretty well into the "monitoring Tor" mission. Perhaps we don't >> put the same meaning behind "monitoring Tor". >> > Ok. You have a point here. This could be argued as some "desktop > integration" of the application. Meta: it's getting hard for me to follow the technical side of all this. I'm still maturing the UX side of things... Beware! 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. 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. 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... -- 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.
[Tails-dev] Tails report from August to December 2014
As you might have noticed, our last monthly report was a long time ago, because the people who were doing them had really no time left. Somebody new finally takes over, let's hope it lasts :) So, here is a minimal report for the second half of 2014, the next ones will be more complete. Releases * Tails 1.1.1 was released on September 2, 2014. (minor release) https://tails.boum.org/news/version_1.1.1 * Tails 1.2 was released on October 14, 2014. (major release) https://tails.boum.org/news/version_1.2 * Tails 1.2.1 was released on December 3, 2014. (minor release) https://tails.boum.org/news/version_1.2.1 * Tails 1.2.2 was released on December 15, 2014. (special minor release for security reasons) https://tails.boum.org/news/version_1.2.2 Code For details, see each release announcement. Notable changes include: * 1.1.1: I2P now needs to be enabled with a boot option. We made this choice after a security hole affected I2P ; this problem is now fixed, but if any other is discovered in the future, it won't affect Tails users who don't use I2P. https://tails.boum.org/doc/anonymous_internet/i2p https://tails.boum.org/security/Security_hole_in_I2P_0.9.13 * 1.2: Tor Browser replaces the previous Firefox + Torbutton setup. This allows us to work more closely with Tor people and provide a more unified experience to the user. https://tails.boum.org/doc/anonymous_internet/Tor_Browser * Several major applications are confined with AppArmor. This improves the overall security provided by Tails, and AppArmor work is going on to confine more applications :) https://tails.boum.org/contribute/design/application_isolation * 1.2.1: finally removes TrueCrypt. It was abandonned upstream since a long time, and it's safer to use maintained, reviewed encryption methods, like LUKS (that's what the persistence. You can still open your TrueCrypt volumes, but we recommand you switch to LUKS volumes as soon as possible. https://tails.boum.org/doc/encryption_and_privacy/truecrypt https://tails.boum.org/doc/encryption_and_privacy/encrypted_volumes Funding === - We passed a call for donations on our website which was quite successful. Donations are still welcome though :) https://tails.boum.org/news/who_are_you_helping - The grant proposal that we submitted to the Digital Defenders was approved. It will fund part of our activity over 2015: - Build our capacity to provide same-day security updates: - Increase the test coverage of our automated test suite to cover most of our remaining manual tests. - Write automated tests for the new features to be developed during 2015. - Buy dedicated hardware to allow core developers to be able to run the test suite locally. - Streamline the installation process for less tech-savvy people: - Have Tails Installer available in Debian, Ubuntu, and derivatives. - Write a Firefox extension to automate the ISO verification at download time. - Rework our download and installation instructions as a web assistant to guide new users step-by-step through the process. - Provide one year of help desk. https://digitaldefenders.org/ - We submitted a full proposal to the Open Technology Fund. It passed a first round of review and is now waiting for the approval of their final committee. https://www.opentechfund.org/ Outreach - Several Tails contributors attended the 31C3 in Hamburg. We held a Tails table where many people came to ask questions, get Tails installed, start to contribute or just say thank you. We even had some origami folding moments :) https://events.ccc.de/category/31c3/ - We passed a call for help on porting Windows camouflage to GNOME 3.14. https://tails.boum.org/news/windows_camouflage_jessie Press & Testimonials For more information concerning the second half of 2014, see our press page. https://tails.boum.org/press/ * 2014-12-29: In Reconstructive narratives at the 31th Chaos Communication Congress, Jacob Appelbaum and Laura Poitras explained that properly implemented encryption technologies such as Tor, Tails, GnuPG, OTR, and RedPhone are some of the only ones that can blind the pervasive surveillance of the NSA. They are rated as "catastrophic" by the NSA itself. http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video * Tails is being used in the film Citizenfour by Laura Poitras and appears in the credits. https://citizenfourfilm.com/ Documentation = - We documented a workaround to empty the trash of the persistent volume. https://tails.boum.org/doc/encryption_and_privacy/secure_deletion#empty_trash. Metrics === In August 2014: * Tails has been started more than 287,156 times in August. This makes 9,263 boots a day on average. * 19,910 downloads of the OpenPGP signa
Re: [Tails-dev] [Tails-support] PGP MIME is insecure (for me)
Jeff Anderson: > === quote === > Brian Morrison 2014-07-15 17:14:27 CEST > > The way to fix this is to create a local MH mailbox on your machine > and point the sent and queue (and any others you want) to that local > mailbox. Then your encrypted mail will not be stored on the IMAP server. > > === end quote === > > This worked very well and was easy to setup. It allows you to continue to > use "MIME" instead of "inline" PGP with claws, and stores the Drafts or > Queue/Outbox messages locally. This reminds me of https://tails.boum.org/doc/first_steps/persistence/configure#index5h2 but I'm not sure whether this warning is complete correct and could be improved. I know that BitingBird has been working on the email client documentation, see #7694): https://labs.riseup.net/code/issues/7694 So maybe now is the time to improve on this. The current development draft is accessible on https://git-tails.immerda.ch/tails/tree/wiki/src/doc/anonymous_internet/claws_mail.mdwn?h=doc/7694-email_client > I spoke with someone at claws and they told me that this is a known issue. Is it well documented on their side? > It has something to do with the fact that once you encrypt a message for > the receiving party, you may not be able to decrypt it yourself. A message > in the 'drafts' folder is incomplete by definition and may need to be > re-opened by the sender in plaintext to make adjustments. So the message > cannot be fully encrypted while in the draft section. A usual trick to prevent this is to encrypt messages for yourself as well as for the receiver. Is there any option for that in Claws maybe? > Anyhow, the best solution is to create a local mail folder and redirect > drafts and queued messages to this. It may be a good idea to mention this > somewhere in the Tails docs, as I think most users of Tails will probably > want their emails to be encrypted prior to leaving their local box. ___ 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.
