Re: [Tails-dev] Tails Jenkins setup: present and future
Amazing! As someone whose grappling with Jenkins and Android emulators, the idea of getting it working with a complicated vagrant setup is scary. Props all around! ~abel intrigeri: Hi, bertagaz and I have just spent quite some time together working on our Jenkins setup. Tails core developers can now push stable, testing, devel and experimental branches to `gitol...@git.puppet.tails.boum.org:tails'. Whenever they do this, an ISO image is built on builder.lizard. The product of this build is kept there for a while. Along the way, we have patched vagrant/provision/assets/build-tails to make it support our Jenkins build setup too. The changes (feature/jenkins-compatible-build-script) were merged into stable, testing, devel and experimental. Vagrant users, please verify that the script still works for you. Next steps in terms of what's visible externally: * publish build products on http://nightly.tails.boum.org/ * automate mirroring process from our master Git repository to the clone on lizard, so that we don't have to push to a special remote * automatically build Debian packages for our custom programs See the roadmap for details: https://tails.boum.org/todo/automated_builds_and_tests/#index3h1 Cheers, ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] MAC Address changing problem
tailshel...@tormail.org: Hello all. I have read about MAC address changing in TAILS, and while I understand the need for some people to always use the default MAC address while using wifi, I also know we need to hide our identity regarding hardware IDs. It's a tricky subject but I believe I have found a solution that will help both people. We cannot rely on Macchanger after OS boots up, because some routers detect our MAC address when the system boots. What does this mean? How do they do this? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
intrigeri: Hi, Abel, Jake, and anyone else interested with access to the hardware: Tails 0.16~rc1 ships ekeyd, please test its EntropyKey support. I've tested this in 0.16~rc1 and it works great. Root is required of course, so you must set the root password at boot. Once that's done, usage is as normal: run ekey-rekey to set the master key, check status with ekeyd-list, and take a look at /proc/sys/kernel/random/entropy_available I cat'ed /dev/random to a file for several minutes and it never blocked, producing the standard 3-4k bytes/second. Good work! ~abel ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Claws mail and GnuPG agent
Alan: Hi, Tails currently configures GnuPG to use the agent. Unfortunately this is buggy and the second time the agent is called it freezes not only claws-mail but also metacity and thus makes the desktop unusable. I found a way to read encrypted email in claws-mail without typing the passphrase each time and without using the buggy agent feature. I use it since quite some time now and it works. I don't know however how safe this feature is. Once sombody have investigated this we might want to include it in Tails. The related configuration bits from .claws-mail/clawsrc follows: [GPG] use_gpg_agent=0 store_passphrase=1 store_passphrase_timeout=10 passphrase_grab=1 Cheers Without commenting on the security of this particular change, this is merely a temporary fix as gpg-agent is the future for gpg. gpg-agent provides process isolation that ensures the secret key material isn't handled improperly. Unfortunately it seems most client apps don't like it :\ ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] haveged quality test in Virtual Box
adrelanos: Hi! Quoted form the haveged testing page [1]: [...] will behave similarly in a virtual environment is a more risky proposition [...] there have been reports of VM that implement the processor time stamp counter as a constant and there are known differences in cpuid operation in others. [...] (Note the runtime checking is not yet available in the haveged Debian package since the Debian package has not yet been updated to the latest haveged version.) Will haveged create sufficient entropy in Virtual Box? Luckily, haveged comes with tools to check the if the entropy it creates. The README in the haveged source folder and the haveged website [2] contains instructions [1] for testing haveged. apt-get source haveged cd haveged-* ./configure --enable-nistest make check ## perhaps repeat #make clean #make check Should say something like 0 failed individual tests PASS: nist/test.sh == All 2 tests passed == The tests succeeded. The maintainer is very well aware of it and even included run-time checks in the latest version. I can not determine whether it's perfectly safe, but I can say: no known vulnerabilities. I recently wrote a post about entropy collection for Qubes OS, which has a similar problem (entropy starved VMs). While writing the post I came across this great LWN article https://lwn.net/Articles/525459/ Near the end it discusses HAVEGE with the startling point: One of Peter's colleagues replaced the random input source employed by HAVEGE with a constant stream of ones. All of the same tests passed. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/ekeyd [Was: Support EntropyKey?]
intrigeri: Hi, please review and merge feature/ekeyd, candidate for 0.16. ticket: todo/Install_ekeyd_for___40__potentially__41___better_entropy (Roughly tested, as in ekeyd starts and does not tell anything after startup into syslog. We'll have to ask Jake and Abel to test the RC1 with real hardware.) Please update this thread once a downloadable iso is available. I can test EntropyKey and the smartcard support. The vagrant build method still fails for me on Fedora :| still haven't had time to debug. ~abel ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
intrigeri: Hi, Jacob Appelbaum wrote (26 Nov 2012 15:40:33 GMT) : intrigeri: we're asked to install ekeyd to support EntropyKey: [...] I think it is a good idea. I regularly install it with Tails anyway. Good to know: it will make it easier for us to support hardware we don't have access to :) What version do you install and use in Tails? stable or squeeze-backports? Do you need to take special actions, beyond apt-get install ekeyd, to make it work? ___ You have to authenticate to the EntropyKey using your secret key, then it will work with ekeyd. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
intrigeri: Hi, we're asked to install ekeyd to support EntropyKey: https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ The total installed size of the needed packages is a few hundred kilobytes. I think it's worth adding to improve cryptography -related hardware support. What do you think? Just want to add my +1 to see this in tails. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/OpenPGP-SmartCard
intrigeri: hi, ticket: https://tails.boum.org/todo/support_OpenPGP_smartcards/ branch: feature/OpenPGP-SmartCard This is a first step toward better support of OpenPGP smartcards. It won't work for all hardware, it won't work with Seahorse's gpg-agent, but it will provide a basis for testing and asking feedback. In the current state of things, I don't think it deserves any end-user nor design documentation. Candidate for 0.15. Short log: 736cd01 Install pcscd and libccid from squeeze-backports. If this triggers any regression I did not notice during my own testing, this can easily be reverted before RC2. cheers, superb! Is there a test ISO available with this change? Or do I need to build from source? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
intrigeri: Hi, Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) : As this is a modular kernel - is there a reason not to simply add a enable firewire widget? There are several I can see: * It is a UX failure every time someone has to go out of their way to have Tails work with their hardware. * Every such widget we add to Tails Greeter makes the greeter worse for every Tails user: more cluttered, more complicated. That's why I still prefer the let's guess what the user wants approach: if they plug a device in the X slot, that's probably because they want to use it, so let's keep the X bus enabled, and disable it else. OTOH, I understand your concern, and I now think the 5 minutes delay that was suggested may be a bit too long. We did not specify exactly when the 5 minutes countdown starts, anyway. Perhaps we could start an initscript right after GDM, have it sleep 1 minute, and then disable these dangerous buses if unused? (This gives a clear visual indication of when the countdown starts.) Regardless of the solution proposed above, would it be possible to have an alternate grub menu that disables these dangerous interfaces from the get go? There could be an Advanced grub menu entry, that displays these alternative kernel-param boot options. Surely, there should be *some* secure option where the window of attack is zero? ~abel signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Ague Mill: On Mon, Oct 15, 2012 at 02:47:05PM +, Abel Luck wrote: intrigeri: Hi, Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) : As this is a modular kernel - is there a reason not to simply add a enable firewire widget? There are several I can see: * It is a UX failure every time someone has to go out of their way to have Tails work with their hardware. * Every such widget we add to Tails Greeter makes the greeter worse for every Tails user: more cluttered, more complicated. That's why I still prefer the let's guess what the user wants approach: if they plug a device in the X slot, that's probably because they want to use it, so let's keep the X bus enabled, and disable it else. OTOH, I understand your concern, and I now think the 5 minutes delay that was suggested may be a bit too long. We did not specify exactly when the 5 minutes countdown starts, anyway. Perhaps we could start an initscript right after GDM, have it sleep 1 minute, and then disable these dangerous buses if unused? (This gives a clear visual indication of when the countdown starts.) Regardless of the solution proposed above, would it be possible to have an alternate grub menu that disables these dangerous interfaces from the get go? Please note that Tails is using SYSLINUX at the moment and not GRUB. Noted. There could be an Advanced grub menu entry, that displays these alternative kernel-param boot options. Surely, there should be *some* secure option where the window of attack is zero? How would you label it so that it does not puzzle users who are using a FireWire external disks, but never had to think about the word FireWire before? Sorry, I wasn't clear. The bootime options I proposed were the firewire disabled options. Assuming, as seems to be the reasoning so far, that the default behavior will be the most usable (enabled for X minutes then disabled, or w/e), my idea is to have a disabled from boot alternative option. To answer your question, my thought was it would be hidden behind an advanced menu, so users who didn't care and didn't know will not pay it any mind. Example (for the sake of clarity): ++ || | * Boot Tails | | * Memtester | | * Advanced |- option behind this menu || ++ What would you write in the end-user documentation? Who would be using such option? The documentation would explain, in layman's terms, the risk of such interfaces, then it would explain the default behavior of the X-minute window. Next, it would explain the the potential threat scenarios in which a user might be concerned about that window, and, finally, instruct how to use the advanced option. I would use such an option, I imagine Jake would as well (though I won't speak for him). Any potential tails user (1) with the awareness of such attacks and (2) desire mitigate them. I am afraid about the endless stream of why are you not making it the default?, like the one we already get regarding Javascript. Answers would probably be even quite similar. I'm not having such option, but it really needs to be done right. Absolutely it should be done right. You shouldn't be afraid of that question. The answer to why are you not making it the default? is being discussed right now in this email thread, see Jacob's point in the great-great-grandfather of this message and intrigeri's reply. I still think this should be the default, and the enabled firewire the advanced option. I can't imagine the majority of users use firewire. Putting the majority at risk for the minority doesn't seem a good idea, BUT I can concede that thought with the 1-minute window proposal. Nevertheless, my point (repeating myself here), is that there should be a zero-second window option regardless, for those that care. Moreover, that option does not have to significantly affect the UX. ~abel signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
