[Tails-dev] Write protection Re: DVD vs. USB: doc needs adjustments? [Fwd: [tor-talk] USB Sticks for Tails - CCCamp]
intrigeri wrote: I believe we're telling users about some security benefits of booting Tails from a DVD (as opposed to from a USB stick), but apparently there are some drawbacks too. Perhaps we need to adjust our doc accordingly? First steps with Tails https://tails.boum.org/doc/first_steps/index.en.html Please notice this line: Installing onto a USB stick or SD card (recommended) Choosing between burning a DVD and installing onto a USB stick or SD card https://tails.boum.org/doc/first_steps/media/index.en.html That second page contains this statement: Some USB sticks, SD cards, or SD card adapters have a read-only switch that can prevent your Tails from being altered, but be aware that this protection is most probably not ensured by the device itself: do not rely on untrusted computers to respect this feature. Suggestion: It would be great if it were possible to automatically test if a USB storage device is *really* write protected. That test could be executed while booting Tails and the user could be informed about the result. Cheers, Andreas ___ 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] GSoC 2014 - Linphone Implementation ... ?
car...@riseup.net: What do you think about the implicit influence interference of projects by google (also with GSoC)? For example the google partnership with mozilla has the result that firefox phone depends more and more on parts of android. I do not see much connection between the payments for the placement of Google search in Firefox and an alleged dependence of Firefox OS on parts of Android (which parts?). The influence on... what exactly? :) i don´t know gsoc ... but normally google don´t give anything without taking influence on it The main influence is the choice of projects. I am not aware of any additional influence on mentors or students (besides the fact that Google obeys certain legal obligations which unfortunately make it impossible for students or mentors from some countries to participate). Cheers, Andreas ___ 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] undefined method `uuid' for #Vagrant::Machine:0x000000025afd00
anonym: In case you are using vagrant = 1.2, I'm aware of this issue. If you use an older vagrant than that it's new to me. Which version are you using? I am on Debian unstable. vagrant package 1.4.3-1. While I have an unpublished fix that seems to work, I want to take a closer look before pushing it (cause I think there are a few other, related inconsistencies in the Rakefile). Until then you can work around it by only issuing the `rake build` when the vagrant VM is halted. So run `rake vm:halt` now and from then on you always build like this: rake build; rake vm:halt to make sure that you don't leave the VM running afterwards. Build process is running now, thanks! It also explains why I was able to build Tails *once* a few hours before the problem occurred (in fact that was my first successful Tails build ever). I did not consider the possibility that a VM might still be running after that and creating problems. Cheers, Andreas ___ 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] undefined method `uuid' for #Vagrant::Machine:0x000000025afd00
Any ideas? Cheers, Andreas --- andreas@lenny:~/tails/tails$ rake --trace build ** Invoke build (first_time) ** Invoke parse_build_options (first_time) ** Execute parse_build_options ** Invoke ensure_clean_repository (first_time) ** Execute ensure_clean_repository ** Invoke validate_http_proxy (first_time) ** Execute validate_http_proxy No HTTP proxy set. ** Invoke vm:up (first_time) ** Invoke parse_build_options ** Invoke validate_http_proxy ** Execute vm:up rake aborted! undefined method `uuid' for #Vagrant::Machine:0x00025afd00 /home/andreas/tails/tails/Rakefile:72:in `current_vm_cpus' /home/andreas/tails/tails/Rakefile:279:in `block (2 levels) in top (required)' /usr/lib/ruby/vendor_ruby/rake/task.rb:236:in `call' /usr/lib/ruby/vendor_ruby/rake/task.rb:236:in `block in execute' /usr/lib/ruby/vendor_ruby/rake/task.rb:231:in `each' /usr/lib/ruby/vendor_ruby/rake/task.rb:231:in `execute' /usr/lib/ruby/vendor_ruby/rake/task.rb:175:in `block in invoke_with_call_chain' /usr/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize' /usr/lib/ruby/vendor_ruby/rake/task.rb:168:in `invoke_with_call_chain' /usr/lib/ruby/vendor_ruby/rake/task.rb:197:in `block in invoke_prerequisites' /usr/lib/ruby/vendor_ruby/rake/task.rb:195:in `each' /usr/lib/ruby/vendor_ruby/rake/task.rb:195:in `invoke_prerequisites' /usr/lib/ruby/vendor_ruby/rake/task.rb:174:in `block in invoke_with_call_chain' /usr/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize' /usr/lib/ruby/vendor_ruby/rake/task.rb:168:in `invoke_with_call_chain' /usr/lib/ruby/vendor_ruby/rake/task.rb:161:in `invoke' /usr/lib/ruby/vendor_ruby/rake/application.rb:149:in `invoke_task' /usr/lib/ruby/vendor_ruby/rake/application.rb:106:in `block (2 levels) in top_level' /usr/lib/ruby/vendor_ruby/rake/application.rb:106:in `each' /usr/lib/ruby/vendor_ruby/rake/application.rb:106:in `block in top_level' /usr/lib/ruby/vendor_ruby/rake/application.rb:115:in `run_with_threads' /usr/lib/ruby/vendor_ruby/rake/application.rb:100:in `top_level' /usr/lib/ruby/vendor_ruby/rake/application.rb:78:in `block in run' /usr/lib/ruby/vendor_ruby/rake/application.rb:165:in `standard_exception_handling' /usr/lib/ruby/vendor_ruby/rake/application.rb:75:in `run' /usr/bin/rake:27:in `main' Tasks: TOP = build = vm: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] Tails report for December 2013
Tails folks: - We are now very likely to create a non-profit organization dedicated to Tails. Is there more information which can be shared on this list - especially regarding the location of the organization ? (US? Europe?) Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Debian issue tagging for Tails
intrigeri: Right. I don't know if our request is at fault, or if the BTS is buggy. Other teams make good use of usertags, so presumably our request should be fixed. At least the BTS UI is partially inconsistent. It is likely that the users tag needs to be removed from some issues. I will find out. Care to file a Fix request for Tails-related bugs on the Debian BTS ticket with this information, and/or work on this any further? Done and assigned to myself. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] machines do not start on USB sticks created using Tails USB Installer, due to a firmware limitation
intrigeri: Andreas Kuckartz wrote (01 Jan 2014 15:51:07 GMT) : The list of known issues contains this section: ThinkPad X220, X230, T430, T520, T530 and E325 These machines do not start on USB sticks created using Tails USB Installer, due to a firmware limitation. [...] I own a different Lenovo model which might be affected by this issue. Interesting. I suspect our (experimental) UEFI images would solve this issue for you, and would be very interested in the results if you had time to test it: https://mailman.boum.org/pipermail/tails-dev/2013-December/004538.html That worked! Two different USB sticks (one containing an SD card) created with the Tails Installer (Clone Install) boot and I could create a persistent volume on them. I used this image: tails-i386-feature_uefi-0.23-20140104T0920Z-3305611.iso The laptop used was a Lenovo ThinkPad X130e. Let me know if you need more details and I will send them by private mail. BTW: The automatic memory wiping seems to fail - that worked before. The text above seems to indicate that the problem occurs while reading the data on the stick, but I am not sure if that is correct. I tried to find more information about the firmware limitation but found nothing so far. Can anyone here provide more information? The limitation is that some crappy pieces of firmware are not able to boot in Legacy BIOS mode from a device that has a GPT. I already downloaded newer firmware but have not yet installed it. I am also considering migrating to coreboot but I currently do not want to spend much time on _that_ adventure. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] machines do not start on USB sticks created using Tails USB Installer, due to a firmware limitation
The list of known issues contains this section: ThinkPad X220, X230, T430, T520, T530 and E325 These machines do not start on USB sticks created using Tails USB Installer, due to a firmware limitation. A workaround for some of these machines is to use the manual installation process. Note, however, that this technique does not allow you to set up a persistent volume. https://tails.boum.org/support/known_issues/#index9h2 I own a different Lenovo model which might be affected by this issue. The text above seems to indicate that the problem occurs while reading the data on the stick, but I am not sure if that is correct. I tried to find more information about the firmware limitation but found nothing so far. Can anyone here provide more information? Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] basebox from scratch Re: Support for modern Vagrant
intrigeri: intrigeri wrote (18 Dec 2013 20:15:16 GMT) : David Wolinsky wrote (18 Dec 2013 17:22:07 GMT) : What's your preferred method? Shall we just hack the keys into the git repo for now until the maintainer of the box has a chance to update it? Unfortunately, the box currently has no maintainer. If someone gives me precise instructions, that work on current Debian unstable, to build an up-to-date one, then I'm happy to upload it. Any taker? I realized I was unclear. Such instructions could: 1. either allow me to build a new, up-to-date basebox from scratch (possibly hard, likely Veewee has changed 10 times since then and our stuff does not work anymore, as it is customary in the Ruby ecosystem) It would also reduce the trusting trust issue if the steps to build the basebox were documented and reproducible. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installed Tails using Tails Installer: USB stick does not boot
sajol...@pimienta.org: Andreas Kuckartz: I installed Tails 0.22 using Tails Installer. But the USB stick does not boot. It I never used the Tails Installer of older Tails versions. Booting is no problem from the same USB stick when Tails is installed on it using the isohybrid+dd method of installation. Hi Andreas, Unfortunately we can't help you, because your description doesn't include enough information. Please read our bug reporting instructions at https://tails.boum.org/doc/first_steps/bug_reporting/tails_does_not_start/ And also, could you move this thread to our support channels? Either tails-supp...@boum.org for a public list otherwise ta...@boum.org is fine as well. That way we reduce the noise on tails-dev@boum.org which is meant for development issues. Thanks, but I do not need support for that problem. I only tried to use the Tails Installer to be able to test the incremental update feature which seems to require that Tails is installed using the Tails Installer: https://tails.boum.org/news/test_incremental_upgrades/ I will wait until incremental updates can be used when Tails was installed using the isohybrid+dd method of installation. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installed Tails using Tails Installer: USB stick does not boot
intrigeri: Andreas Kuckartz wrote (18 Dec 2013 14:13:21 GMT) : I will wait until incremental updates can be used when Tails was installed using the isohybrid+dd method of installation. I doubt this is ever supported. I originally had assumed that the result does not in any way depend on the used installation method. Why is there a difference between the two methods? And what is the difference? Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Installed Tails using Tails Installer: USB stick does not boot
I installed Tails 0.22 using Tails Installer. But the USB stick does not boot. It I never used the Tails Installer of older Tails versions. Booting is no problem from the same USB stick when Tails is installed on it using the isohybrid+dd method of installation. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please test incremental upgrades (from 0.22~rc1 to 0.22~rc2)
intrigeri: Most ETA's I see displayed are seriously wrong, so I'm not convinced it generally helps at all UX-wise. Is it really considered as a best practice these days to display an ETA along with progress bars for long operations? When I am downloading large files (such as Tails binaries ;-) Iceweasel displays progress bars and ETAs and that helps me. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Old unresolved security-related Firefox issue
That Firefox issue has now been resolved as WONTFIX. This part of the closing comment by David Anderson might also be interesting here on this list: - The best path forward for JIT security is sandboxed content processes, which is in progress for both Desktop Firefox and Firefox OS. Sandboxing will greatly reduce the threat of JIT exploits, and it's unlikely any other solution will be as effective. For Desktop, it's part of the Electrolysis effort: [1] https://wiki.mozilla.org/FoxInABox [2] https://wiki.mozilla.org/Electrolysis - Cheers, Andreas --- Andreas Kuckartz: The security of Firefox/Iceweasel is important for the security of Tails. I therefore suggest to have a look at this old unresolved Firefox issue and vote for it. Years ago people working for RedHat spent a lot of time to create a patch which does not yet seem to have been applied. Resolving the issue would make Firefox more secure (even when SELinux is not used): SELinux is preventing JIT from changing memory segment access https://bugzilla.mozilla.org/show_bug.cgi?id=506693 Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Old unresolved security-related Firefox issue
The security of Firefox/Iceweasel is important for the security of Tails. I therefore suggest to have a look at this old unresolved Firefox issue and vote for it. Years ago people working for RedHat spent a lot of time to create a patch which does not yet seem to have been applied. Resolving the issue would make Firefox more secure (even when SELinux is not used): SELinux is preventing JIT from changing memory segment access https://bugzilla.mozilla.org/show_bug.cgi?id=506693 Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Fwd: Proposed release goal: SELinux
FYI This proposed Jessie release goal might be relevant for Mandatory Access Control in Tails (https://labs.riseup.net/code/issues/5370). Cheers, Andreas Original Message Date: 2 Oct 2013 08:00:43 +0200 From: Andreas Kuckartz a.kucka...@ping.de To: Debian Release debian-rele...@lists.debian.org Cc: selinux-de...@lists.alioth.debian.org A few minutes before the deadline I created https://wiki.debian.org/ReleaseGoals/SELinux Goal description: Allow the users to enable SELinux enforcing mode on their machine without too much hassle. * Improve the SELinux reference policy, this is currently being worked out with upstream. * Be sure that when a init/maintainer script is creating a file/directory the label on disk is properly (re)set. * Be sure that SELinux aware applications have SELinux support enabled and that's it's working properly. That goal was only briefly discussed on selinux-de...@lists.alioth.debian.org a few hours before the deadline. Further volunteers or advocates should add themselves on the Wiki-page. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Relative security of Debian unstable / testing / stable
The current official Debian position on security regarding unstable and stable: Q: How is security handled for unstable? A: The short answer is: it's not. Unstable is a rapidly moving target and the security team does not have the resources needed to properly support it. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. http://www.debian.org/security/faq.en.html But my empirical observations are that this has not been true for several years now: Debian unstable has been promptly supported with security fixes. Is anybody aware of any research regarding the relative security of Debian unstable / testing / stable or similar Linux distributions? Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Relative security of Debian unstable / testing / stable
intrigeri: Andreas Kuckartz wrote (16 Sep 2013 08:04:44 GMT) : But my empirical observations are that this has not been true for several years now: Debian unstable has been promptly supported with security fixes. Well, yes and no. It is correct that Debian unstable is not supported by the security team. But this does not mean that it's in a bad shape security-wise: it's just hard to predict and rely upon. Security fixes in unstable generally do happen fast (and certainly faster than in testing since the secure-testing effort faded out), *but* it all depends on the package maintainers. Hoping it helps :) Yes, thanks. That is in line with what I have observed. If it all depends on package maintainers that might imply that unstable is generally more secure than stable. And upstream developers generally are more interested in maintaining the most recent versions of their software. If you are interested to go on with this discussion, then perhaps it could be moved to a more appropriate place such as the debian-user mailing-list? I probably will move it to debian-secur...@lists.debian.org. (Or it should be clarified how this relates to Tails development.) Well, Tails can choose between stable and unstable packages, therefore statistical security might be a factor in such decisions. My hypothesis is that generally (but not always) unstable is more secure regarding several security aspects (but not all). Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] SELinux AppArmor
Alan: On Fri, 13 Sep 2013 12:40:46 -0400 Stephen Stewart stewartan...@hotmail.com wrote: The NSA's SELinux or Novell's AppArmor, both of which are implemented as Linux Security Modules (LSM) are compiled into the Linux kernel. It seems LSMs are mutually exclusive. Fedora and Red Hat Enterprise Linux use SELinux, Ubuntu and SuSE use AppArmor. Current Tails doesn't use any LSM (they are compiled in but disabled), but we are in the process of using AppArmor (https://labs.riseup.net/code/issues/5370). It is interesting to have a look at Google Trends for SELinux versus AppArmor: http://www.google.com/trends/explore?q=%22selinux%22+%22apparmor%22#q=selinux%2C%20apparmorcmpt=q (I still prefer SELinux.) Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] SELinux
Most Linux system administrators probably don't know what to make of Mandatory Access Control and the Linux kernel security architecture but I do not think that this is a strong argument against using it in Tails. A recent article worth reading: Overview of Linux Kernel Security Features Thursday, 11 July 2013 Editor's Note: This is a guest post from James Morris, the Linux kernel security subsystem maintainer and manager of the mainline Linux kernel development team at Oracle. https://www.linux.com/learn/docs/727873-overview-of-linux-kernel-security-features/ Security would be improved by enabling SELinux enforcing mode (BTW: CyanogenMod will do that soon: http://www.cyanogenmod.org/blog/this-week-in-cm-july-19-13). Using permissive mode can help to prepare for such a step. There are many things which can be done to improve Tails: https://labs.riseup.net/code/projects/tails Removing Linux security features does not belong to those as far as I am concerned. And I am more concerned about software where it is unknown if the NSA was involved. Cheers, Andreas --- Stephen Stewart: TAILS Developers, SELinux was created by the NSA. I first encountered SELinux as a userland program that ran on Red Hat and Fedora Linux, before it was submitted to kernel.org, but it is now built into the kernel of most Linux distributions. Since most Linux system administrators don't know what to make of SELinux, it usually runs in permissive mode and is largely ignored. I am convinced it is completely unnecessary and, considering the source, I suspect it may be hazardous. I'm concerned that SELinux may compromise TAILS and would encourage you to remove it from the kernel. Failing that, I will recompile TAILS without SELinux myself. Please let me if you want me to do that. Stephen Stewart ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Wiki password reset: Error: Failed to send mail
intrigeri: Out of curiosity, now that our website has neither the forum nor the todo list anymore, what part of it did you mean to edit? This page: https://tails.boum.org/blueprint/Mandatory_Access_Control/ I intended to update it a bit - Debian Wheezy was released a while ago - and make it more SELinux friendly ;-) BTW: It is significant that SELinux is included in recent versions of Android and CyanogenMod. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Wiki password reset: Error: Failed to send mail
Password reset does not work for Wiki accounts: Error: Failed to send mail Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Mandatory Access Control, SELinux and Tails
intrigeri: I'm curious: have you been running a GNOME desktop in enforcing mode? No, I am usually using KDE in permissive mode. There are still some AVC warnings I want to get rid off. But due to the involvement of Red Hat in both SELinux policy development and Gnome I do not expect that many difficulties with Gnome and SELinux, but I did not try. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Mandatory Access Control, SELinux and Tails
intrigeri: Next question, then: is it compatible with aufs, or perhaps it does not need to be? Good questions, but I have no real answer to them. The AuFS page has this statement on Aufs3 in the section titled Features: Features or just an idea in the future (see also design/*.txt), ... - xattr, acl http://aufs.sourceforge.net/ So I think that means that there is no xattr support in Aufs3. But I am not sure what the implications are. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Mandatory Access Control, SELinux and Tails
Is anybody currently working on adding Mandatory Access Control to Tails? Any strong opinions regarding possible solutions? See https://tails.boum.org/todo/Mandatory_Access_Control/ I would suggest to start with SELinux in permissive mode and incrementally adapt the policy so that in a later stage - when no access denied warnings occur while using Tails - enforcing mode can be switched on. The main effect of that change probably would be on the build process because the initial file labeling takes some time and requires a reboot. I have some experience with SELinux and Debian unstable which might help, but installing the relevant SELinux packages and enabling permissive mode is quite straightforward (at least in Debian unstable ;-). Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Mandatory Access Control, SELinux and Tails
https://tails.boum.org/todo/Mandatory_Access_Control/ I just tried to update that page but got an error message as a result: Error: Sorry, but that looks like spam to blogspam: bayes, 13 links found :-/ Can someone tell me how I can edit that page?! I did not even add a link but only wanted to change one... This was the text I intended to put on the page: SELinux --- Developed initially by big brother (NSA). It is pretty hard to write and maintain policies but such policies exist and they can mostly be used by different Linux distributions. Support in Debian has improved since the release of Squeeze. - http://etbe.coker.com.au/2012/06/17/debian-selinux-june-2012/ - selinux policies are part of Squeeze - GNOME, policykit, etc. are supported by Debian-packaged policies Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails Vagrant VM: repositories in /etc/apt/sources.list use http instead of https
Thanks for the suggestion to use vagrant ssh. I am now having a close look at the VM from inside. I noticed that all the repositories configured in /etc/apt/sources.list use http instead of https. I suggest to change that to reduce the threat of MITM attacks. To do that apt-get install apt-transport-https is required. I am experimenting with these and other changes. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] rake build fails
intrigeri: The funny thing is that it's not needed anymore (see recent email about ikiwiki on tails-dev), Seems to be this one: https://mailman.boum.org/pipermail/tails-dev/2012-June/001331.html but the Vagrant stuff was not updated yet. Feel free to update it so that it uses ikiwiki from current Debian testing/unstable (= 3.20120516), instead of building its own. Am I correct that this file has to be modified? /vagrant/provision/setup-tails-builder Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] rake build fails
I am trying to build tails by following the steps on this page: https://tails.boum.org/contribute/build/ But rake build results in: - 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. fatal: remote gaffer already exists. gaffer.ptitcanardnoir.org[0: 82.225.70.86]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) rake aborted! The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! chmod +x /tmp/vagrant-shell /tmp/vagrant-shell Tasks: TOP = build = vm:up (See full trace by running task with --trace) - What should I do? Where should I add --trace? Thanks, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] rake build fails
intrigeri: Andreas Kuckartz wrote (07 Jul 2012 13:11:38 GMT) : gaffer.ptitcanardnoir.org[0: 82.225.70.86]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Looks like that host is down, right. The funny thing is that it's not needed anymore (see recent email about ikiwiki on tails-dev), but the Vagrant stuff was not updated yet. Feel free to update it so that it uses ikiwiki from current Debian testing/unstable (= 3.20120516), instead of building its own. If you do so, please send us a patch: https://tails.boum.org/contribute/how/code/ I do not yet know much about the tails architecture and build process, so it currently is not that likely that I will be able to provide this patch soon. I now tried the manual build process and noticed that root access is required (Every build commands must be run as root). I am very hesitant to run an unknown build process as root. Why is root access required? Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
