Re: [Tails-dev] [tails-dev] [#10972] Port Tails to arm platforms
Hi, Tails wrote (12 Feb 2016 19:16:12 GMT) : > intrigeri: >> Tails wrote (11 Feb 2016 11:47:00 GMT) : >>> > intrigeri: >> I think you should focus on packages that are in the "devel" suite of >> our APT repository. OK? >>> > OK. I guess I should get more familar with the APT repositories ... >> Maybe :) > As far as I got more familar with the repositories now ... I guess an > actual list of packages to possibly port to tails should result from the > following steps: I think it's much simpler. Basically, the only custom APT suite we'll be using in next Tails major release is the 'devel' one ⇒ just rebuild the packages that are currently in there. What are these packages? Either get yourself a Debian system (debootstrap chroot, VM, Tails, whatever) and add this APT source: deb-src http://deb.tails.boum.org/ devel main ... or look into http://deb.tails.boum.org/dists/devel/main/source/Sources directly. You can even skip some packages that are currently not used (and might not build on Jessie): gnome-theme-windows8, gnome-theme-xpluna, gnome-xp-icon-theme, window-picker-applet and xp-cursor-theme. ⇒ we're talking of 12 source packages to rebuild. To understand more about our custom APT repository, start at https://tails.boum.org/contribute/APT_repository/ :) 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] [tails-dev] [#10972] Port Tails to arm platforms
Hi, intrigeri: > Tails wrote (11 Feb 2016 11:47:00 GMT) : >> > intrigeri: >>> >> I think you should focus on packages that are in the "devel" suite of >>> >> our APT repository. OK? >> > OK. I guess I should get more familar with the APT repositories ... > Maybe :) As far as I got more familar with the repositories now ... I guess an actual list of packages to possibly port to tails should result from the following steps: 1.) clone devel branch (stable should also be suitable?) 2.) using package sources as listed in config/chroot_sources/ in *.chroot_sources 3.) using config/chroot_apt/preferences - Pin-Priority defines the search order, Pin the location within the apt tree 3.) for each package listed in config/chroot_local-packagelists/tails-common.list if package is found as module on http://deb.tails.boum.org/pool/main/ and has no armXX .deb -> candidate for arm port else Check if a armXX .deb is available If NOT -> candidate for arm port As fare as I saw config/chroot_local-patches does only affect configuration items, no source code. Right way? Anything missing/missunderstood? Thanks for any hints/help! -- Best Regards! n9iu7pk PGP pool.sks-keyservers.net 0x4D12FFCB 7426 4598 B5AD 4D12 1699 C710 D602 E331 4D12 FFCB ___ 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] Reducing attack surface of kernel and tightening firewall/sysctls
sajolida wrote (12 Feb 2016 17:20:16 GMT) : > So I'm just wondering whether we have tickets to track this? We have none, as far I know. Someone volunteered to create them back them, once it was clarified that this was something we wanted, but didn't do it in the end. Feel free to create it if you see some value in it. Personally, it would not help me yet, but hopefully soon I will need to create one :) Cheers! ___ 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] Reducing attack surface of kernel and tightening firewall/sysctls
intrigeri:
> intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
>> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>>> I see this thread has been quiet for a bit more than a month.
>
>>> Maybe it's time for someone to sum up whatever consensus was reached,
>>> and whatever disagreement may still be remaining?
>
>>> Jake, maybe?
>
>> Ping?
>
> OK, OK, here we go :)
>
> Thank you all for your contribution!
>
> I have compiled everything that everybody seemed to agree in this
> thread, into a Git branch (feature/various-firewall-hardening).
> I'll build it and run our automated test suite on it.
>
> There's one question below, mainly for Oliver-Tobias, but anyone else
> is free to have a look.
>
> Anyone who participated in this thread, please consider checking my
> summary below. This is _not_ my area of expertise, and it may very
> well be that I got something wrong from your discussion, which is why
> I was asking for someone else to sum it up a year ago.
> Thanks in advance!
It's even less my area of expertise but I remember this discussion
around "RELATED ESTABLISHED" as interesting :) Nonetheless, searching
for "RELATED ESTABLISHED" on Redmine doesn't return anything.
So I'm just wondering whether we have tickets to track this?
> Note that all patches pasted below are entirely untested.
>
> Regarding the firewall rules, I think the agreement that was reached
> is:
>
> --- a/config/chroot_local-includes/etc/ferm/ferm.conf
> +++ b/config/chroot_local-includes/etc/ferm/ferm.conf
> @@ -15,7 +15,7 @@ domain ip {
> policy DROP;
>
> # Established incoming connections are accepted.
> -mod state state (RELATED ESTABLISHED) ACCEPT;
> +mod state state (ESTABLISHED) ACCEPT;
>
> # Traffic on the loopback interface is accepted.
> interface lo ACCEPT;
> @@ -25,7 +25,7 @@ domain ip {
> policy DROP;
>
> # Established outgoing connections are accepted.
> -mod state state (RELATED ESTABLISHED) ACCEPT;
> +mod state state (ESTABLISHED) ACCEPT;
>
> # White-list access to local resources
> outerface lo {
___
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] About the future of the OpenPGP verification instructions
I wanted to discuss this during the February meeting but we ended up doing different things. So I thought I might raise the issue here instead. When I'm saying "here", I'm actually not sure whether tails-ux or tails-dev is the best place. So I'm writing to tails-dev as I got more concerns raised by people from tails-dev than by people from tails-ux :) As a reminder, I initially submitted a branch for 2.0 which removes the current OpenPGP verification instructions. We ended up not doing this and, for the time being, pointing to the Installation Assistant by default, pointing to the old installation instructions as a fallback, pointing to the old OpenPGP instructions from the "Learn how to do this" link after a successful verification through the browser extension, but we didn't decide yet about the future of these old pages. The ticket is #11027. The installation assistant forces people to do a verification equivalent to HTTPS (Browser extension or BitTorrent). With this in mind, the OpenPGP verification only makes sense for people: - Using the web-of-trust. As we're documenting in /install/debian/usb. Relying on TOFU. Note that with automatic upgrades and in the future with full self upgrades (#7499), a typical user won't download and verify ISO images very often, or at least rely on this "first use" for quite a while. TOFU only improves the security of the subsequent uses. Correlate downloads (/doc/get/trusting_tails_signing_key#index1h1). Which is not a proper cryptographic technique and is quite impractical for a first-time user. So really, the OpenPGP verification mostly makes sense if using the web-of-trust. The current instructions focus on step-by-step instructions on how to download the key and verify the ISO image against it; which doesn't provide strong authenticity (see /download.html#index3h1). They are fairly complicated (see the user support load on the "Not enough information to check the signature validity." message) but were very relevant before we could provide HTTPS-equivalent verification for everybody. In them, trusting the Tails signing key was proposed as an additional check to provide authenticity. I think we should acknowledge that proper OpenPGP verification with the web-of-trust is not accessible to first-time users who landed on our website and want to give Tails a try. But are for people who already know the basics of OpenPGP for encrypting their emails, for example. So as a general direction, I think we should focus on: - Documenting better the strategy behind the web-of-trust which is the game changer here. - Pushing bits of OpenPGP verification to Tails Installer. And not so much on providing step-by-step instructions for OpenPGP basics. Not that it's a bad thing as such but more as a question of priority. Also note as a general policy, documenting how to use Gpg4Win, GPGTools, etc. could be considered out-of-scope in our documentation. Regarding what to do now, I propose we: - Rescue /download.html#index3h1 and make it clear in the intro that this is meant for people who already know the basic of OpenPGP and insist more on the web-of-trust verification. - I'm not sure it's relevant to keep /doc/get/verify_*, further improve these pages (see #7147), etc. Maybe helping upstream on the long-term would be better but we've not been very good at this in the past. - I'm not sure what to do with the download correlation technique right now, but I don't mind leaving it around for some time. ___ 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] Dynamically changing ISO URL in DAVE
Hi, [there's one question for sajolida below, even if most of my message is mainly meant to Giorgio and U.] Giorgio Maone wrote (11 Feb 2016 16:15:30 GMT) : > I can't see any particular problem (except for some less than idiomatic > EcmaScript style instances, e.g. new Array()) in your code. Thanks! Good to know that this should work in a Firefox add-on. I'll let U. decide if she wants more such feedback, where, when, and how :) > The only caveat for integrating it into DAVE is that every time the > extension starts/resume a download or is installed/upgraded/reloaded, > downloader.js loops through all the download jobs already "known" to the > browser's built-in download manager and, if any of them matches the URL > in the IDF, picks the active one, or if none is currently active, the > most advanced one and makes it "current", resuming it if required. Wow, congrats for caring about all these use cases in DAVE! > Therefore, rather than just checking for equality with the URL provided > by the IDF, we should check whether these jobs match any of the URLs > produced by combining the mirror host names with the path provided by > the IDF, and force the mirror of the "choosen" download job if any can > be made current. Right! (So I've created a dedicated ticket for the implementation side of this, and pointed to your reply so we keep this in mind: https://labs.riseup.net/code/issues/11109) > Beside that, I think the JSON should be fetched every time the UI page > is reloaded (of course obeying to server-side caching directives), just > like we currently do with the IDF. I'm afraid I don't know under which circumstances the UI page is reloaded, so I lack the background info to integrate this proposal into my mental representation of the problem. @sajolida + @Giorgio: is this done as part of the Installation Assistant or DAVE course of operation, or only due to external factors (e.g. the user manually reloading the page, or restarting their browser)? >> Will you be happy to review our DAVE patch, once we have something >> that Works For Me™? Likely we will be working on it on April 6-8, and >> ideally we would need the new feature to be on AMO by the end >> of April. > Of course I will. :) >> Also, it would be awesome if we could ask you one or three questions >> when we hit technical difficulties along the way, > No problem, just drop me an email and if asked I'm also going to join > the #tails-dev channel ASAP. Cool. Note that our official development channel has moved to XMPP: https://tails.boum.org/contribute/chat/ 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] Allowing all people with Redmine "Contributor" status to edit ticket description?
sajolida wrote (12 Feb 2016 13:02:16 GMT) : > I understand that then we would stop using the role "Contributor" for > Tails and only rely on "TailsContributor", right? Yes. ___ 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] Allowing all people with Redmine "Contributor" status to edit ticket description?
intrigeri: > currently, most of us have the "Contributor" role in Redmine, and > have thus fairly limited credentials. E.g. until a few days ago they > could not add watchers, and they still cannot edit a ticket's description. > > Note that the power associated with a given Redmine user role are > global on this Redmine instance, and thus shared with other projects, > so we can't just take over what "Contributor" means. > > I will then create a new user role called "TailsContributor", based on > the "Contributor" one, that will give us more flexibility to give more > permissions to our contributors, as we wish. I understand that then we would stop using the role "Contributor" for Tails and only rely on "TailsContributor", right? I'm fine with this. ___ 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] Fwd: [tor-dev] Git users, enable fsck by default!
intrigeri: > This should do it (untested): > > --- a/config/chroot_local-includes/etc/gitconfig > +++ b/config/chroot_local-includes/etc/gitconfig > @@ -1,2 +1,4 @@ > [color] > ui = auto > +[transfer] > + fsckObjects = true When I sent my previous email I thought about our personal setups, but indeed it might make sense to apply this in Tails by default. So I created #11107. ___ 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
Spencer wrote (12 Feb 2016 02:43:41 GMT) : > Are these the typical Thumbs.db & .DS_Store files, or are > there others? I don't keep a record of them and don't remember, sorry. > Where are they located, in some/all folders, at top of the package directory, > or somewhere outside of Tails? I never looked deeper than the root directory of the system filesystem. ___ 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] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls
Hi, Jurre van Bergen wrote (11 Feb 2016 16:46:47 GMT) : > Forwarding e-mail. Thanks :) > Date: Thu, 11 Feb 2016 12:28:35 +0100 > From: Cornelius Diekmann > A conservative change to the tails config would be to keep an RELATED > rule but limit it to known good ICMP messages. Yes, this was proposed on the thread; in the email you're replying to I explained why I didn't pick this option, mainly because no (pseudo-) implementation thereof has been proposed nor discussed yet. Given this discussion has been going on for more than a year, and apparently most of the people involved in it are not quite into the summing up and making decisions game, my goal here was to build on top of what has been agreed upon as an improvement already, and to actually make it happen. This of course works only if the current proposal does not break too much stuff (see discussion below about Destination Unreachable). In any case, I'm happy if people discuss how we can make things even better in a second iteration :) … especially since once we do IPv6, apparently we can't escape dealing with this problem. > What I did not see in the discussion is the Destination Unreachable ICMP > error. If a host is unreachable, tails will eventually find out by a > timeout. But with an unreachable message, a user does not have to wait > for a timeout. Good point! I say let's evaluate if this is a _practical_ problem for Tails first. In the current state of Tails, if I got it right this should only affect: * trying to access an unreachable host on the LAN: indeed this has the potential to cause minor usability issues, e.g. when the network printer is turned off; it would be nice if someone tested how Tails _currently_ behaves in this respect (just configure a network printer with an unused IP on the LAN), and how things would look like with the firewall changes one can find in the feature/various-firewall-hardening branch; * Tor trying to connect to an entry guard or directory authority that is currently unreachable: I'm curious what would happen in practice; * I2P: I don't know (and I don't maintain our I2P support) * Unsafe Browser: very minor issue IMO 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.
