Author: intrigeri Date: To: The Tails public development discussion list Subject: 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.
