Re: [Tails-dev] AdBlock Plus in Tails' Tor Browser
Hi, This answer might pop up late now that #8665 is in Ready for QA state, still it might bring new questions. Sorry for that. On Fri, Jan 23, 2015 at 12:49:10AM +0100, intrigeri wrote: > mercedes508 wrote (22 Jan 2015 17:54:53 GMT) : > > And I'm wondering how important the fingerrint issue is, considering > > how easy it is to change it (e.g. by enlarging the browser window), > > I'm more concerned about behavioral differences (compared to the Tor > Browser) that we ship by default (XXX: we haven't summed up what they > were recently, by the way), than about bits of fingerprinting > information that every Tor Browser user, be it upstream or within > Tails, can individually choose to leak. > > I'm tempted to propose that on this topic, just like for resizing the > browser: > > * we provide safer defaults; > * we let users manually opt-in if they want to block ads and diverge >from the Tor Browser anonymity set. > (Of course the current behaviour for resizing the window is not a good > implementation of opting-in to diverge, as the security consequences > of this action are completely non-obvious to the user. There are > tickets in the right place about asking for a confirmation in this > case, I think.) > > [And I'm starting to wonder if this wouldn't be better to put that > in the upcoming Tor Browser's "security slider". At first glance: Then if we go for safer defaults, I agree Ad Block+ would be more close to NoScript in term in UX and fingerprinting. We could integrate Ad Block+ the same way: installed but disabled by default. That sure would be something to discuss further with the TorBrowser people. We could help them to upstream our Ad Block+ rules update process. Shall we engage a discussion about this? That's https://trac.torproject.org/projects/tor/ticket/9387 > "block ads, not JS" < "block neither ads nor JS" < "block JS, not ads" > (default) > > but once you block JS, your fingerprint is so much different anyway > that blocking ads on top don't make a big difference, so possibly this > would be better, although awkward and then perhaps confusing for > users: > > "block ads, not JS" < "block neither ads nor JS" < "block JS and ads" > > Food for thought.] I'm not even sure we need to decouple both, but why not. It might be hard to fit in the TorLauncher slider though if we want to push this forward. 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] [review'n'merge:1.3] feature/8726-use-homogenous-Debian-mirrors-at-build-time [
On 26/01/15 20:04, intrigeri wrote: > anonym wrote (26 Jan 2015 13:56:44 GMT) : >> Merged! > > I think you forgot to push stable, experimental and feature/jessie > after merging into these branches as requested. Sorry, I completely forgot about stable and feature/jessie, and hadn't pushed my experimental. Now done! > Once this is done, please reassign the ticket to bertagaz so that he > can take care of the follow-ups on Puppet side. 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] [review'n'merge:1.3] feature/8726-use-homogenous-Debian-mirrors-at-build-time [
Hi, anonym wrote (26 Jan 2015 13:56:44 GMT) : > I thought it best I took it, since it modifies some Vagrant stuff, which > I seem to be the maintainer of. Indeed, I had to push two small fixes > (commits 535abed and a7d4c9c) to repair the provisioning script. Thanks! > Merged! I think you forgot to push stable, experimental and feature/jessie after merging into these branches as requested. Once this is done, please reassign the ticket to bertagaz so that he can take care of the follow-ups on Puppet side. 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] [review'n'merge: 1.3] feature/8725-remove-vagrant-bootstrap-cache
anonym wrote (26 Jan 2015 12:32:55 GMT) : > So a `lb clean --all` will remove the built wiki etc. The Vagrant build > script is actually quite clever in that it *will* reuse any "cached" > wiki, which can save a couple minutes of build time. I personally find > this quite useful. Good to know, thanks! 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] [review'n'merge:1.3] bugfix/8257-more-robust-tor_bootstrap_progress
On 27/11/14 22:35, intrigeri wrote: > hi, > > I've noticed that bug thanks to the Journal capturing such error > output on Tails/Jessie, but it affects Wheezy too. We're using the > affected function in tor-has-bootstrapped, that some users can run > with passwordless sudo, so better make it more robust to be on the > slightly safer side. > > Please review'n'merge into devel for 1.3, unless you feel comfortable > to take it into 1.2.1 (if I were the RM, I wouldn't, since AFAICT it's > mostly cosmetic, and without any practical implication unless we use > the affected function in a "set -e" script -- not checked if we did). > > It passes the time sync', torified browsing and Windows camouflage > features of our automated test suite. Not tried to run the rest. These tests passes for me too with this branch. Merged! 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] [review'n'merge:1.3] bugfix/8699-only-create-timestamps-in-Jenkins
On 19/01/15 14:16, intrigeri wrote:
> Hi,
>
> since the .{src,bin}pkgs stuff was merged, our build system is leaving
> .{start,end}.timestamp files around, which are useless in most cases.
> anonym has complained about it, so here's a branch that only generates
> these files when building from Jenkins.
Thanks, this is now merged!
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] [review'n'merge:1.3] feature/8726-use-homogenous-Debian-mirrors-at-build-time [Was: RFC: Use homogenous Debian mirrors at build time (#8726)]
On 26/01/15 12:31, intrigeri wrote: > Hi, > > please review'n'merge: > > 1. feature/8726-use-homogenous-Debian-mirrors-at-build-time (main Git > repo) into all branches we build automatically, namely stable, > devel, experimental and feature/jessie => that's for the RM, > unless he explicitly asks for help reviewing the pile of stuff > that's waiting for QA (hint, hint). I thought it best I took it, since it modifies some Vagrant stuff, which I seem to be the maintainer of. Indeed, I had to push two small fixes (commits 535abed and a7d4c9c) to repair the provisioning script. The resulting Vagrant build's buildlog looks good AFAICT: $ grep -wo "\S*\.debian\S*" $BUILDLOG | sort -u http://ftp.us.debian.org http://ftp.us.debian.org/debian/ http://ftp.us.debian.org/debian... http://security.debian.org http://security.debian.org/ syslinux_6.03~pre20+dfsg-2~bpo70+1.debian.tar.xz Merged! 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] Automated builds specification
Hi, On Mon, Jan 19, 2015 at 08:14:55PM +0100, bertagaz wrote: > > On Sun, Jan 18, 2015 at 08:07:46PM +, sajolida wrote: > > bertagaz: > > > 0. We might also want a mechanism for devs to pro-actively state they > > > want to > > > keep their branches being build even if the last commit was older than the > > > last release. IIRC > > > > If I understand correctly, adding a dummy commit would bring back my > > branch in the set of branches that are automatically built. So maybe we > > don't need a dedicated mechanism handle those rare cases. > > That's the idea, having a timestamp file that would be use for this dummy > commit. But it comes for free, sure. :) I had Alan having a look at the blueprint too, she fixed some issues in the scenario and added one for the future. The blueprint has been updated with some proposalsi for each question. If you want to consider them, or propose another one, please have a look. 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] [review'n'merge: 1.3] feature/8725-remove-vagrant-bootstrap-cache
On 23/01/15 12:16, intrigeri wrote:
> hi,
>
> anonym wrote (23 Jan 2015 10:34:47 GMT) :
>> This kills the bootstrap stage caching feature in our Vagrant setup,
>> which is considered harmful. Please review and merge into devel!
>
> The code looks good to me. Who in here still has a working
> Vagrant-based build setup to confirm it works fine?
For people not following the Redmine ticket, KillYourTV successfully
tested my branch and it has now been merged.
> Also, while we're at it, why not get rid of the `cleanall' build
> option as well, and make it the default and forced behavior?
> What exactly is it useful for to *not* run `lb clean --all'
> every time?
In `auto/clean` we have:
# static wiki
rm -rf config/chroot_local-includes/usr/share/doc/tails/website
wiki/src/.ikiwiki
find wiki/src -name *.pot -exec rm {} \;
So a `lb clean --all` will remove the built wiki etc. The Vagrant build
script is actually quite clever in that it *will* reuse any "cached"
wiki, which can save a couple minutes of build time. I personally find
this quite useful.
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 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
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] Hybrid ISOs: need to reconsider the plan (#8510)
Hi,
Alan wrote (18 Jan 2015 13:40:37 GMT) :
>> I prefer option C: [...]
>>
>> Thoughts?
A week later, I've removed the indication that #8510 is blocked by
#8524.
> I'm fine with option C especially if as much people as possible try
> booting isohybrid DVDs on various computers.
Agreed. Created #8797 ("Send a call for testing hybrid ISO images
burnt on DVD") to this end.
> I'll do that within the week to all computers I have access to.
Any regression detected?
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.3] feature/8726-use-homogenous-Debian-mirrors-at-build-time [Was: RFC: Use homogenous Debian mirrors at build time (#8726)]
Hi,
please review'n'merge:
1. feature/8726-use-homogenous-Debian-mirrors-at-build-time (main Git
repo) into all branches we build automatically, namely stable,
devel, experimental and feature/jessie => that's for the RM,
unless he explicitly asks for help reviewing the pile of stuff
that's waiting for QA (hint, hint).
2. feature/8726-use-homogenous-Debian-mirrors-at-build-time ("tails"
Puppet module) into this module's master branch, and deploy on
lizard *once #1 has been done* => that's for bertagaz
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] RFC: Use homogenous Debian mirrors at build time (#8726)
Hi, intrigeri wrote (19 Jan 2015 12:31:29 GMT) : > So, I want to: > 1. hard-code in auto/config all mirrors that shall be used at build time > 2. update vagrant/provision/setup-tails-builder so that it doesn't >configure LB_*MIRROR*, and deconfigures them if present > 3. update wiki/src/contribute/build.mdwn so that it doesn't advise to >set $LB*MIRROR* > 4. update tails::builder so that it doesn't configure LB_*MIRROR*, and >deconfigures them if present > (Steps 1-3 are implemented already in > feature/8726-use-homogenous-Debian-mirrors-at-build-time.) This proposal didn't raise any opposition, so I'm going to implement step 4 as a branch against our "tails" Puppet module, and then ask for a review'n'merge of the whole thing. 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
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.
