Re: [Tails-dev] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
intrigeri wrote (04 Feb 2015 10:36:45 GMT) : Good enough? Shall we try that and see? I've implemented #3 already, and can do #1 and #2 for Tails 1.3.1. Thanks for the replies. Created #8852 to track the next steps. ___ 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
On 04/02/15 11:36, intrigeri wrote: [...] Good enough? Shall we try that and see? I've implemented #3 already, and can do #1 and #2 for Tails 1.3.1. I'm convinced and have nothing more to add than well done!. :) 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
Hi, anonym wrote (26 Jan 2015 12:17:22 GMT) : While I appreciate #1 forcing us to track upstream, I think these build failures that depend on things external to Tails (e.g. fetching from APT repos outside of our control) are quite problematic: * They further complicate things for potential Tails contributors and adds the impression that Tails building is a fragile black art (rightfully so, actually!). * I worry that excessive build failure notifications will result in some kind of the boy who cried wolf syndrome for us, or at least that they become a nuisance we tend to ignore or delay, instead of something we appreciate. OK. Indeed, a build failure notification is not the nicest possible way to tell us we have work to do. IMHO we already expose ourselves too much to these kind of externally triggered build issues, and without a 24/7 on call developer that will fix them ASAP, I think we need less of them, not more. Sure. Besides, we already require manual intervention for upgrading the Tor Browser, so why not adding upgrade the apparmor profile to those instructions? Because we also need less manual steps in our dev and release process, not more? :) (Note, in case there was a misunderstanding, that the upstream AppArmor profile we're talking of here does *not* live in the Tor Browser Git tree, but in the torbrowser-launcher one.) The main problem I see with this approach is that it requires coordination very late in the release process, between the current release manager, and the ones of us who are best skilled at AppArmor magics. And then, it requires the latter to be available exactly at the right time once the Tor Browser has been updated. Given how we already have a hard time coordinating between the RM and the ones who run the manual test suite, I'm unconvinced that we can sanely add one more synchronization point along the way. Now, of course is the RM is skilled enough at AppArmor, everything becomes simpler, but that's not our current situation AFAIK. What do you think? My current preferred solution is: 1. Set up a Git repository forked off upstream torbrowser-launcher's. 2. Set up a daily Jenkins job that tries to merge upstream torbrowser-launcher's master branch into our own one. Have the ones of us who volunteered to maintain our AppArmor profile patch be notified on failure. 3. At ISO build time, download upstream profile from Debian *testing* (as opposed to directly from upstream's Git or from Debian unstable), and apply Tails-specific patch. I believe that #1 + #2 should drastically reduce the chances of #3 failing, and most importantly, put us a more relaxed situation whenever it happens: * #3 cannot fail due to upstream changes directly, since we get them proxied from Debian * the people who are most likely to update the torbrowser-launcher package in Debian will be aware when it's going to break the Tails build due to our patch not applying anymore once the package migrates from sid to testing * we have 5 days (migration time) to resolve the merge the conflict on our side, and then import the updated patch as soon as the new torbrowser-launcher package has propagated to Debian testing; granted, there can still be build failures, but the solution will be merge the branch that has already been prepared, rather than OMG we have to resolve this merge conflict in a hurry, which should be more relaxed * once we have our own mirror of the Debian APT archive, we can do even better: we'll control exactly when we get the new torbrowser-launcher package, and then we can coordinate it with importing the updated patch, so that no breakage happens at all Good enough? Shall we try that and see? I've implemented #3 already, and can do #1 and #2 for Tails 1.3.1. The main problem with this approach is that if a Tor Browser update requires changes in the AppArmor profile, then our build will be broken until a new torbrowser-launcher is released, uploaded, and then migrates to Debian testing. Once Tor Browser upstream itself ships AppArmor profiles, the situation will be entirely different, though, so hopefully all this discussion is about the current, temporary situation. 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
On Wed, Feb 04, 2015 at 12:10:31PM +0100, anonym wrote: On 04/02/15 11:36, intrigeri wrote: [...] Good enough? Shall we try that and see? I've implemented #3 already, and can do #1 and #2 for Tails 1.3.1. I'm convinced and have nothing more to add than well done!. :) I do too. That sounds more bullet-proof than the first iteration. bert. ___ 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
hi, bertagaz wrote (25 Jan 2015 12:14:21 GMT) : While I think I could help with maintaining this profile when it breaks the build, I'm not much comfortable with this option from my CI hat point of view. It means that every devs would be notified of this breakage if/when automatic builds will be deployed. I can see the mailbombing coming, and devs and contributors ranting on the list. I hear this concern. Thankfully it won't happen often, with two Debian torbrowser-launcher maintainers now committed to keep an eye on this before uploading new versions. Also note that we're already doing #1 for 5 files in /etc/apparmor.d/, by the way (see config/chroot_local-patches/apparmor-*). If #1 is chosen, we could maybe have a dedicated jenkins jobs to test if our Tails specific patches don't apply. ... and make this job a blocker of the automated ISO builds? Seems sensible at first glance. Whenever the patch can't be applied automatically, I guess the torbrowser-launcher/AppArmor people among us will be notified, as opposed to tails-dev@. Still, in this case we'll probably need a way for other tails-dev@ people to be aware that the rest of our ISO CI process is stalled, blocking on the Tor Browser profile patch to be repaired. Any idea how this can be conveyed? Can we have e.g.: * tails-dev@ notified once when the patch job fails, and once when it becomes stable again * torbrowser-launcher/AppArmor folks notified every time the patch job fails (just like tails-dev@ is currently notified every time an automated ISO build fails) ? Maybe we could also make this build time automatic merge being less destructive for the build: if the merge doesn't work, the build goes on but notify that the apparmor profile is out of sync, and that the torbrowser is probably broken. It seems to me that this would open a painful can of worms: we'll then have known-broken, 2nd class autobuilt ISOs, that will break automated tests and can't be used for some use cases we currently have for these ISOs. I'd rather avoid that. Either it builds successfully, or it doesn't. Anything in between is just too complicated (both conceptually and technically) and thus painful to deal with IMO. So I'm not firmly opposed to #1, and I dislike #2, but would prefer #1 to be a bit more gentle. Agreed. 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
intrigeri wrote (25 Jan 2015 08:50:32 GMT) : u wrote (24 Jan 2015 19:54:11 GMT) : Do you want to point me at the Tails-specific patch so I can see what we are talking about? I'll do that once I have implemented it as a patch. In the meantime: https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/apparmor.d/torbrowser?h=feature/5525-sandbox-web-browser Done in the feature/5525-sandbox-web-browser branch: - config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch - config/chroot_local-hooks/19-install-tor-browser-AppArmor-profile 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
On 23/01/15 20:50, intrigeri wrote: Hi, I'm working on #5525 (Sandbox the web browser), and have an AppArmor profile that works locally for most basic use cases. Now, I'm wondering how to integrate it into Tails and I need your input. This profile was derived from the one I've worked a lot on for torbrowser-launcher (https://micahflee.com/torbrowser-launcher/). I think we have two solutions: 1. Download upstream profile and apply Tails-specific patch at ISO build time 2. Ship a forked profile in our Git repository (And no, there's no 3. Upstream our changes given how our different our Tor Browser installation is from standard ones. About 20% of our changes could be made configurable upstream with tunables, but given it's only 20%, I don't think it's worth the added complexity.) #1 has the advantages that we get upstream improvements for free, and we're forced to track upstream, and to adjust our own patch whenever needed: otherwise, Tails ISO build fails. #2 has the advantage that the Tails build won't ever fail due to upstream changes. But our Tor Browser may break at runtime because we failed to integrate upstream changes in their AppArmor profile. From my point of view, #1 feels cleaner: it forces us to do the right thing wrt. upstream, and it fails earlier (at build time). While I appreciate #1 forcing us to track upstream, I think these build failures that depend on things external to Tails (e.g. fetching from APT repos outside of our control) are quite problematic: * They further complicate things for potential Tails contributors and adds the impression that Tails building is a fragile black art (rightfully so, actually!). * I worry that excessive build failure notifications will result in some kind of the boy who cried wolf syndrome for us, or at least that they become a nuisance we tend to ignore or delay, instead of something we appreciate. IMHO we already expose ourselves too much to these kind of externally triggered build issues, and without a 24/7 on call developer that will fix them ASAP, I think we need less of them, not more. Besides, we already require manual intervention for upgrading the Tor Browser, so why not adding upgrade the apparmor profile to those instructions? Of course, we generally upgrade the Tor Browser *very* late in the release process, so if an issue arise it becomes a quite serious blocker, but #1 wouldn't catch all such issues any way, e.g. those introduced by such a new Tor Browser release. Just some food for thought for now. Personally I'm not at all sure which approach is the best. 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
On Fri, Jan 23, 2015 at 08:50:28PM +0100, intrigeri wrote: I'm working on #5525 (Sandbox the web browser), and have an AppArmor profile that works locally for most basic use cases. Now, I'm wondering how to integrate it into Tails and I need your input. I think we have two solutions: 1. Download upstream profile and apply Tails-specific patch at ISO build time 2. Ship a forked profile in our Git repository = I'm in favor of #1. Thoughts, opinions, volunteers? While I think I could help with maintaining this profile when it breaks the build, I'm not much comfortable with this option from my CI hat point of view. It means that every devs would be notified of this breakage if/when automatic builds will be deployed. I can see the mailbombing coming, and devs and contributors ranting on the list. If #1 is chosen, we could maybe have a dedicated jenkins jobs to test if our Tails specific patches don't apply. Also, I'm running myself a Torbrowser contained by an apparmor profile since something like 4 or 5 Torbrowser releases, and it did break for only one of them, so this scenario might not happen so often. Maybe we could also make this build time automatic merge being less destructive for the build: if the merge doesn't work, the build goes on but notify that the apparmor profile is out of sync, and that the torbrowser is probably broken. So I'm not firmly opposed to #1, and I dislike #2, but would prefer #1 to be a bit more gentle. bert. ___ 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
Hi, I'm working on #5525 (Sandbox the web browser), and have an AppArmor profile that works locally for most basic use cases. Now, I'm wondering how to integrate it into Tails and I need your input. This profile was derived from the one I've worked a lot on for torbrowser-launcher (https://micahflee.com/torbrowser-launcher/). I think we have two solutions: 1. Download upstream profile and apply Tails-specific patch at ISO build time 2. Ship a forked profile in our Git repository (And no, there's no 3. Upstream our changes given how our different our Tor Browser installation is from standard ones. About 20% of our changes could be made configurable upstream with tunables, but given it's only 20%, I don't think it's worth the added complexity.) #1 has the advantages that we get upstream improvements for free, and we're forced to track upstream, and to adjust our own patch whenever needed: otherwise, Tails ISO build fails. #2 has the advantage that the Tails build won't ever fail due to upstream changes. But our Tor Browser may break at runtime because we failed to integrate upstream changes in their AppArmor profile. From my point of view, #1 feels cleaner: it forces us to do the right thing wrt. upstream, and it fails earlier (at build time). However, I see how it can be annoying to see the build suddenly start failing, if only few of us feel comfortable updating our profile delta. These disadvantages are slightly mitigated, though: * U. is gaining a lot of AppArmor knowledge these days, and may want to give a hand maintaining our Tails-specific profile patch e.g. when I'm not available to fix the build * at least Alan and bertagaz have some knowledge of AppArmor, and may want to give a hand too * it would be good if more of us learned the basics of AppArmor, anyway :) * U. and I are part of the team that maintains torbrowser-launcher in Debian, so generally, we'll notice when the upstream AppArmor profile changes. In particular, if #1 is implemented by retrieving the upstream profile from the Debian sid source package, we'll notice such changes before they hit the Debian archive and thus impact Tails. = I'm in favor of #1. Thoughts, opinions, volunteers? For now, I'll go with #2 which is trivial to implement) until we have decided whether #1 (which needs a little bit more work) is better. 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.
