[Tails-dev] Git vs. point-release
Hi, I'm getting increasingly fed up with cherry-picking patches from the devel branch into testing / stable branches. That process creates a lot of duplicate commits, and makes it quite hard to see what's new in a release being prepared / what commits are possible candidates. So I propose we do the following experiment from now to the release of the probable Tails 0.10.1: Anyone who wants to prepare a bugfix that may end up in 0.10.1 should: 1. Fork from the stable branch (*not* from devel!): git checkout -b bugfix/NAME_OF_THE_BUG origin/stable 2. Do their job: $EDITOR ; git commit 3. Test, test, test. 4. Merge bugfix/NAME_OF_THE_BUG into devel. 5. Propose bugfix/NAME_OF_THE_BUG for merging into stable (unless it's really trivial and well tested - in that case, be bold, merge into stable and deal with the mess if needed). Cheers, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: WhisperBack bug reporting application
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org mailing-list.) I tried to use the tails bug reporter but it doesn't work. It fails in two ways: first, it simply cannot seem to make a proper smtp connection and thus fails to send any report. [...] The bug reporter should actually post over http to a hidden service rather than using smtp if smtp services can't be reached regularly. The system that runs the hidden service used by whisperback as an SMTP relay currently has stability problems. We plan to setup other instances of the same hidden service to solve that problem. Besides, we fail to see what using a relay using HTTP rather than SMTP would change. There is no exit policy matters for a hidden service, is it? Please elaborate if we missed something. Secondly, it doesn't work if you've changed or removed the .gnupg directory on the file system. With the upcoming persistence feature, this will actually become an issue that will be faced by more users. To solve it, we propose to setup a specific keyring to be used by whisperback e.g. in /usr/share/whisperback. - https://tails.boum.org/todo/whisperback_should_use_a_dedicated_keyring/ -- pgp9HQvwWQwQS.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: USB stick verification and duplication
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Tails should include a program for usb stick verification - so one can use one tails install to verify or create others. This should also aid in detection of backdoored tails installs if someone ever roots someone via a client side exploit or tampering with the usb disk directly. We created a wishlist page about the first part: https://tails.boum.org/todo/tool_to_verify_another_Tails/ The stick duplication feature is already implemented in our upcoming installer software. -- pgpXHUB6auVWp.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: Tahoe
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) As far as other software goes, Tahoe would be quite useful to include. Ok. Some non-trivial things must happen before we consider this seriously, but we would like to: https://tails.boum.org/todo/include_tahoe/ -- pgpkaS8JcBN1y.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: grsec and friends
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) The kernel: grsec kernel + pax should be a major priority. We agree it would be great if Tails shipped with tools that make it harder to practically exploit security issues. Both mandatory access control systems (AppArmor, RBAC) and general kernel hardening patches are such tools, and we are considering both. Debian has started shipping AppArmor-enabled kernels recently, while the grsec effort is far from having reached this goal; therefore, our time being pretty limited, it seems likely we'll consider shipping AppArmor MAC policies instead of RBAC policies or a kernel patched with PaX. This decision is far from being final yet; as you can see on our roadmap, there are a few things we find more urgent to address first: https://tails.boum.org/contribute/roadmap/ FYI our quick review of MAC systems from Tails PoV is there: https://tails.boum.org/todo/Mandatory_Access_Control/ -- pgpcpIgfTICIg.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: lid close vs. shutdown
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) The lid should not cause a shut down as it results in lost data upon first discovery of this feature. Agreed, was disabled in Tails 0.10. -- pgpeUXOd4IsOu.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: Tor 0.2.3.x
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Tor should be upgraded to the 0.2.3.x branch to ensure that the seperate streams feature is activated. This is critical for a system such as tails. We agree this feature will be very welcome for Tails usecase; some of us are testing it on their private boxen, and we created a page about it in our todo list: https://tails.boum.org/todo/separate_Tor_streams/ However, we do not think it would be wise to ship an alpha version of Tor in Tails; a version of Tor that works reliably enough to be labelled as stable by the Tor project seems critical for a system such as Tails. -- pgpuWKSjw06Ig.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: pcmcia / firewire / etc.
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Disable all firewire kernel modules. This will help fight against forensics programs that will attempt to suck out memory with the internal firewire or a cardbus/pcmcia card. Disable all pcmcia kernel modules; we should try to power off the bus entirely. Thanks for bringing up these issues. They raise the question of usability vs. security balance. One of the Tails usecase is indeed Working on sensitive documents, which includes audio and video. Such a task might include using external firewire devices. We thus have to discuss and investigate this issue furether. Will be tracked there: https://tails.boum.org/todo/disable_expresscard__63__/ https://tails.boum.org/todo/disable_pcmcia__63__/ https://tails.boum.org/todo/disable_firewire__63__/ Recent Linux kernels shipped by Debian use filtered physical DMA; unfiltered physical DMA seems to be disabled (CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set). Do you know which class of attacks is still practicaly doable on such a system? -- pgpOeJvDcD6Xg.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: upgrades
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Tails should try to check for updates over Tor regularly to ensure that it hasn't been updated; it should alert the user if there is no update after a reasonable window of time. Tails does check at boot time if the running version is affected by security problems. See config/chroot_local-includes/usr/local/bin/tails-security-check in our Git repository. However, when discussing this topic, we had misread your proposal, and thought you were suggesting to check if *Tor* should be updated. Therefore, we wrote the following reply, that I'm sending anyway for what it's worth: FYI Tor is not that often the weak link that forces us to do a quick release because of huge security or anonymity issues. Our release timing depends more, say, on the Mozilla security updates schedule. Then, our problems wrt. the need for quick updates is more general, and quite harder, than if Tor was the usual suspect. We already have the infrastructure and software needed to tell every Tails users they must upgrade this or that or do whatever is needed. So, the alerting the user part is covered already. Maybe you were suggesting to setup some way to go further, that is to *upgrade* Tor on a running Tails system. We might want to setup semi-automated upgrades at some point (that is, we would maintain a public list of packages that can be safely upgraded without causing any harm, possibly in a APT repository, and Tails would fetch packages from there). However, the time needed to properly test and maintain such a repository, as well as the additional complexity for user support, makes us very doubtful about such a thing. (Even once we get persistence for APT caches, and even dismissing the conffiles conflicts problem, that is.) That's why getting binary-level incremental upgrades looks like a safer bet: it would be much easier to manage and support, and the upgrade process would not have to be conducted at every boot; in case you're interested, see our research and test results there: https://tails.boum.org/todo/usb_install_and_upgrade/#index6h3 -- pgp7K9NwuMrd0.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: persistent APT cache
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) The dpkg cache should be populated at some point so that it is useful (eg: apt-get update) Currently, shipping APT indices inside the ISO image would be useless as most of them would be obsolete a few days after the release. APT would then download them again. Once persistence is implemented, opt-in inclusion of APT indices and cache is planned to be supported: https://tails.boum.org/todo/persistence/#index2h3 -- pgpubXangXmKU.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: NoScript
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Adding noscript to disable remote font loading among other things is a good idea. Done in Tails 0.10. -- pgp9hkZgmNP0X.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: mute microphone
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Disable the microphone unless a sound enabled application needs it. Attacks using the microphone are a point. However, disabling it hard enough so that it would actually defeat a serious attacker while still providing an option for the user to enable it seems us a non-trivial task and higher priority items are still in our todo list. Even though an attacker targeting Tails (or just a bit serious) could bypass the protection, muting the microphone by default might defeat some attacks. We thus added it to our todo: https://tails.boum.org/todo/disable_microphone__63__/ -- pgpfNDotLmpBG.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: Jitsi
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) Jitsi is a possible solution for voip/zrtp/otr that will complement and perhaps even replace pidgin/libpurple. We're considering Jitsi among other pieces of software (see https://tails.boum.org/todo/VoIP_support/ for details). Sure, it has tons of interesting features. However, the way it's developped and distributed (e.g. bundling more than 100 JAR files in the binary packages), although perfectly compliant with the involved free software licenses, makes it a pain for anyone to audit or package this piece of software, which explains we're a bit reluctant to ship it. See e.g. http://bugs.debian.org/627362 to get an idea of the problem. Anyway, have you successfully used Jitsi with Tor? -- pgpNlV2F72Tj3.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] WTF are those tons of messages?
Hi, all those messages are (split by thread) replies to Jacob's Tails review: https://trac.torproject.org/projects/tor/ticket/4639 Cheers, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: unbound
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) In the future, I suspect it will be useful to replace pdns with unbound. Please elaborate why unbound would be better. -- pgpL4NdvGVuez.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails: spideroak
Hi, (Please Cc: any subsequent reply to the public tails-dev@boum.org ML.) https://spideroak.com/engineering_matters seems like a nice addition as well This is not free software, is it? -- pgpoCl5DYYRUj.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
