Re: [Tails-dev] Hide internal drives when no admin password has been entered
Hi, tail...@ruggedinbox.com wrote (12 Jun 2015 04:38:31 GMT) : Please see this feature request in the Tails repository Local storage devices displayed- Tails DVD no admin (https://labs.riseup.net/code/issues/9554) where intrigeri suggested raising this issue on the mailing list. I wrote: the tails...@boum.org mailing-list. This is tails-dev@. 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] Hide internal drives when no admin password has been entered
Hi Peter, thanks for your input. Sadly, this discussion was erroneously started on tails-dev@, while it should have been started on tails-ux@ = let's wait for tail...@ruggedinbox.com to start it again in the right place, and then please resend your reply in that new thread. Sorry for the inconvenience. 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] [review'n'merge:1.5] feature/9513-OTR-v3
Hi, this branch installs libotr and pidgin-otr 4.x from wheezy-backports, to suport the OTRv3 protocol and multiple concurrent connections to the same account. Please review'n'merge into devel. (Yet another occurrence of doing the work in Debian, and then forgetting to follow-up on it in Tails.) 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] Hide internal drives when no admin password has been entered
On Jun 11, 2015, at 9:38 PM, tail...@ruggedinbox.com wrote: Please see this feature request in the Tails repository Local storage devices displayed- Tails DVD no admin (https://labs.riseup.net/code/issues/9554) where intrigeri suggested raising this issue on the mailing list. The basic premise being that hiding the internal drives in working in what I call safe mode (booting with no admin privileges) to be more consistent with Tails goals and objectives of consistensy than it is to show them. From a UX perspective, I am curious what the reasoning is behind the policy of associating access to local storage devices with the entry of an arbitrary admin password. In reality, there is no particular connection there. We can presume someone somewhere has the legal or moral authority to access the internal drives, but we have no basis to conclude that the current user is or is not authorized. This gives us two failure modes from one policy: A) an authorized user fails to gain access because he or she did not enter an admin password; B) an unauthorized user gains access by entering an admin password. Because the policy connects unrelated concepts, it can also mislead users. Someone might boot Tails without an admin password, not see the local drives, and assume that because Tails is a security-oriented OS, it never shows internal drives. Or someone might assume that Tails is like other Linux live distros that always give access to internal drives based on booting once with an admin password. I’m also curious whether internal storage devices are truly locked out if the current user didn’t enter an admin password. Is it just that we don’t auto-mount the filesystems, or is it more secure than that? I think I’d prefer that we adopt a policy of not displaying the presence of (or auto-mounting) internal drives regardless of whether an admin password is entered at boot time. If a password has been entered, we should provide an admin-only function, whether in the GUI or on the command line, or both, that allows users to discover and mount these drives. If no password has been entered, this function should not be operable. This solution avoids associating unrelated concepts and largely eliminates the potential for confusion. I’m entirely willing to have my mind changed by better arguments, of course. :-) . png ___ 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] [tor-qa] Tor Browser 4.5.2 is ready for testing
Georg Koppen: Hi, Tor Browser 4.5.2-build1 is up at for testing: https://people.torproject.org/~gk/builds/4.5.2-build1/ We actually rebuilt parts of the 4.5.2 bundles mentioned above to include the latest Tor (0.2.6.9) and above all a fixed OpenSSL (1.0.1n). We plan to release 4.5.2 on Monday, June 15. If you have the time, please give it a round of testing. The new bundles can be found on: https://people.torproject.org/~gk/builds/4.5.2-build2/ Georg This release provides a fix for the Logjam attack (https://weakdh.org/) and updates a number of Tor Browser components: Tor to version 0.2.6.8, Torbutton to version 1.9.2.6, NoScript to version 2.6.9.26 and HTTPS-Everywhere to version 5.0.5. Moreover, it fixes a possible crash on Linux and avoids breaking the Add-ons page if Torbutton is disabled. Here is the full change log: Tor Browser 4.5.2 -- June 12 2015 * All Platforms * Update Tor to 0.2.6.8 * Update HTTPS-Everywhere to 5.0.5 * Update NoScript to 2.6.9.26 * Update Torbutton to 1.9.2.6 * Bug 15984: Disabling Torbutton breaks the Add-ons Manager * Bug 14429: Make sure the automatic resizing is disabled * Translation updates * Bug 16130: Defend against logjam attack * Bug 15984: Disabling Torbutton breaks the Add-ons Manager * Linux * Bug 16026: Fix crash in GStreamer * Bug 16083: Update comment in start-tor-browser Georg ___ tor-qa mailing list tor...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-qa 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] [tor-qa] Tor Browser 4.5.2 is ready for testing
On Fri 2015-06-12 15:13:18 -0400, Georg Koppen wrote: We actually rebuilt parts of the 4.5.2 bundles mentioned above to include the latest Tor (0.2.6.9) and above all a fixed OpenSSL (1.0.1n). Please use OpenSSL 1.0.1o, and not 1.0.1n. 1.0.1n had an ABI breakage which was fixed in 1.0.1o. This might not be an issue for TBB in the common use case, particularly, if you're building all of TBB from source in one go, and nothing interacts with TBB's OpenSSL from outside TBB. But if any of your components were built against 1.0.1m or earlier (or end up being built against 1.0.1o or later in the future) and they need to interact with the 1.0.1n, you risk memory corruption. Regards, --dkg ___ 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] Hide internal drives when no admin password has been entered
On Jun 12, 2015, at 2:03 AM, intrigeri intrig...@boum.org wrote: Hi Peter, thanks for your input. Sadly, this discussion was erroneously started on tails-dev@, while it should have been started on tails-ux@ = let's wait for tail...@ruggedinbox.com to start it again in the right place, and then please resend your reply in that new thread. Sorry for the inconvenience. Ah, you’re right! I should have checked. Thanks for letting me know, and yes, I’ll re-post. Best, . png ___ 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] [review'n'merge:1.5] feature/9567-move-check_po-to-jenkins-tools
Hi, for #8358 (Automatically check PO files in all our repositories) a new jenkins-tools Git repo has been created, and the check_po script has been copied there. It would be impractical to have this script live in two different Git repositories, so this branch: * adds the jenkins-tools repo as a submodule on the main Git repo; * replace the current wiki/src/contribute/l10n_tricks/check_po.sh with a symlink to submodules/jenkins-tools/slaves/check_po, so that the workflow of translators and RMs isn't affected too much; * updates the translators doc accordingly. I'd like to see that in 1.5. 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] [review'n'merge:1.5] feature/9381-ship-amd64-syslinux
Hi, as you may know already, Tails Installer uses the syslinux binary shipped in our ISO, so that the version of the syslinux modules we install match the version of the syslinux binary being used. Given this, once Tails Installer is in Debian/Ubuntu, we'll need to have an amd64 syslinux binary in our ISO filesystem, otherwise Tails Installer won't work on amd64 installations. The proposed branch implements that = please review'n'merge into devel. u.: it would be awesome if you quickly (and possibly hackishly) patched Tails Installer to make it use utils/linux/syslinux-amd64 instead of utils/linux/syslinux, and tested that on an amd64 Jessie or sid system. I'm not sure if that filename will work, for example (it might be that some lame iso9660 restriction applies here). If it doesn't work due to file naming, perhaps try syslinux.64 and syslin64, surely one of those will work :) 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.
