Re: [Tails-dev] Faking htpdate user agent worth it?
intrigeri: > Hi, > > adrelanos wrote (30 Sep 2012 22:25:31 GMT) : >> I am wondering about this line in /etc/default/htpdate: >> HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)" > > FTR, this is left from the times when htpdate did run wget in the > clear (without going through Tor). > >> Since you are also using curl and only download the header, does >> faking the Tor Button user agent provide any additional benefit? >> Couldn't the server quite easily distinguish from real Tor Button >> users and tails_htp curl users? > > It may be worse than what you are suggesting. > > If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests, > then we should probably not pretend to be Torbutton. Does it? The more software that pretends to be TorButton - the better, I think. All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Faking htpdate user agent worth it?
Hi, adrelanos wrote (30 Sep 2012 22:25:31 GMT) : > I am wondering about this line in /etc/default/htpdate: > HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)" FTR, this is left from the times when htpdate did run wget in the clear (without going through Tor). > Since you are also using curl and only download the header, does > faking the Tor Button user agent provide any additional benefit? > Couldn't the server quite easily distinguish from real Tor Button > users and tails_htp curl users? It may be worse than what you are suggesting. If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests, then we should probably not pretend to be Torbutton. Does it? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Faking htpdate user agent worth it?
adrelanos: > Jacob Appelbaum: >> I'd be interested in using the same headers for tlsdate - so whatever >> you guys end up using - lets try to make them look similar? > > curl is already a good choice. Supports socks proxy settings, ssl > certificate pinning, strict https, tlsv1, only header... > I have mixed feelings - namely - I think their SOCKS proxy support seems to really not be fantastic. In some testing we did, we found that it leaked DNS basically everywhere unless you used some kind of HTTP proxy. :( > That everyone uses the same is good idea. > I want to behave similarly without promoting a monoculture. > I am just not sure if the "phrasing Tor Button's latest user agent" is > worth the extra effort. I think using a common user agent is a fine idea. I would also want to ensure that all of the headers sent are also documented and that tlsdate sends the same headers. All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Faking htpdate user agent worth it?
Jacob Appelbaum: > I'd be interested in using the same headers for tlsdate - so whatever > you guys end up using - lets try to make them look similar? curl is already a good choice. Supports socks proxy settings, ssl certificate pinning, strict https, tlsv1, only header... That everyone uses the same is good idea. I am just not sure if the "phrasing Tor Button's latest user agent" is worth the extra effort. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Faking htpdate user agent worth it?
adrelanos: > Hello, > > I am wondering about this line in /etc/default/htpdate: > HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)" > > Since you are also using curl and only download the header, does faking > the Tor Button user agent provide any additional benefit? Couldn't the > server quite easily distinguish from real Tor Button users and tails_htp > curl users? > > Even if you were not telling curl to only download the header. If you > were still downloading the whole site. Would that actually add any > additional benefit? > > Haven't found this in the design. Please explain. > I'd be interested in using the same headers for tlsdate - so whatever you guys end up using - lets try to make them look similar? All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
Hi, adrelanos wrote (30 Sep 2012 22:14:29 GMT) : > I reviewed those commits as well, since I am already using them in > Whonix. :) Works very well. Nice to read :) > Could you put please the following to from /etc/init.d/htpdate > [...] > as variables into /etc/default/htpdate? I agree the result would be a bit nicer, and I guess we would happily apply a well tested patch that implements this suggestion, but I don't think I'll personally spend time on this any time soon, sorry. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Faking htpdate user agent worth it?
Hello, I am wondering about this line in /etc/default/htpdate: HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)" Since you are also using curl and only download the header, does faking the Tor Button user agent provide any additional benefit? Couldn't the server quite easily distinguish from real Tor Button users and tails_htp curl users? Even if you were not telling curl to only download the header. If you were still downloading the whole site. Would that actually add any additional benefit? Haven't found this in the design. Please explain. Cheers, adrelanos ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
Hi, I reviewed those commits as well, since I am already using them in Whonix. :) Works very well. Could you put please the following to from /etc/init.d/htpdate --allowed_per_pool_failure_ratio 0.34 \ --proxy"socks5h://192.168.0.10:9108/" as variables into /etc/default/htpdate? Cheers, adrelanos ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review and merge bugfix/iceweasel_file_associations
Hi, Quoting the closest-related ticket (https://tails.boum.org/todo/open_mp3_with_totem_instead_of_audacity/): This bug, as well as others of the same kind (e.g. the "PDF open with Gimp" one, that is now unreproducible by pure luck, and could come back any time soon if we don't really fix that issue at its roots), happens with the instance of iceweasel started from the NetworkManager hook, but not with another iceweasel started by hand after closing the former. This is explained by our NetworkManager hook not setting the XDG_DATA_DIRS environment variable to the GNOME -specific value that gnome-session does. Details are explained in comment n°26 on Debian bug #522998. The bugfix/iceweasel_file_associations branch fixes that, candidate for Tails 0.14. Changes from stable to that branch: dccc7fa Start iceweasel from NM with the same XDG_DATA_DIRS settings as the GNOME session Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [patch, please review] generate Iceweasel profile at build time
On Sun, Sep 30, 2012 at 07:28:04PM +0100, Alessandro Grassi wrote: > > [...] If the symlink points to a non-existent file, then Firefox will > > happily create it [...] > Correct, I tried it too. This is ok for when no places.sqlite exists. > If it exists, user may have some saved bookmarks already, and we should > preserve them. Other bits of configuration are not saved until a new session is started in which the persistence volume is activated. So there is no need to worry about this: the first time a newly created persistence volume is activated, it will get the default set of bookmarks. Changes will be kept from then on. -- Ague pgpoa3bNHIFEM.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] tails-persistence-setup releases vs. Tails 0.14
Hi, please, anyone who did the 0.18 release of tails-persistence-setup, push your pristine-tar branch. Other than that, a 0.18 release was made from the usual branches in there, with stuff that is not be ready yet for merging into devel. One drawback is that it has apparently blocked an improved t-p-s (with bigger timeout) from entering Tails 0.13. I'd like to avoid this happening again. I think we now have two possibilities: A. the NM presets persistence is finished and merged in time => t-p-s 0.18 or greater is shipped into Tails 0.14, with a (possibly much) bigger timeout. Great. B. the NM presets persistence is not finished and merged in time => I'd rather not fork a branch off t-p-s 0.17 and prepare 0.17.1 from there (overkill), so I think we should go for a chroot_local-patches. So, I think I'll wait a few days (say, until next Thursday), and go with #B if #A has not happened yet. Thoughts, better ideas? Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [patch, please review] generate Iceweasel profile at build time
> Great! The hook looks fine. Minor cosmetic remark:[...] Fixed and new patch attached > I am not sure I understand. Do you already have code for that? No, I made tests on the running system > [...] If the symlink points to a non-existent file, then Firefox will happily create it [...] Correct, I tried it too. This is ok for when no places.sqlite exists. If it exists, user may have some saved bookmarks already, and we should preserve them. Alessandro From c8394e520dd15fdbf80bd1e2651a464499a4a010 Mon Sep 17 00:00:00 2001 From: Alessandro Grassi Date: Sun, 30 Sep 2012 20:09:08 +0200 Subject: [PATCH] generate iceweasel profile at build time --- config/chroot_local-hooks/14-generate-iceweasel-profile | 11 +++ 1 file changed, 11 insertions(+) create mode 100755 config/chroot_local-hooks/14-generate-iceweasel-profile diff --git a/config/chroot_local-hooks/14-generate-iceweasel-profile b/config/chroot_local-hooks/14-generate-iceweasel-profile new file mode 100755 index 000..d910076 --- /dev/null +++ b/config/chroot_local-hooks/14-generate-iceweasel-profile @@ -0,0 +1,11 @@ +#!/bin/sh + +#generate iceweasel profile at build time, so that it has a fixed name + +set -e +apt-get --yes install xvfb +xvfb-run iceweasel -CreateProfile default +mv ~/.mozilla/firefox/*.default ~/.mozilla/firefox/default +sed -i "s@Path=.*\.default@Path=default@" ~/.mozilla/firefox/profiles.ini +mv ~/.mozilla /etc/skel +apt-get --yes purge xvfb -- 1.7.10.4 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [patch, please review] generate Iceweasel profile at build time
On Sun, Sep 30, 2012 at 04:18:07PM +0100, Alessandro Grassi wrote: > > People usually use Xvfb when they need a 'fake' X server. See the 'xvfb' > > package in Debian, and the `xvfb-run` script it contains. > > xvfb works fine, new patch is attached ;-) Great! The hook looks fine. Minor cosmetic remark: I'd rather have the profile named 'default' than 'amnesia'. The 'amnesia' name is a leftover from the very first versions of what became Tails. Maybe someday we'll want to get rid of those. > Now the real thing: make bookmarks persistent. I got it working using > dotfiles and putting places.sqlite in the right subfolder, so I can make a > preset in tails-persistence-setup which links "bookmarks/places.sqlite" to > "/home/amnesia/.mozilla/firefox/profiles/amnesia/places.sqlite" (I looked > at the code). > > The only missing thing is the first-time behaviour: the existing > places.sqlite (or, if missing, a default one) must be moved to the > persistent storage and linked to the profile folder, and Iceweasel should > not be open while this happens. > > Is there a way for tails-persistence-setup to execute a script on preset > activation? I am not sure I understand. Do you already have code for that? Some tests have shown that you can have `places.sqlite` be a symlink to a file in another directory, e.g. `~/.mozilla/tails-bookmarks`. If the symlink points to a non-existent file, then Firefox will happily create it from the defaults when it starts. So I suspect that making this directory persistent would do the trick. -- Ague pgpVaRcdUOqj7.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [patch, please review] generate Iceweasel profile at build time
> > People usually use Xvfb when they need a 'fake' X server. See the 'xvfb' > package in Debian, and the `xvfb-run` script it contains. > xvfb works fine, new patch is attached ;-) Now the real thing: make bookmarks persistent. I got it working using dotfiles and putting places.sqlite in the right subfolder, so I can make a preset in tails-persistence-setup which links "bookmarks/places.sqlite" to "/home/amnesia/.mozilla/firefox/profiles/amnesia/places.sqlite" (I looked at the code). The only missing thing is the first-time behaviour: the existing places.sqlite (or, if missing, a default one) must be moved to the persistent storage and linked to the profile folder, and Iceweasel should not be open while this happens. Is there a way for tails-persistence-setup to execute a script on preset activation? Alessandro From faf5d5d142c6d3a7928a106ec53dfb2660a8c2d6 Mon Sep 17 00:00:00 2001 From: Alessandro Grassi Date: Sun, 30 Sep 2012 15:43:03 +0200 Subject: [PATCH] generate iceweasel profile at build time --- config/chroot_local-hooks/14-generate-iceweasel-profile | 11 +++ 1 file changed, 11 insertions(+) create mode 100755 config/chroot_local-hooks/14-generate-iceweasel-profile diff --git a/config/chroot_local-hooks/14-generate-iceweasel-profile b/config/chroot_local-hooks/14-generate-iceweasel-profile new file mode 100755 index 000..be2054f --- /dev/null +++ b/config/chroot_local-hooks/14-generate-iceweasel-profile @@ -0,0 +1,11 @@ +#!/bin/sh + +#generate iceweasel profile at build time, so that it has a fixed name + +set -e +apt-get --yes install xvfb +xvfb-run iceweasel -CreateProfile default +mv ~/.mozilla/firefox/*.default ~/.mozilla/firefox/amnesia +sed -i "s@Path=.*\.default@Path=amnesia@" ~/.mozilla/firefox/profiles.ini +mv ~/.mozilla /etc/skel +apt-get --yes purge xvfb -- 1.7.10.4 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/assymetric_gpgApplet [sic!]
intrigeri wrote (29 Sep 2012 18:38:23 GMT) : > How about creating a ticket page for it? There is already one, actually: https://tails.boum.org/todo/gpgapplet:_public_key_support/ ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
Hi, berta...@ptitcanardnoir.org wrote (30 Sep 2012 13:46:57 GMT) : > Done the tests, works as expected, merged (with --no-ff this time) > in devel, and pushed. Thanks :) > I haven't updated the ticket, there was no qa tag in there, There was one, so I removed it and updated the ticket a bit. Next thing to do is to split the remaining parts out of the ticket. I'll take care of it. Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
On Thu, Sep 27, 2012 at 11:24:04AM +0200, intrigeri wrote: > Hi, > > Ague Mill wrote (26 Sep 2012 12:08:08 GMT) : > > htpdate lists a "--proxy" option. I may assume that when I don't > > specify this option, it will not use a proxy at all. But, the > > current code will still use a proxy if HTTPS_PROXY or ALL_PROXY are > > set. I think this is confusing. > > Fair enough, nice catch. > Here's what I did, then: > > -[ 'proxy|p:s', "what to pass to curl's --socks5-hostname" ], > +[ 'proxy|p:s', "what to pass to curl's --socks5-hostname (if unset, > environment variables may affect curl's behavior -- see curl(1) for details)" > ], > > >> > Uh... and actually, those changes might require to add some more > >> > tests to the checklist. What do you think? > >> > >> I'll think of it later today or tomorrow. > > Done (19b552f) -- yeah, that's the bare minimum. I'm not sure if, and > how, we would want to deeper dive into checking that Tor itself works > as advertised. > > If the current state of this branch looks good enough, I suggest you > build an ISO from devel + feature/separate_Tor_streams, and "run" > these tests before merging. Done the tests, works as expected, merged (with --no-ff this time) in devel, and pushed. I haven't updated the ticket, there was no qa tag in there, and I was not really sure about the chenges that have to be done. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/japanese_input
On Sat, Sep 29, 2012 at 08:54:22PM +0200, intrigeri wrote: > this branch adds a Japanese input system (scim-anthy) that was asked > on the forum. I've asked for tests, and was asked for an ISO. > So I suppose we should add this package, and call for > Japanese -speaking testers at RC1 or RC2 time. > > Candidate for 0.14, has been living in experimental for ~2 weeks. Merged in devel. -- Ague pgpTpyCuQqn3S.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Sound in the Unsafe Browser
Hi, this was pushed to devel: f6dba62 Enable sound in the Unsafe Browser. I beg to disagree. My belief is that us actively making the Unsafe Browser work for more uses than what we want it to be used (in a manner supported by us) sends a contradictory message to our users, and weakens the warnings we display about that in the Unsafe Browser dialog message and documentation. However, I eventually understood why this change was made. According to a comment in the forum [1] (not the best place to document it, if you ask me), the reason was to better support visual impaired users, in preparation for the day when todo/accessibility is seriously tackled: > I think a valid use case for sound in the Unsafe Browser is to make > it usable for people with sight impairments. I'm unsure whether > Tails includes any text-to-speech software that actually makes Tails > usable with such impairments, but even if it doesn't the support > should be there for the day such software is added. > Hence commit f6dba62. [1] https://tails.boum.org/forum/Enabling_audio_with_unsafe_web_browser__63__/#comment-3a41109b0c2d96eca0509799bb15d67c Tails has been shipping a screen reader (GNOME Orca) since 0.8, so the necessity and usefulness of this change can actually be tested. Orca works quite well with most applications shipped in Tails, but a quick test shows that it does not work out of the box, as of Tails 0.13, for iceweasel (be it the regular one, or the Unsafe Browser), and I did not quickly manage to fix this. Once we fix this, I'm not sure if we can, and want, the Unsafe Browser's session to start and use a separate instance of Orca, that would bring the need for the clearnet user to be part of the audio group; I've no idea how ATK and AT-SPI work; maybe the existing instance of Orca would access the Unsafe Browser UI? I'd like us to know the answer to this question, before doing changes that might, some day, fix something, or be useless forever. So, either the potential usefulness of this change is displayed a bit more clearly soon, or I'd rather see us revert it. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
