[Tails-dev] testing squashfs-tools 4.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...---... Subject: testing squashfs-tools 4.3 To: tails-dev@boum.org Hello all, * I've set up an old computer in my house to act as a Tails builder. I can't afford to make much more than a single-core 1GB of RAM VM. * Learning about what SquashFS was, I had a look at the documentation. Somehow found out that squashfs-tools 4.3 has been released since 2014-05-12 (http://sourceforge.net/projects/squashfs/files/squashfs/) * Here is the changelog: http://sourceforge.net/p/squashfs/code/ci/master/tree/CHANGES * We can see it mentions that some new gzip compression options were added to this version. We can now use a lower compression level, which would supposedly allow us to build faster testing ISOs. * We can also see experimental support for LZ4 which is supposed the king of all the decompression speedsters. Debian packages are at 1:4.2 and there is no sign of a 4.3 at sid. I went a made a 4.3 package by combining the src for squashfs-tools 4.3 and what I found in squashfs-tools_4.2+20130409-2.debian.tar.xz, made a bogus entry in changelog, and activated LZ4 in the makefile. I've got my own custom deb mirror for building my custom version of Tails, so it was fairly easy to outstage the 4.2 version that you are all currently using. Here are some results: BASELINE: XZ currently used in STABLE - -comp xz -Xbcj x86 -b 1024K -Xdict-size 1024K: real81m43.904s (4903.904s) user54m10.363s (3250.363s) sys 9m24.107s The ISO is 970584064 bytes large. BASELINE: Gzip vanilla currently used in TESTING - -comp gzip: The ISO is 1291370496 bytes large. real44m40.244s 2680.244 user14m16.910s sys 8m18.031s TEST1: GZip with the lowest compression setting - -comp gzip -Xcompression-level 1 The ISO is 1412929536 bytes large. real38m4.922s 2284.922 user8m41.441s sys 6m59.390s TEST2 LZ4 vanilla - -comp lz4 The ISO is 1801336832 bytes large. real38m18.538s user7m51.701s sys 6m44.649s TEST3 LZ4 High Compression - -comp lz4 -Xhc The ISO is 1529903104 bytes large. real37m59.400s user8m57.886s sys 7m22.332s Conclusions: * The new 4.3 version appears to allow for faster test builds when using GZIP with the lowest compression setting. * Remarkably, it appears that LZ4 High compression is faster than LZ4 vanilla, and even slightly faster than GZIP with the lowest compression setting. Could LZ4 -Xhc become the new favoured 'quick-build' compression setting for the future? Final words: * Would you prefer to wait for Debian to upstream the squashfs-tools 4.3 or would you be willing to distribute a custom build from the tails deb repo? I could submit the files I used to build squashfs-tools 4.3. PS: mksquashfs 4.3 also has a '-progress' argument you can pass it, which is supposed to give you a nice progress bar so you can see at what point of the compression you currently are, but sadly I haven't seen it work as advertised. Take care! ...---... -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVo+msAAoJEM5wUx8CP5BTKv4P/jowZmboR3YXhmWwZQJWMpzW MJo8CmWGeuWZTAsBk7uqdpsbysSD30Ufj+VvL8BDEvQ9XCpkOc531I2q/Vf7amBM yZRvO8vdxCdgDiCbUKThBzZQI612JtyEeHP+OLvWt6/627E/asC7sv+cCvXUEary 9ZIy6ykwGkiYnNfaqUvD4E1mxEGja1XK4LfWODpA0vmfwgvACyaBywPI5AJvOot7 yuQmkuQkynDUHXPUBEWreslGUdy+rzJ+M/l9G0FLUQRLjIeyg+pgMRj0Jb8S6QT/ wkuHMQHcFhyuBarBZYw8eP56yCq4vYehpjb+xzobWUlOCofAtYtUbRqqVHUnKCJW p1FycnAf3cB8G2jg/+/yRqnNz2vgZavh9xNLhEfoh+RDOmjjFJndzLUk/GkNpE8a dCZxWXg9QsVj14wY5G0+uTVW9NkO3jSjmJqdC/4tjbv0d84jLXbxHBatgrDsSZDe FzpivKMehDWSiUBGPJcdMOdnY9yu8P1rOZGM1R3p240tCwSAcjUJWjqd2JG76dnU 60fMcRhLsm/QB2YNcCjhab9mEcQb/XMFhbNCNQQB3HdtXBlmaokDvm1mhqut3J69 pK6yzZfQil8+R9keIvVHRhYp/eEK3Ir/Hv9T66NYVQP13IpTEqS9myJqUTYuJ1CE tRL8Y33mtVVACleYXvMA =P68+ -END PGP SIGNATURE- ___ 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 build system with Vagrant 1.7.3
Got Vagrant 1.7.3 to inter-operate with the current TAILS Rakefile by adding explicit paths for some extra require commands. This likely is not needed once ruby/rake system paths for require commands are set correctly (I'm a ruby/rake n00b). The Vagrant/VirtualBox shell provisioning of the base box 'tails-builder-20141201' currently errors with the following packages not found. P: Begin installing packages... Reading package lists... Building dependency tree... Reading state information... Package hopenpgp-tools is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Package keyringer is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Package linux-image-3.16.0-4-586 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Package linux-image-3.16.0-4-amd64 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'linux-image-3.16.0-4-586' has no installation candidate E: Package 'linux-image-3.16.0-4-amd64' has no installation candidate E: Package 'hopenpgp-tools' has no installation candidate E: Package 'keyringer' has no installation candidate P: Begin unmounting filesystems... real4m42.505s user2m6.284s sys 0m33.978s + RET=123 + '[' -e binary.iso ']' + fatal 'lb build failed (1).' + echo 'lb build failed (1).' lb build failed (1). + exit 1 Not sure what am I missing here? Thanks for any pointers/tips! signature.asc Description: OpenPGP digital signature ___ 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] Please support VPN for Tails. Any workaround for now?
intrigeri, OK, I get it, but understand on another level how absolutely maddening this is. Tor has been under fire for being 'government funded', it's gotten beyond ugly, particularly for Andrea Shepherd. There has been some talk of a blockchain based method for relays/exits to get paid for the traffic they handle, but this is likely years away, if it happens at all, and that doesn't do much to support the developers. I2P is smaller, weirder, and it didn't make such appeals, now some needed stuff, like the C++ version of the system, are finally getting attention. The three credible adversary resistant computing systems - namely TAILS, Whonix, and Qubes, are all in the "have contributors, need donors" mode of operation. I don't see any signs of the free software/get paid providing services model that other projects have successfully followed. What I do see is stuff like Subgraph - slick branding, slick marketing, some recognizable folks working on it, but nothing that can be downloaded and used. Looks to me like they will take the best of the three actual projects I mentioned above, whomever is funding it will make out like the proverbial bandit, and you guys don't even get a thank you from that process. What you have said has been the universal response, and I think our response is likely to be a "pick which project you want to donate to" on the token sales page, which puts an end to any complaints about commercial interests, while actually supporting valuable projects. -killswitch On Mon, July 13, 2015 10:55 am, intrigeri wrote: > Hi, > > > Dr. Killswitch, D.V.M. wrote (12 Jul 2015 21:25:06 GMT) : > >> Cryptostorm provides [...] >> > > To me, this looks dangerously like commercial advertisement, which has > nothing to do on this mailing-list. Please be a bit more cautious about not > crossing this line in the future. Thanks! > > 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. > > ___ 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] Sprints for Tails/Jessie
Hi, I plan to focus on porting Tails to Debian Jessie for a couple weeks in November. Tentative dates: * November 9-13 * November 16-20 If you want to join the fun, let me know. If you're interested in having a face-to-face sprint to work on this in November, let me know. If these dates don't work for you, let me know. Meta: I'm planning this far in advance so that 1. this task doesn't permanently stick in my head as a painful "OMG that's something I should make progress on every time I have a spare hour, otherwise I'll be late"; 2. other people can more easily join this effort; 3. some people know in advance when I *won't* be available for other matters. 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.
[Tails-dev] Call for help: important stuff we have to do, that lack people
Hi, it's often the case that I take care of the unexpected research/code tasks that pop up on our plate, that some of us feel that we (as a project) absolutely have to deal with. Of course it's less simplistic, and sometimes other people do take care of those, and very often I don't take care of it but instead add it to my backlog and fail to address the issue effectively. I need to escape this situation, because it harms me, the project, and much more. So here's a call for help and volunteers. Here are some tasks that I would very happily see someone else (and ideally, small teams) take over: * #8415 "Migrate from aufs to overlayfs": until this is done, we're stuck with Jessie's Linux 3.16 kernel * #7675 "Persist entropy pool seeds" * #7642 "Investigate whether we should ship /var/lib/urandom/random-seed" * #5650 "rngd" * #7100 "Decide what to do with machine-id" * some bugs in the ikiwiki 'po' plugin, and some missing feature in other areas of ikiwiki — ask me for details if you want to hack Perl code In most cases, it's an option to reconsider the urgency of the task, and another way to help me is to explain why it's not so critical. Thanks in advance! 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] Hacking Team looking at Tails
Peter N. Glaskowsky wrote (13 Jul 2015 08:29:02 GMT) : > I can’t think of any obvious reason this shouldn’t be detectable. Attach a > suspect > USB stick, do not mount it, and compute secure hashes of the partitions. > If the Tails installer doesn’t reliably create consistent > partitions, that’s something to consider fixing, if it can be fixed. Jake started working on this (modulo he started with a mounted system partition, which is a good first step IMO) a year ago. Some technical challenges are left to be addressed, though: https://labs.riseup.net/code/issues/7496 Needless to say: help is welcome. 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] Hacking Team looking at Tails
I can’t think of any obvious reason this shouldn’t be detectable. Attach a suspect USB stick, do not mount it, and compute secure hashes of the partitions. If the Tails installer doesn’t reliably create consistent partitions, that’s something to consider fixing, if it can be fixed. Even then, we could use an emulator to walk through the boot process on the suspect USB stick and see if any code gets executed that isn’t part of Tails. .png > On Jul 13, 2015, at 1:24 AM, intrigeri wrote: > > Hi, > > [redirecting this discussion to tails-dev@boum.org, which is more > suitable for this discussion => please drop tor-talk@ from the list of > recipients when replying -- thanks!] > > I wrote (12 Jul 2015 13:06:15 GMT) : >> https://wikileaks.org/hackingteam/emails/emailid/25607#efmBTaBTh > >> Below research points remain outstanding ... > >> VECTORS · Offline: [...] > >> by translate.google.com but obviously not precise but concerning nonetheless. > > I got a translation made by a native speaker who's skilled in this > area, quoting it below with my notes+todo inline. > > $native_speaker wrote: >> [EN] Below the feature that will be deployed for RCS10. The release is >> expected for [... not sure what does it means ...] (October) > >> VECTORS: > >> Offline: >> o Infection of bootable usb keys from UEFI (Antonio)$ The infected usb >>key will drop (release) a scout itself. > > This seams to mean that a corrupted UEFI firmware would modify a Tails > device plugged in the machine to infect it. To me it looks like it's > part of "Tails can't protect against compromised hardware", modulo > nitpicking wrt. whether firmware is software (which is correct > strictly speaking), or a mere part of the computer hardware (which is > also correct, from the PoV of a Tails system, as it's pre-existing to > Tails starting). We have WIP to clarify our documentation in > this respect. > >> o Infecting USB device which appears to be a bootable disk (Antonio + >>Giovanni)§ It will drop (release) the scout, then it will run >>a wipe. > > Seems to be the same, but from a running and already infected > non-Tails OS, when a Tails USB stick is plugged in it. That's more > concerning. We should check if we're communicating clearly enough > that: > > * the OS used to install or upgrade a Tails device can corrupt it > * plugging one's Tails device in an untrusted OS is dangerous > >> o Infection of Tails USB (Antonio)$ The infection will occur at runtime > > This seems to mean an running Tails infecting its boot device. > Totally unclear if they had any remote idea of how to implement that, > back then. Not much we can do about it that is not on our hardening > milestone already, I guess. > >> o New NTFS driver for UEFI infection (Antonio) >> o Persistent infection also on OSX and signed UEFI (Antonio) > >> Network Injection: >> o New set of external antennas for the TNI (Andrea) >> o Creation o a mini-TNI (Andrea)$ transportable by a drone, without >> any melting constraints >> o Creation of a micro-TNI (Andrea)$ HW of a mobile $ It will have a >> subset of the functionality > > 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. ___ 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] Hacking Team looking at Tails
Hi, [redirecting this discussion to tails-dev@boum.org, which is more suitable for this discussion => please drop tor-talk@ from the list of recipients when replying -- thanks!] I wrote (12 Jul 2015 13:06:15 GMT) : > https://wikileaks.org/hackingteam/emails/emailid/25607#efmBTaBTh > Below research points remain outstanding ... > VECTORS · Offline: [...] > by translate.google.com but obviously not precise but concerning nonetheless. I got a translation made by a native speaker who's skilled in this area, quoting it below with my notes+todo inline. $native_speaker wrote: > [EN] Below the feature that will be deployed for RCS10. The release is > expected for [... not sure what does it means ...] (October) > VECTORS: > Offline: > o Infection of bootable usb keys from UEFI (Antonio)$ The infected usb > key will drop (release) a scout itself. This seams to mean that a corrupted UEFI firmware would modify a Tails device plugged in the machine to infect it. To me it looks like it's part of "Tails can't protect against compromised hardware", modulo nitpicking wrt. whether firmware is software (which is correct strictly speaking), or a mere part of the computer hardware (which is also correct, from the PoV of a Tails system, as it's pre-existing to Tails starting). We have WIP to clarify our documentation in this respect. > o Infecting USB device which appears to be a bootable disk (Antonio + > Giovanni)§ It will drop (release) the scout, then it will run > a wipe. Seems to be the same, but from a running and already infected non-Tails OS, when a Tails USB stick is plugged in it. That's more concerning. We should check if we're communicating clearly enough that: * the OS used to install or upgrade a Tails device can corrupt it * plugging one's Tails device in an untrusted OS is dangerous > o Infection of Tails USB (Antonio)$ The infection will occur at runtime This seems to mean an running Tails infecting its boot device. Totally unclear if they had any remote idea of how to implement that, back then. Not much we can do about it that is not on our hardening milestone already, I guess. > o New NTFS driver for UEFI infection (Antonio) > o Persistent infection also on OSX and signed UEFI (Antonio) > Network Injection: > o New set of external antennas for the TNI (Andrea) > o Creation o a mini-TNI (Andrea)$ transportable by a drone, without > any melting constraints > o Creation of a micro-TNI (Andrea)$ HW of a mobile $ It will have a > subset of the functionality 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] Please support VPN for Tails. Any workaround for now?
Hi, Dr. Killswitch, D.V.M. wrote (12 Jul 2015 21:25:06 GMT) : > Cryptostorm provides [...] To me, this looks dangerously like commercial advertisement, which has nothing to do on this mailing-list. Please be a bit more cautious about not crossing this line in the future. Thanks! 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.
[Tails-dev] Heads up: changed ways to track review'n'merge requests
Hi, in the "[Tails-dev] Getting rid of review'n'merge email on this list" thread, we've decided to stop requiring review'n'merge email on this list. Alternate ways to track such requests have been found and set up, and are documented there: https://tails.boum.org/contribute/working_together/Redmine/#atom 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'n'merge:master] doc/no-more-review-n-merge-email
sajolida wrote (12 Jul 2015 08:44:29 GMT) : > I had a quick look and it looks all-right. Thanks. So, I've merged 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] Git repositories at immerda: downtime
kytv wrote (11 Jul 2015 19:04:27 GMT) : > FWIW I'm not seeing updates when pulling from the git repo over > https. It should now be fixed. Thanks for the heads up! ___ 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] 32bit UEFI
Hi, 林哲民 (Lin Zhemin) wrote (13 Jul 2015 05:03:27 GMT) : > I've successfully booted TAILS nightly build (20150712) from Asus X205TA on > a Trenscend 4GB USB 2.0 disk. Thanks for the report! It's good to see this branch confirmed to work on another machine. 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.
