Re: [Tails-dev] Pip is not torified by default
>It never was installed in any Tails release. My bad I thought it was in 5.20 but upon further investigation it was indeed not included like you said. >and none of them are into Python development. Thats fair and makes sense. Could python3-pip be included or would it cause issues with build or other dependencies or security? >Our focus are on the needs of our personas [2] >[2] https://tails.net/contribute/personas/ > Cris > > The Information Gatherer There are many open-source intelligence (OSINT) tools that you can install with pip. > Derya > > The Privacy Advocate There also may be different privacy tools that you can install with pip that are not in apt or included with tails. A guide could be added to advanced topics for these use cases https://tails.net/doc/advanced_topics/python_packages * Example: Start Tails with an administration password Open root terminal under Applications -> System Tools -> Root Terminal Update and install pip apt update apt install python3-pip -y Create pip.conf file to use tor mkdir -p ~/.config/pip/ echo '[global] proxy = socks5h:127.0.0.1:9050' >> ~/.config/pip/pip.conf Copy pip.conf to dotfiles mkdir -p /live/persistence/TailsData_unlocked/dotfiles/.config/pip cp /home/amnesia/.config/pip/pip.conf /live/persistence/TailsData_unlocked/dotfiles/.config/pip/ Add python packages folders to persistence.conf for persistence echo '/home/amnesia/.local/libsource=python-packages' \ >> /live/persistence/TailsData_unlocked/persistence.conf echo '/home/amnesia/.local/binsource=local/bin' \ >> /live/persistence/TailsData_unlocked/persistence.conf echo '/home/amnesia/.cache/pipsource=pip-cache' \ >> /live/persistence/TailsData_unlocked/persistence.conf Reboot tails and install the pip packages you want :) On 2/1/24 19:01, tails-dev-requ...@boum.org wrote: Re: Pip is not torified by default ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Pip is not torified by default
>You could get some stream isolation by adding a "username" with a value not used by other apps. >The file /usr/local/bin/curl shows how to create a random one each time. >That'd be hard to do in a pip.conf file, but even a "username" created once would create a different stream compared to other applications on Tails, and that would provide *some* isolation. Update: python3-pip is not included in latest Tails release I was doing some more testing and noticed that its not included anymore as of the latest release. Not exactly sure what in the building process removed it. When typing `pip`, `pip install ` returns bash not found and `which pip` returns nothing. `apt list --installed |grep python3-pip` returns nothing. Python3-pip should be added back next release and with a global config to torify it by default. There are many nice python tools not included with tails that users may like to install. Also pip seems like a easy way to test different python tools for use and possible integration onto tails. A persistent storage feature for user installed python packages could also be designed to be a hook that adds the appropriate corresponding .local folders to the persistence.conf upon activation of the feature. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Pip is not torified by default
Pip requires torsocks to even work when it comes installing things through pip. Despite other binaries being set to use torsocks --isolate or set in their own config, pip is not set to use tor by default in tails. New users might not know that torsocks is required to launch many applications so they may get confused. pip install hangs up (errors out) due to it unable to reach and even fetch things from pypi.org. Setting a global config for pip to use tor as a proxy would fix this and force pip to use tor. Creating a config file for pip to use globally: /etc/pip.conf or /etc/xdg/pip/pip.conf with this line: [global] proxy = socks5h:127.0.0.1:9050 The only issue I can see with this is no stream isolation for pip. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] onion-grater fix Tor control auth cookie authentication even if HashedControlPassword is set
Hi! https://github.com/Whonix/onion-grater/commit/70e735dae1c15920c356b07fc6aaf4b9589b465a Please review and merge. The more I think about it, perhaps we could abolish DEFAULT_COOKIE_PATH = '/run/tor/control.authcookie' altogether? PROTOCOLINFO tells controllers (like stem) where the cookie file is located. It doesn't rely on a default path. For an example of what this looks like on the wire please see... https://stem.torproject.org/faq.html#i-m-using-cookie-authentication Then we might be able to simply this and just use authenticate(). Cheers, Patrick ___ 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] Shortcut to Start Orca
Hi Intrigeri, Le 06/07/2017 à 10:26, intrigeri a écrit : > I've just tried and it worked for me: 5-10 seconds after pressing this > keyboard shortcut, I hear "screen reader on". So I wonder what's > happening on your side. It might be a problem with the sound card > drivers, or with the mixer volume, or the known bug that sometimes > prevents GNOME Shell from starting in the Greeter. > The sound card issue made me looking in PulseAudio side. In fact PulseAudio made me some jock in the host machine only for virtualbox which was mutted... Sorry for this false alarm, still new to Linux... And different volume for each application is still a new concept for me :) > Note that even once Orca will have started, a few remaining issues > could be either painful or blocking: > > * Greeter accessibility settings are not forwarded to the GNOME >session (https://labs.riseup.net/code/issues/12384) so one has to >enable Orca again once logged in. > Fortunately, Alt+Super+S works well so we can use Orca without too much difficulties in this case. > * Not everything is read by Orca in the Greeter, due to widgets not >being tagged properly (https://labs.riseup.net/code/issues/11664). > With all these informations I'll be able to test more thoroughly. Cheers, Patrick ___ 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] Shortcut to Start Orca
Hi, After a long time away from Tails, I would like to set up a virtual machine with tails to make some tests to contribute more. In the documentation, I read it is now possible to start Orca with Alt+Super+S. Unfortunately, it doesn't seem to work in greater. I though it worked... When this shortcut works? Do I make a mistake with the "super" key? Is not it the Windows key? Thanks, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix? - \n -> \r\n fix
Hi, could you please add this trivial fix? https://github.com/Whonix/control-port-filter-python/commit/30c1de54f9feaa26464842241e217be6edf3b464 (fixes txtorcon compatibility) Cheers, Patrick [1] https://github.com/meejah/txtorcon/issues/215#issuecomment-290277209 ___ 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] onion-grater sd-notify support
Hi! Please reviewer and merge into onion-grater. https://github.com/adrelanos/onion-grater-remote.git branch: sd-notify https://github.com/adrelanos/onion-grater-remote/tree/sd-notify Cheers, Patrick ___ 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] [tor-dev] GSOC 2017: Proposal for anon-connection-wizard
anonym: > irykoon: >> Currently, the Tor Launcher is shipped with the Tor Browser Bundle >> and heavily relies on the Tor Browser for its implementation. These >> facts cause using Tor Launcher without having the Tor Browser >> impossible. I agree with the whonix core developer Patrick >> Schleizer that "the Tor Browser Bundle has its kind of users. >> system Tor (refers to Tor from packages.debian.org or >> deb.torproject.org) users, where Tor runs as daemon, is used in >> different ways for different purposes. These users cannot use Tor >> Launcher, because it only works with Tor Browser". > > I might be misunderstanding what you and Patrick mean with > "impossible" (or rather, which use cases are impossible) w.r.t. using > Tor Launcher outside of the Tor Browser; Tails uses the Tor Launcher > shipped in Tor Browser, but it's run as a stand-alone XUL application > (`firefox --app ...`), so the *web* browser isn't started as part of > it. [1] One could even run it using Iceweasel/Firefox, i.e. > completely without Tor Browser. Right. I might have used the word "impossible" as a short cut to say the following: tor-launcher will never be a great solution for system Tor users on Debian. Since Tor Browser is not packaged as in Debian unfortunately as it looks like will not be anytime soon, getting tor-launcher working nicely as a package available from packages.debian.org is very hard and unrealistic. A python rewrite (anon anon-connection-wizard) seems the way to go. > That said, this approach will not be viable any more some time next > year when the Firefox ESR branch drops XUL support and Tor Launcher > is deprecated upstream. It remains to see how the replacement of Tor > Launcher will look, it might still work for Tails. However, if > anon-connection-wizard would be a (more or less) drop-in replacement > for Tor Launcher in Tails, that would be immensely helpful since we'd > have a solution that will be guaranteed to work for us without much > work. And I guess as long as the UX is more or less identical to the > new Tor Launcher and rapidly adapts to changes, and there are good > translations, we'd probably prefer it over the new Tor Launcher, > since it probably will be even harder to decouple from the web > browser. That's great to know! Let's hope tor-launcher will work great everywhere, Debian, Whonix, Tails and whoever else may be interested in using it. > Any way, I also see potential for future collaboration between Whonix > and Tails for extending the usefulness of anon-connection-wizard > beyond what Tor Launcher (and its replacement) offers [2]; > anon-connection-wizard targets the OS, not just a single application, > so it could integrate the choices of network configuration (wired? > which wireless network? MAC spoofing?) and Tor configuration (proxy? > pluggable transport?) in a single place which probably makes more > sense for users and also allows us to more easily (optionally) save > these settings so they are restored the next time you visit the same > network. This could potentially even be used to help giving users > control over entry node selection to avoid persistent Entry Guards > from leaking information about you geographical movement. [3] Tor proxy configuration yes. Tor pluggable configuration, by all means yes, that will is the core feature of anon-connection-wizard. Other Tor settings, perhaps. Depends on the settings. We'd need to discuss them. My current impression of iry is that anon-connection-wizard development will go on after this gsoc. anonym, did you have in mind combining anon-connection-wizard with the revamped Tails greeter? (Some links, you might have better ones. [1] [2]) Perhaps that could be done by leaving some "holes" in anon-connection-wizard? I mean, perhaps it's gui wizard pages could allow having additional pages before and after the actual Tor connection wizard pages? That way you could flexibly integrate it in Tails somehow? (Definition of "page" in anon-connection-wizard context: This is a page [1]. This is another page [2].) Let's leave all of that post gsoc future work. I am concerned to overextend this the anon-connection-wizard project. A tor-launcher python clone ending up in packages.debian.org would be an awesome improvement, even if it does not solve all issues such as mac changing. For mac changing a lot more work would be required. For start, a working cli implementation (covering all that Tails does) that get be installed on a regular Debian system from packages.debian.org.) Then perhaps anon-connection-wizard could morph into a bigger project and provide a gui for that as well. At the moment the anon-connection-wizard gsoc proposal is well defined in scope. A Tor connection
Re: [Tails-dev] [Whonix-devel] Tails control port filter proxy in Whonix?
Happy to report, that tor-controlport-filter learned sd_notify, now got support for systemd's watchdog feature. Using python3-sdnotify from packages.debian.org. To be found in git master. Git commits, test results can be found here. https://phabricator.whonix.org/T274#12423 https://github.com/Whonix/control-port-filter-python Cheers, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
anonym: > Patrick Schleizer: >> Patch by Joy. Otherwise it does not work for us. Do you think you could >> merge this patch? > > No; the "match-"-prefix was intentionally dropped, so please `s/match-//g` in > all your scripts and filter files. > > Cheers! Awesome, this is done in git master. Best regards, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
Patch by Joy. Otherwise it does not work for us. Do you think you could merge this patch? https://github.com/joysn/control-port-filter-python/commit/6f488c14980e8b5c58a42374649c4d5725c8296e#diff-7414879ce81f5586d790820540d0ca05 Best regards, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
>> One minor bug, I think, first line is supposed to be >> >> #!/usr/bin/python3 -u (not -v) > > That error was not present in the code I looked at. Strange. Probably by the time you looked at it, Joy already fixed it. Anyhow. It's looking alright now. >> Please take: >> >> - #!/usr/bin/python3 -u (makes eventual python exceptions and up in >> journal) - Use yml.safe_load and Python exceptions in journalctl - >> add --listen_interface option > > These were the commits I imported. > Great! anonym: > Patrick Schleizer: >> Hello anonym! >> >> anonym: >>> Feel free to send a PR with your other changes applied to >>> tor-controlport-filter in Tails Git! Otherwise I'll do it myself >>> later this week. >> >> Joy rebased Whonix's changes on top of your new version. >> >> base: >> https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/usr/local/lib/tor-controlport-filter >> >> >> fork: >> https://github.com/joysn/control-port-filter-python/blob/master/usr/lib/tor-controlport-filter >> >> >> The diff looks simple, I guess. > > If you see my email from earlier today, I already did this: > https://mailman.boum.org/pipermail/tails-dev/2017-January/011190.html > > >> Please ignore: >> >> - config parser changes > > I did! > > However, in your repo I still see that commit bed6399b contains the > merge_yml() code. You are gonna do that externally, right? However, > the commit talks about "add /etc/tor-controlport-filter.d > configuration support", so perhaps it was a mistake (i.e. you wanted > to add a `--filter-dir` option, but picked the wrong commit)? > Created https://phabricator.whonix.org/T617 for it. What's next? What else? :) Can we implement /usr/lib/tor-controlport-filter-merger directly in https://github.com/Whonix/control-port-filter-python or would you prefer if we implement that elsewhere? Should we implement the systemd override to actually use it in Whonix elsewhere? If done right, if we move the Whonix config into another Whonix package, it would not interfere with Tails. I'll take https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/tor-controlport-filter.d?h=feature/12173-end-whonix-controlport-filter-fork and add to https://github.com/Whonix/control-port-filter-python ? Then you should be able to build and install that package on Tails if you wish. (lintian --pedantic warning free as well as most likely reproducible on stretch.) Cheers, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
Hello anonym! anonym: > Feel free to send a PR with your other > changes applied to tor-controlport-filter in Tails Git! > Otherwise > I'll do it myself later this week. Joy rebased Whonix's changes on top of your new version. base: https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/usr/local/lib/tor-controlport-filter fork: https://github.com/joysn/control-port-filter-python/blob/master/usr/lib/tor-controlport-filter The diff looks simple, I guess. Please ignore: - config parser changes Please take: - #!/usr/bin/python3 -u (makes eventual python exceptions and up in journal) - Use yml.safe_load and Python exceptions in journalctl - add --listen_interface option One minor bug, I think, first line is supposed to be #!/usr/bin/python3 -u (not -v) Best regards, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
>> Noticed one incompatibility.>> >> https://github.com/HelloZeroNet/ZeroNet/issues/756 >> >> https://github.com/Whonix/control-port-filter-python/blob/master/usr/share/tor-controlport-filter/examples/40_zeronet.yml anonym sorted that out by fixing a bug in ZeroNet. https://github.com/HelloZeroNet/ZeroNet/issues/756#issuecomment-274029807 Thanks, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
anonym: > Patrick Schleizer: >> [override] will probably work for Whonix. Joy and me drafted a >> plan. >> >> In one sentence: We at Whonix invent a new a separate config >> folder, parse it with a yml merger python script, and generate >> another yml file that gets passed to tor-controlport-filter by >> Tails. > > Ok. My understanding of this proposal is that you no longer need any > sort of "filter rules merging" in tor-controlport-filter itself, > correct? If so, great! :) I guess so, right. Unless any of the Tails profiles use '*'? But in that case we might be able to just config-package-dev displace the profile. > Feel free to send a PR with your other > changes applied to tor-controlport-filter in Tails Git! > Otherwise > I'll do it myself later this week. Let's see who is faster. Can't say yet. >> In more detail: >> >> - We'll at Whonix invent /usr/lib/tor-controlport-filter-merger. - >> And ship that as opt-in or in a separate package by Whonix. - (If >> opt-in, we enable it in a separate Whonix package.) >> >> - /etc/tor-controlport-filter.d -- We tell Whonix users to ignore >> it. -- Internally used by /usr/lib/tor-controlport-filter . -- Will >> contain --- tails-default-profies.yml (for the sake of sharing the >> package > > But they are not useful in Whonix since they only work for loopback > connections (i.e. only for applications running on the gateway, which > should be nothing except for tor, essentially). Right? Right. [And a rather minor point...: tor-arm [now nyx] is one that could use a profile. Users tend to create screenshots of arm, so redacting any IP addresses would be nice. Also terminal emulators such as konsole might have bugs. By limiting what what tor-arm gets to see it might prevent exploiting a bug in the terminal emulator. So hypothetically speaking, you have a profile for tor-arm, we would probably use it as well.] >> and perhaps we also benefit from a profile for arm/nyx) > > For the record, we'll remove Nyx/arm in Tails 2.10, due tomorrow. :) Ah, I see. :) > >> --- 30_autogenerated.yml >> >> - /etc/tor-controlport-filter-merger.d -- Will be used by Whonix >> and its users -- 30_whonix_default.yml - will by shipped by Whonix >> by default -- 40_onionshare.yml - user defined -- 40_ricochet.yml - >> another user defined etc. >> >> - /usr/lib/tor-controlport-filter-merger parses both, -- >> /etc/tor-controlport-filter-merger.d and -- >> /usr/local/etc/tor-controlport-filter-merger.d (for Qubes-Whonix) >> -- and creates /etc/tor-controlport-filter.d/30_autogenerated.yml >> >> - Our tor-controlport-filter.service systemd service will in >> essence look like this. -- >> ExecStartPre=/usr/lib/tor-controlport-filter-merger -- >> ExecStart=/usr/lib/tor-controlport-filter >> >> Does that sound like that could work out? > > Yup, I don't see why this wouldn't work. Awesome! Cheers, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
Hi! [override] will probably work for Whonix. Joy and me drafted a plan. In one sentence: We at Whonix invent a new a separate config folder, parse it with a yml merger python script, and generate another yml file that gets passed to tor-controlport-filter by Tails. In more detail: - We'll at Whonix invent /usr/lib/tor-controlport-filter-merger. - And ship that as opt-in or in a separate package by Whonix. - (If opt-in, we enable it in a separate Whonix package.) - /etc/tor-controlport-filter.d -- We tell Whonix users to ignore it. -- Internally used by /usr/lib/tor-controlport-filter . -- Will contain --- tails-default-profies.yml (for the sake of sharing the package and perhaps we also benefit from a profile for arm/nyx) --- 30_autogenerated.yml - /etc/tor-controlport-filter-merger.d -- Will be used by Whonix and its users -- 30_whonix_default.yml - will by shipped by Whonix by default -- 40_onionshare.yml - user defined -- 40_ricochet.yml - another user defined etc. - /usr/lib/tor-controlport-filter-merger parses both, -- /etc/tor-controlport-filter-merger.d and -- /usr/local/etc/tor-controlport-filter-merger.d (for Qubes-Whonix) -- and creates /etc/tor-controlport-filter.d/30_autogenerated.yml - Our tor-controlport-filter.service systemd service will in essence look like this. -- ExecStartPre=/usr/lib/tor-controlport-filter-merger -- ExecStart=/usr/lib/tor-controlport-filter Does that sound like that could work out? Best regards, Patrick ___ 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] [Whonix-devel] Tails control port filter proxy in Whonix?
anonym: > Yay! Let's try to make this fork short-lived! Yes! :) > Note that Tails' version has changed quite a lot since you forked -- please try to keep your fork delta minimal (i.e. only do what *must* be done)! Our diff of the filter is quite mergable, I guess. In summary: - filters = yaml.safe_load(fh.read()) - #!/usr/bin/python3 -uso python exceptions end up in journal - config parser - --listen-interface (which you already said you want to add) (And the packaging stuff is not all that difficult?) We have a ticket for merging Tails' version into Whonix's version so we get your enhancement and so the diff looks simpler. [1] > So, since all your filters match *everything*, you could actually merge all the filters yourself into a single filter rule file, right? In fact, the only non-sytlistic reason you want merging of multiple matched rules is to allow Whonix users to add their own filters without overwriting yours (which causes issues during Whonix upgrades), correct? > > If so, I think I have a simpler solution: we introduce a new top-level key called `override` which takes a list of strings. If such a filter is matched together with a filter whose name is listed in `override`, then the `override`-filter is merged into the other one, and has priority whenever there's any ambiguity. So with this, Whonix would ship a single, nicely commented filter called 'whonix', and users that need to modify it simply creates a filter with `override: ['whonix']`. > > The only drawback I can see is that Whonix cannot organize the filters in separate files this way, but I think that is a small prize to pay for such a simple solution to this problem (which I fear otherwise can make it really hard to reason about filters when they grow in number). I actually think Whonix having a single file is slightly advantageous since you use the same match rules in every filter. > > Would this work for you? No. (However, I am not sure I fully understood your proposal. Technically at the moment all config file snippets are merged into the same merged filter rule.) Having the filters split in multiple files is very much desirable. We want to ship a maximally restrictive config by default. And then allow users to make it more permissive as required depending on their use case. Just two different configs, one for maximum restrictive vs one for custom maximum permissive is probably not right balance here. (We match everything because of necessity - to keep the code complexity manageable. Matching by IP would be a nice feature, so would be a profile on the gateway that only matches `arm`.) For example, adding onionshare is one of the safer applications one can whitelist due to the limited range of listening ports it opens. ricochet is more crazy, since all ports need to be allowed. (Something being discussed with upstream so this may change for Debian buster.) Some applications want to see the onion's private key [ricochet, so it can restore it later], for others we can inject DiscardPK and redact it. I think other applications will require access to further Tor internal states. Ricochet uses STATUS_CLIENT, but fortunately also does not break without it yet. Having to use something like "override: ['whonix']" and somehow have a hierarchy of files named that way, if they are splittable/stackable, would of course not be an issue. > Beyond that, I'll add your `--listen-interface` option, and I'll add a `--filters-dir` option that can be used to override the default filters dir, and that can be passed multiple times (so you'll pass `--filters-dir /etc/tor-controlport-filter.d --filters-dir /usr/local/etc/tor-controlport-filter.d/`). That's great! (Please don't fail if the folder does not exist - logging that only would be a lot better.) Cheers, Patrick [1] https://phabricator.whonix.org/T612 ___ 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 control port filter proxy in Whonix?
anonym:
> Patrick Schleizer:
>> Noticed one incompatibility.
>>
>> ZeroNet uses custom code rather than python-stem to talk to Tor control
>> protocol. It's line handling works with original Tor, but not with the
>> filter.
>
> The filter *should* be able to deal with any client implementation as long as
> it follow the control-spec, but there can of course be bugs.
>
>> https://github.com/HelloZeroNet/ZeroNet/issues/756
>>
>> https://github.com/Whonix/control-port-filter-python/blob/master/usr/share/tor-controlport-filter/examples/40_zeronet.yml
>
> Given your error:
>
> TorManager Tor controller connect error: AttributeError: 'NoneType'
> object has no attribute 'group' in TorManager.py line 160
>
> which triggers in this part of ZeroNet's src/Tor/TorManager.py:
>
> [...]
> # Version 0.2.7.5 required because ADD_ONION support
> res_version = self.send("GETINFO version", conn)
> version = re.search('version=([0-9\.]+)', res_version).group(1)
> assert float(version.replace(".", "0", 2)) >= 207.5, "Tor version
> >=0.2.7.5 required, found: %s" % version
>
> self.status = u"Connected (%s)" % res_auth
> self.conn = conn
> except Exception, err:
> self.conn = None
> self.status = u"Error (%s)" % err
> self.log.error("Tor controller connect error: %s" %
> Debug.formatException(err))
> [...]
>
> it seems to me like your filter lacks a rule allowing the "GETINFO version"
> command.
I don't think so. It's already white listed here:
https://github.com/Whonix/control-port-filter-python/blob/master/etc/tor-controlport-filter.d/30_whonix.yml
Also no rejected messages in journal. Actually, the communication in the
logs looked all correct.
Best regards,
Patrick
___
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 control port filter proxy in Whonix?
Noticed one incompatibility. ZeroNet uses custom code rather than python-stem to talk to Tor control protocol. It's line handling works with original Tor, but not with the filter. https://github.com/HelloZeroNet/ZeroNet/issues/756 https://github.com/Whonix/control-port-filter-python/blob/master/usr/share/tor-controlport-filter/examples/40_zeronet.yml Best regards, Patrick ___ 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 control port filter proxy in Whonix?
Whonix has forked tor-controlport-filter by Tails. https://github.com/Whonix/control-port-filter-python Whonix is using a different configuration parser. This is now documented in details here: https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy/tor-controlport-filter/config Best regards, Patrick ___ 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 control port filter proxy in Whonix?
Happy to report, that a few profiles have been successfully written. That are using Whonix forked config parsing code. They are now living here: - https://github.com/Whonix/control-port-filter-python/tree/master/usr/share/tor-controlport-filter/examples There is one for onionshare, one for ricochet as well as one for ZeroNet. So onionshare and ricochet will most likely run fine in the next version of Whonix, Whonix 14. I am impressed by the rewrite functionalities which are a blessing. Ricochet does something rather ugly, requesting several GETINFO status at once. GETINFO status/circuit-established status/bootstrap-phase net/listeners/socks With Tails control port filter proxy, these are elegantly rewritten. GETINFO: - pattern: 'status/circuit-established status/bootstrap-phase net/listeners/socks' response: - pattern: '250-status/bootstrap-phase=*' replacement: '250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"' - pattern: '250-net/listeners/socks=".*"' replacement: '250-net/listeners/socks="127.0.0.1:9150"' The ZeroNet profile latter however might require some more hackery. Or fixes in ZeroNet or fixes in the control port filter proxy. This is probably because ZeroNet has custom code for Tor control protocol authentication. Not using python-stem. ZeroNet works when having a direct Tor control connection but not through the control port filter proxy. - https://github.com/HelloZeroNet/ZeroNet/blob/master/src/Tor/TorManager.py Reported two issues. - https://github.com/HelloZeroNet/ZeroNet/issues/756 - https://github.com/HelloZeroNet/ZeroNet/issues/758 Best regards, Patrick ___ 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] future of tor-launcher? - Firefox XPCOM / XUL based add-ons deprecation
Hi, XPCOM / XUL based add-ons will be deprecated in Firefox. [1] I've searched trac, mailing list, irc logs... I know you are aware of that, but haven't found your plan forward. Is there already one? What are your plans regarding tor-launcher? Will tor-launcher be ported over as Firefox WebExtension? Is that even possible? Or will tor-launcher become a standalone application that runs outside of Firefox? If it is the latter, we Whonix would be interested in that. Our use case is "same as system Tor". I guess the Tails developers may be interested in that also, hence cc'd their list also. Best regards, Patrick [1] https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ ___ 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 control port filter proxy in Whonix?
Patrick Schleizer:
> anonym:
>> Patrick Schleizer:
>>> anonym:
>>> About the packaging. If you like the genmkfile way to package things, I
>>> could also do the packaging. Only disadvantage would be an extra
>>> dependency on genmkfile.
>>>
>>> https://github.com/Whonix/control-port-filter-python
>>> https://github.com/Whonix/genmkfile
>>>
>>> That would be trivial on my side since Tails control filter seems very
>>> similar to control-port-filter-python. (control-port-filter-python
>>> packaged with genmkfile is a lintian --pedantic warning free and to my
>>> knowledge, fully complaint Debian source and binary package.) Otherwise,
>>> I'd just wait for you.
>>
>> Sure! I bet you'll beat me to it, so I don't want to be the blocker, but
>> perhaps I'll take over the packaging in the future, depending on how
>> things go (would this make sense to include in Debian?). However, first
>> we need, in order:
>
> Not sure if upload to Debian would benefit any of our projects or if
> anyone besides our two projects would be interested in that package. Due
> to release cycles, I guess we'd end up not using that package in
> Tails/Whonix anyhow. I must admit, that this chance to get genmkfile
> into Debian as a byproduct is more appealing than the filter itself.
>
> If any other of Whonix's packages seems useful to be uploaded to Debian
> or otherwise useful for Tails, I'd be happy to polish them if there are
> any requests to return the favor and to improve the cooperation.
>
>> 1. A name that doesn't including 'tor'. What about 'grater' or
>> 'onion-grater'? My inspiration is something like [0]. :) Otherwise
>> there's 'onion-filter' I guess.
>
> What about control-port-filter-python? :)
>
> I was rethinking this. The packaging may not be that important on the
> Whonix side. Since the tails filter is small, clean, nice and simple and
> "quite similar" to currently used control-port-filter-python... I could
> just copy over the tails filter to control-port-filter-python
> usr/sbin/cpfpd. (Along with some minor things such as debian/control
> migrating dependencies list and systemd unit file differences.)
>
>> 2. A dedicated Git repo (trivial once we have a name).
>
> https://github.com/Whonix/control-port-filter-python ? :)
>
> The separate upstream tails filter repository would just help me to stay
> on top of changes rather than following changes in the huge Tails main
> repository. It's not very important either. If you'd ever find a
> security critical issue, please notify me. Otherwise for newer features,
> I'll probably learn about them early enough.
>
>>> I added 'Flags=DiscardPK', which works and I thought that is useful at
>>> least in case of Whonix. The workstation does not need to learn the
>>> hidden service key since onionshare does not use it anyhow. Not sure
>>> this (and the following) makes also sense in Tails?
>>>
>>> Some lines in Tor's response contain the following:
>>> (azazazazazazaz10 is the HS)
>>>
>>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=0
>>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=1
>>> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN gliberrish gliberrish
>>> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN gliberrish
>>>
>>> Could you please show how to rewrite them to:
>>>
>>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=0
>>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=1
>>> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN dedacted dedacted
>>> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN dedacted
>>>
>>> I am not sure stem would complain about this, but I guess not
>>
>> onionshare uses stem's `create_ephemeral_hidden_service()` convenience
>> method with `await_publication=True`, and it tracks the state of the
>> hidden services publication via HS_DESC events, so you have to be
>> careful here (e.g. only allowing the UPLOADED won't work, probably).
>>
>> So, to me it looks like you need the following (untested) config,
>> although you might want to study the spec to see which events are to be
>> expected:
>>
>> HS_DESC:
>> - pattern: '650 HS_DESC CREATED (\S+) (\S+) (\S+) \S+ (.+)'
>> replacement: '650 HS_DESC CREATED {} {} {} redacted {}'
>>
Re: [Tails-dev] Tails control port filter proxy in Whonix?
Hi, it's now packaged and lintian pedantic clean. The package should be generic (work in Whonix and Tails at the same time) for the most part. The missing part is Tails' config files. Since I don't know if you want to actually use that package, I skipped Tails' config files and just dropped Whonix's config file. If you like to use that package, I would be happy to add Tails' config [remove the only Whonix specific thing, the config]. [And then add Whonix's config to some other of Whonix's packages.] https://github.com/Whonix/control-port-filter-python Best regards, Patrick ___ 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] Fwd: [tbb-dev] Tor Browser and Targeted RAM Bit-Flips
Forwarded Message Subject: [tbb-dev] Tor Browser and Targeted RAM Bit-Flips Date: Fri, 18 Nov 2016 10:16:47 +1100 From: teor Reply-To: discussion regarding Tor Browser Bundle development To: tbb-...@lists.torproject.org Hi Mike (and other Tor Browser devs), Thought you might be interested in this tor-dev thread about securing Tor and Tor Browser against targeted RAM bit-flip attacks: https://lists.torproject.org/pipermail/tor-dev/2016-November/011655.html T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tbb-dev mailing list tbb-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev ___ 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] Tails control port filter proxy in Whonix?
anonym:
> Patrick Schleizer:
>> anonym:
>> About the packaging. If you like the genmkfile way to package things, I
>> could also do the packaging. Only disadvantage would be an extra
>> dependency on genmkfile.
>>
>> https://github.com/Whonix/control-port-filter-python
>> https://github.com/Whonix/genmkfile
>>
>> That would be trivial on my side since Tails control filter seems very
>> similar to control-port-filter-python. (control-port-filter-python
>> packaged with genmkfile is a lintian --pedantic warning free and to my
>> knowledge, fully complaint Debian source and binary package.) Otherwise,
>> I'd just wait for you.
>
> Sure! I bet you'll beat me to it, so I don't want to be the blocker, but
> perhaps I'll take over the packaging in the future, depending on how
> things go (would this make sense to include in Debian?). However, first
> we need, in order:
Not sure if upload to Debian would benefit any of our projects or if
anyone besides our two projects would be interested in that package. Due
to release cycles, I guess we'd end up not using that package in
Tails/Whonix anyhow. I must admit, that this chance to get genmkfile
into Debian as a byproduct is more appealing than the filter itself.
If any other of Whonix's packages seems useful to be uploaded to Debian
or otherwise useful for Tails, I'd be happy to polish them if there are
any requests to return the favor and to improve the cooperation.
> 1. A name that doesn't including 'tor'. What about 'grater' or
> 'onion-grater'? My inspiration is something like [0]. :) Otherwise
> there's 'onion-filter' I guess.
What about control-port-filter-python? :)
I was rethinking this. The packaging may not be that important on the
Whonix side. Since the tails filter is small, clean, nice and simple and
"quite similar" to currently used control-port-filter-python... I could
just copy over the tails filter to control-port-filter-python
usr/sbin/cpfpd. (Along with some minor things such as debian/control
migrating dependencies list and systemd unit file differences.)
> 2. A dedicated Git repo (trivial once we have a name).
https://github.com/Whonix/control-port-filter-python ? :)
The separate upstream tails filter repository would just help me to stay
on top of changes rather than following changes in the huge Tails main
repository. It's not very important either. If you'd ever find a
security critical issue, please notify me. Otherwise for newer features,
I'll probably learn about them early enough.
>> I added 'Flags=DiscardPK', which works and I thought that is useful at
>> least in case of Whonix. The workstation does not need to learn the
>> hidden service key since onionshare does not use it anyhow. Not sure
>> this (and the following) makes also sense in Tails?
>>
>> Some lines in Tor's response contain the following:
>> (azazazazazazaz10 is the HS)
>>
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=0
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=1
>> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN gliberrish gliberrish
>> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN gliberrish
>>
>> Could you please show how to rewrite them to:
>>
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=0
>> 650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=1
>> 650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN dedacted dedacted
>> 650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN dedacted
>>
>> I am not sure stem would complain about this, but I guess not
>
> onionshare uses stem's `create_ephemeral_hidden_service()` convenience
> method with `await_publication=True`, and it tracks the state of the
> hidden services publication via HS_DESC events, so you have to be
> careful here (e.g. only allowing the UPLOADED won't work, probably).
>
> So, to me it looks like you need the following (untested) config,
> although you might want to study the spec to see which events are to be
> expected:
>
> HS_DESC:
> - pattern: '650 HS_DESC CREATED (\S+) (\S+) (\S+) \S+ (.+)'
> replacement: '650 HS_DESC CREATED {} {} {} redacted {}'
> - pattern: '650 HS_DESC UPLOAD (\S+) (\S+) .*'
> replacement: '650 HS_DESC UPLOAD {} {} redacted redacted'
> - pattern: '650 HS_DESC UPLOADED (\S+) (\S+) .+'
> replacement: '650 HS_DESC UPLOADED {} {} redacted'
> - pattern: '.*'
> replacement: ''
That unfortunately does not work.
use
[Tails-dev] onionshare does not notice when control port disconnects - was: Tails control port filter proxy in Whonix?
anonym: > Patrick Schleizer: >> When the filter is terminated, onionshare apparently does not notice >> that. Would be better if onionshare would notice that. Is that a bug? > > It seems like a "bug" in onionshare, or even the control port language > protocol itself since it (AFAICT) doesn't have a concept of the server > quitting mid-session. No signal is sent, and I haven't even found an > event one can explicitly subscribe to to learn when it shuts down. In > fact, any stem-application will, for instance, notice that Tor closed > its control port on the next send() or recv() on the socket, and then > throw a stem.SocketClosed. Both nc and telnet will notice and automatically terminate as expected once the filter was stopped. Therefore I guess the control protocol may be sufficient. Do you think this could be a bug in onionshare or onionshare? //cc Damian, Micah Cheers, Patrick ___ 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 control port filter proxy in Whonix?
anonym:
> Patrick Schleizer:
>> anonym:
>>> Patrick Schleizer:
>>>> Where I need to correct myself. The injected IP is probably difficult to
>>>> add to a config file since IPs in Qubes will remain dynamic for some
>>>> quite some time until Qubes 4.0. We'd need something like this.
>>>>
>>>> ADD_ONION:
>>>> - pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
>>>> replacement: 'NEW:BEST Port=80,:{}'
>>>>
>>>> (Where is just used to illustrate. Not a syntax
>>>> suggestion. Could be expressed with any other special chars.)
>>>>
>>>> Could you implement that please?
>>>
>>> I hacked something together so that the following should work for you:
>>>
>>> ADD_ONION:
>>> - pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
>>> replacement: 'NEW:BEST Port=80,{client-address}:{}'
>>>
>>> See attached patch, but note that I haven't tested it (and not pushed
>>> it, since the branch is up for review, and I won't have time to test it
>>> for that). If there's some silly syntax error, I bet you can fix it
>>> yourself. :)
>>
>> Fixed some minor issues indeed. Patch attached.
>>
>> However, there is an offending line, I am stuck with.
>>
>> return r['replacement'].format(*match.groups()) + terminator
>>
>> File "./tor-controlport-filter", line 334, in rewrite_line
>> return r['replacement'].format(*match.groups()) + terminator
>> KeyError: 'client-address'
>>
>> Could you fix that please?
>
> Yesterday's patch was trash. See the new commit(s) I've just pushed to
> the branch.
That seems to work! :)
When the filter is terminated, onionshare apparently does not notice
that. Would be better if onionshare would notice that. Is that a bug?
About the packaging. If you like the genmkfile way to package things, I
could also do the packaging. Only disadvantage would be an extra
dependency on genmkfile.
https://github.com/Whonix/control-port-filter-python
https://github.com/Whonix/genmkfile
That would be trivial on my side since Tails control filter seems very
similar to control-port-filter-python. (control-port-filter-python
packaged with genmkfile is a lintian --pedantic warning free and to my
knowledge, fully complaint Debian source and binary package.) Otherwise,
I'd just wait for you.
I added 'Flags=DiscardPK', which works and I thought that is useful at
least in case of Whonix. The workstation does not need to learn the
hidden service key since onionshare does not use it anyhow. Not sure
this (and the following) makes also sense in Tails?
Some lines in Tor's response contain the following:
(azazazazazazaz10 is the HS)
650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=0
650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN gliberrish REPLICA=1
650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN gliberrish gliberrish
650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN gliberrish
Could you please show how to rewrite them to:
650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=0
650 HS_DESC CREATED azazazazazazaz10 UNKNOWN UNKNOWN dedacted REPLICA=1
650 HS_DESC UPLOAD azazazazazazaz10 UNKNOWN dedacted dedacted
650 HS_DESC UPLOADED azazazazazazaz10 UNKNOWN dedacted
I am not sure stem would complain about this, but I guess not and seems
useful to me be to contain that information.
Cheers,
Patrick
___
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 control port filter proxy in Whonix?
anonym:
> Patrick Schleizer:
>> Where I need to correct myself. The injected IP is probably difficult to
>> add to a config file since IPs in Qubes will remain dynamic for some
>> quite some time until Qubes 4.0. We'd need something like this.
>>
>> ADD_ONION:
>> - pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
>> replacement: 'NEW:BEST Port=80,:{}'
>>
>> (Where is just used to illustrate. Not a syntax
>> suggestion. Could be expressed with any other special chars.)
>>
>> Could you implement that please?
>
> I hacked something together so that the following should work for you:
>
> ADD_ONION:
> - pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
> replacement: 'NEW:BEST Port=80,{client-address}:{}'
>
> See attached patch, but note that I haven't tested it (and not pushed
> it, since the branch is up for review, and I won't have time to test it
> for that). If there's some silly syntax error, I bet you can fix it
> yourself. :)
Fixed some minor issues indeed. Patch attached.
However, there is an offending line, I am stuck with.
return r['replacement'].format(*match.groups()) + terminator
File "./tor-controlport-filter", line 334, in rewrite_line
return r['replacement'].format(*match.groups()) + terminator
KeyError: 'client-address'
Could you fix that please?
Cheers,
Patrick
>From cf1a7c9033d4b06763c71f166ced2892b82f8a5b Mon Sep 17 00:00:00 2001
From: Your Name
Date: Sat, 12 Nov 2016 23:17:54 +
Subject: [PATCH] syntax
---
tor-controlport-filter | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tor-controlport-filter b/tor-controlport-filter
index 95be1e5..face56e 100755
--- a/tor-controlport-filter
+++ b/tor-controlport-filter
@@ -316,10 +316,10 @@ def handle_controlport_session(controller, readh, writeh, client_desc, client_pi
def rewrite_line(replacers, line):
builtin_replacers = (
-('{client-address}', client_address[0]),
-('{client-port}',client_address[1]),
-('{server-address}', server_address[0]),
-('{server-port}',server_address[1]),
+('{client-address}', str(client_address[0])),
+('{client-port}',str(client_address[1])),
+('{server-address}', str(server_address[0])),
+('{server-port}',str(server_address[1])),
)
for pattern, replacement in builtin_replacers:
line = line.replace(pattern, replacement)
@@ -560,7 +560,7 @@ class FilteredControlPortProxyHandler(socketserver.StreamRequestHandler):
try:
handle_controlport_session(controller, self.rfile, self.wfile,
client_desc, client_pid,
- self.client_address, self.server_address,
+ self.client_address, server_address,
allowed_commands, allowed_events,
restrict_stream_events
)
@@ -631,9 +631,10 @@ def main():
global_args.__dict__['print_requests'] = global_args.complain or \
global_args.debug
global_args.__dict__['print_responses'] = global_args.debug
-address = (global_args.listen_address, global_args.listen_port)
-server = FilteredControlPortProxy(address, FilteredControlPortProxyHandler)
-log("Tor control port filter started, listening on {}:{}".format(*address))
+global server_address
+server_address = (global_args.listen_address, global_args.listen_port)
+server = FilteredControlPortProxy(server_address, FilteredControlPortProxyHandler)
+log("Tor control port filter started, listening on {}:{}".format(*server_address))
try:
server.serve_forever()
except KeyboardInterrupt:
--
2.1.4
___
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 control port filter proxy in Whonix?
anonym: > Patrick Schleizer: >> That crashes the filter for me. > > Argh, I meant: > > GETINFO: > - pattern: 'net/listeners/socks' > response: > - pattern: '250-net/listeners/socks=".*"' > replacement: '250-net/listeners/socks="127.0.0.1:9150"' > > (Notice the removed "-" in front of "replacement".) That works for me! Cheers, Patrick ___ 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 control port filter proxy in Whonix?
anonym:
> Patrick Schleizer:
>>>> - https://phabricator.whonix.org/T564
>>>
>>> I'd need more details of what the idea is here.
>>
>> Prevent (in case of some bug or compromise) that more than X hidden
>> services are created. The number of hidden service should be tracked. If
>> more than X are created, requests for creating even more should be rejected.
>>
>> This is because too many hidden services on the same connection may be
>> suspicious for ISP level adversaries or even dangerous for other tricky
>> anonymity reasons.
>
> Ok, while the "other tricky anonymity reasons" may be true, I don't buy
> the ISP argument: in its position (it sees the first hop) the traffic
> generated by hosting lots of (never unused) hidden services won't look
> very interesting, I'd wager. If it looked interesting, an attacker that
> has compromised Whonix workstation would most likely be able to generate
> the same traffic pattern by using tor in some other way. Any way, I
> think a proper threat model where e.g. "suspicious traffic" is defined
> is needed to treat this properly. IMHO we have tons of much lower
> hanging fruit in the area of "network fingerprinting".
I agree with this.
>>> Any way, it seems that if one is careful when writing the rules for
>>> ADD_ONION, one can limit the number simply by making sure there's that
>>> number of possible matches of [host:]ports. E.g. the above filter for
>>> onionshare can at most allow 100 ports. Solved?
>>
>> I guess. Is that already possible?
>
> Yes, e.g.:
>
> ADD_ONION:
> - pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
>
> That would match only the 50 different ports that onionshare will ever
> try to run the web server on. It's a solution by coincidence, but it
> works! :)
Ha, tricky, but a good solution.
>>> Let me end with: if you test our filter in Whonix, and decide it's the
>>> way to go, then I'll try to do the Debian packaging unless someone wants
>>> to contribute it!
>>
>> That's an awesome offer you! Yes, please do.
>
> Sorry, what I meant was: if you *first* try it (which should be easy in
> a running Whonix session) and decide that you want to use it, *then* I
> will do the packaging. Fair enough?
Sure. I was already testing the filter inside a running Whonix session. :)
So for using the Tails control port filter proxy in Whonix, there are
just two remaining blockers. The Debian packaging and the following...
Patrick Schleizer:
>> For connectivity, we need to remove 127.0.0.1 and replace it with
>> >> Whonix-Workstation IP. That is currently done with the following code
>> >> block that I was going to merge with T562.
>> >>
>> >>
https://github.com/Whonix/control-port-filter-python/blob/6a131266a8dc8f98ff22a3b83fae9d43e38b3127/usr/sbin/cpfpd#L345-L375
>>
>> Got it. Our filter doesn't do this (as we do not have this need) but I
>> feel a general solution could be to allow sed-like rewriting rules, e.g.
>>
>> ADD_ONION:
>> - pattern: 'NEW:BEST Port=80,(176\d\d)'
>> replacement: 'NEW:BEST Port=80,10.137.6.41:{0}'
>>
>> which would be easy to implement.
Where I need to correct myself. The injected IP is probably difficult to
add to a config file since IPs in Qubes will remain dynamic for some
quite some time until Qubes 4.0. We'd need something like this.
ADD_ONION:
- pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
replacement: 'NEW:BEST Port=80,:{}'
(Where is just used to illustrate. Not a syntax
suggestion. Could be expressed with any other special chars.)
Could you implement that please?
Cheers,
Patrick
___
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 control port filter proxy in Whonix?
anonym:
> Patrick Schleizer:
>> Hi there,
>>
>> sorry for the delay, I got side tracked with other stuff.
>>
>> My first and summary impression is, that this is looking excellent!
>
> \o/
>
>> ./tor-controlport-filter --listen-address 9052
>> Tor control port filter started, listening on 9052:9051
>>
>> Do you see any reason in Whonix not to use the following...?
>>
>> match-hosts:
>> - '*'
>
> Principle of least privilege and defense in depth, I guess. If your
> threat model supports that any host with access to the gateway can use
> the Tor control port, then it's fine. Otherwise, perhaps you solve it on
> the firewall-level instead. But if a static address is used for the
> workstation, and its the only expected client, then I think locking it
> down is a good idea, especially when it is so cheap (just a static
> configuration).
We don't have static addresses in Qubes-Whonix yet. Will come in Qubes
4.0. Then indeed match-hosts will be a great feature for us.
>> What I found confusing is, that "SIGNAL NEWNYM" is allowed, but being
>> case sensitive, i.e. "signal newnym" being blocked.
>
> The command ("SIGNAL") is not case sensitive (e.g. "signal NEWNYM" is
> eq. to "SIGNAL NEWNYM") per the Tor control port specification, and the
> filter knows this. For arguments it depends on the command, and for
> simplicity the filter tries to understand as little as possible of the
> underlying language, so the responsibility is on the author of the
> config file. However, it's fairly easy to profile an application with
> the --complain option so I'm not worried about this being an issue.
Okay.
>> What do you suggest Whonix should use to pass --listen-address? A system
>> drop-in file overwriting ExecStart?
>
> Yes, an override like that seems like the way to go.
Alright. :)
Cheers,
Patrick
___
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 control port filter proxy in Whonix?
anonym:
> Patrick Schleizer:
>>>>>> - https://phabricator.whonix.org/T564
>>>>
>>>> Protecting cpfpy from DDOS from client applications. Not sure that
>>>> matters for Tails?
>>>
>>> We do not do much specific here. What kind of DoS are you talking about
>>> here? Eating up all RAM or crashing the filter via oom kill? Preventing
>>> the filter from serving other clients? We admittedly do not do much here
>>> except that each client is dealt with in a separate thread, and that
>>> client requests are limited to 1024 bytes.
>>
>> Yes, I meant crashing the filter or making the whole computer unusable
>> by flooding cpfpy with too much requests.
>
> So the scenario is something like this: an attacker compromises the
> workstation, and then want to crash the filter running on the gateway
> (or even crash the whole gateway)?
Yes.
> If so, IMHO DoS is the least of our
> worries since all gateway activity (= user activity) now is compromised.
> I mean, the attacker can DoS the workstation by killing all user
> processes or whatever.
>
> ... but now I get that you may run several workstations (in Qubes, I
> guess), and then this makes sense.
Yes.
> Quick solution that a determined adversary probably easily can work
> around: in the gatway's firewall rules, rate limit the traffic to the
> control filter per workstation.
I will consider this, useful, but guess it's not a priority as you
pointed out.
> Slightly more involved, slightly more efficient solution: we could add
> an option to the filter making the server forking instead of threading,
> and then adjust OOM scores and NICEness for these subprocesses so they
> are low prio for the CPU, and prone to get OOM killed if memory gets
> low. The server process itself will be configured in the opposite way
> (you can add the options via a systemd override).
>
> Any way, DoS protection is pretty hard... and I doubt it's much of a
> problem on *local* systems. Rather DoS gives away that a workstation has
> been compromised, instead of it remaining in a stealthy surveillance
> mode, which I think I must consider worse (even when limited to a single
> workstation == application).
>>> I could even imagine yet another rule-type for solving these types of
>>> issues:
>>>
>>> GETINFO:
>>> - pattern: 'net/listeners/socks'
>>> respond: '250-net/listeners/socks="127.0.0.1:9150"'
>>
>> Seems great!
>
> In the end, this was generalised into:
>
> GETINFO:
> - pattern: 'net/listeners/socks'
> response:
> - pattern: '250-net/listeners/socks=".*"'
> - replacement: '250-net/listeners/socks="127.0.0.1:9150"'
That crashes the filter for me.
config:
---
- match-exe-paths:
- '*'
match-users:
- '*'
match-hosts:
- '*'
commands:
SIGNAL:
- 'NEWNYM'
GETINFO:
- 'circuit-established'
GETINFO:
- pattern: 'net/listeners/socks'
response:
- pattern: '250-net/listeners/socks=".*"'
- replacement: '250-net/listeners/socks="127.0.0.1:9150"'
run:
user@host:~$ ./tor-controlport-filter --listen-address 0.0.0.0 --debug
Tor control port filter started, listening on 0.0.0.0:9051
10.137.11.80:49996 (filter: tor-browser) connected: loaded filter:
tor-browser
Final rules:
commands:
GETCONF:
- {pattern: ()}
GETINFO:
- pattern: net/listeners/socks
response:
- {pattern: 250-net/listeners/socks=".*"}
- {replacement: '250-net/listeners/socks="127.0.0.1:9150"'}
SIGNAL:
- {pattern: NEWNYM}
events: {}
restrict-stream-events: false
10.137.11.80:49996 (filter: tor-browser): -> GETINFO net/listeners/socks
10.137.11.80:49996 (filter: tor-browser) disconnected: client quit
Exception happened during processing of request from ('10.137.11.80', 49996)
Traceback (most recent call last):
File "/usr/lib/python3.4/socketserver.py", line 613, in
process_request_thread
self.finish_request(request, client_address)
File "/usr/lib/python3.4/socketserver.py", line 344, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python3.4/socketserver.py", line 669, in __init__
self.handle()
File "./tor-controlport-filter", line 550, in handle
restrict_stream_events
File "./tor-controlport-filter", line 466, in handle_controlport_session
response_rewriter=response_rewriter)
File "
Re: [Tails-dev] Tails control port filter proxy in Whonix?
anonym:
> https://tails.boum.org/news/report_2016_09/#index2h1
>
> and look at the documentation at the top of the script, and the filter
> rules we ship to get an idea of what it can do.
> As you can see, in Tails we use match-exe-paths and match-users a lot,
> but since you won't have access to these I guess you want something like
> match-hosts, so that the filter is picked based on the client's
> (non-localhost) address (= VM). Right?
The match-hosts works well for Whonix. Set to "*" for now.
- https://phabricator.whonix.org/T562
>>
>> This is about parsing add_onion and whitelisting sane commands rather
>> than letting through everything.
>
> For any command we allow a list of regexes for the arguments. If a
> command doesn't match any of them, it is filtered.
Sounds good!
>> add_onion is not a whitelist/not whitelist.
>
> I do not understand this sentence...
Originally we at Whonix thought we wanted "wildcard support". Meant,
matching just "add_onion *", i.e. letting everything through
that comes after "add_onion". As it turned out, that was insufficient.
For example, add_onion flag "nonanonymous" ought to be avoided.
Tails control port filter proxy seems to keep care of that.
>> Buggy applications or by user mistake, they could choose the add_onion
>> flag nonanonymous, which would be a disaster. We also don't know what
>> Tor control protocol upgrades are coming in the years to come. So I
>> strongly suggest a only letting through whitelisted syntaxes.
>
> ... but this I get and agree with. Currently we require ADD_ONION for
> onionshare to have args matching the regex 'NEW:BEST Port=80,176\d\d'.
Great!
>> Malicious applications could make the Tor HS listener bind on the wrong
>> interface. In Whonix-Gateway, maliciously listen on Whonix-Gateway.
>> Which could be fatal if we had also a real Tor ControlPort open there.
>> Does that make sense? I am not sure it applies to Tails, that depends on
>> your design and threat model, but it is however an interesting thought
>> that can inspire to finding more security issues with it.
>>
>> Also it may be worth making sure it can only bind to specified (and
>> configureable) local ports?
>
> Ack, this is an issue. In Tails there must be an explicit firewall rule
> allowing a user listening on some port, so I think we are covered.
Ok.
>> For connectivity, we need to remove 127.0.0.1 and replace it with
>> Whonix-Workstation IP. That is currently done with the following code
>> block that I was going to merge with T562.
>>
>> https://github.com/Whonix/control-port-filter-python/blob/6a131266a8dc8f98ff22a3b83fae9d43e38b3127/usr/sbin/cpfpd#L345-L375
>
> Got it. Our filter doesn't do this (as we do not have this need) but I
> feel a general solution could be to allow sed-like rewriting rules, e.g.
>
> ADD_ONION:
> - pattern: 'NEW:BEST Port=80,(176\d\d)'
> replacement: 'NEW:BEST Port=80,10.137.6.41:{0}'
>
> which would be easy to implement.
Yes, that would work for Whonix.
- https://phabricator.whonix.org/T564
>>
>> Protecting cpfpy from DDOS from client applications. Not sure that
>> matters for Tails?
>
> We do not do much specific here. What kind of DoS are you talking about
> here? Eating up all RAM or crashing the filter via oom kill? Preventing
> the filter from serving other clients? We admittedly do not do much here
> except that each client is dealt with in a separate thread, and that
> client requests are limited to 1024 bytes.
Yes, I meant crashing the filter or making the whole computer unusable
by flooding cpfpy with too much requests.
>> - Supports logging.
>
> I'm not sure what type of logging you are talking about here. Currently
> it uses print() (to stdout) and flush, which works well with the journal
> when run as a systemd service.Normally only filtered commands are
> logged, but there's also a --complain mode which logs all client
> requests, which is useful when writing rules for a new application.
Sounds fine!
>> - systemd support
>
> Not sure what this means. We have a .service file.
That's it.
>> - When request is 'getinfo net/listeners/socks' answer with a lie
>> '250-net/listeners/socks="127.0.0.1:9150"'.
>
> Nope. Why is this needed?
Rather minor: Not revealing all the listeners to all connected
workstations.
> I could even imagine yet another rule-type for solving these types of
> issues:
>
> GETINFO:
> - pattern: 'net/listeners/socks'
> respond: '250-net/listeners/socks="127.0.0.1:9150"'
Seems great!
___
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 control port filter proxy in Whonix?
> [...]
>> In conclusion, I think the truth is that Whonix switching to our filter
>> will require some work to reach feature-parity with you current filter,
>> and you will not really gain anything by doing so except code sharing.
>> YMMV. That said, I'd happily implement match-hosts and the two
>> additional types of rules I mentioned above if that would be enough for you.
>
> I actually went ahead and implemented these, and I've successfully been
> able to run a client on a different host than the filter, like in
> Whonix. This is how I imagine the onionshare filter configuration Whonix
> needs would look like:
>
> - match-hosts:
> - '10.1.1.42'
> commands:
> GETINFO:
> - 'version'
> - 'onions/current'
> - pattern: 'net/listeners/socks'
> response: '250-net/listeners/socks="127.0.0.1:9150"'
> GETCONF:
> - '__owningcontrollerprocess'
> ADD_ONION:
> - pattern: 'NEW:BEST Port=80,(176\d\d)'
> replacement: 'NEW:BEST Port=80,10.137.6.41:{}'
> DEL_ONION:
> - '.+'
> events:
> SIGNAL:
> suppress: true
> CONF_CHANGED:
> suppress: true
> HS_DESC:
>
> If you need help deciphering the above I refer you to the "docs":
>
>
> http://git.tails.boum.org/tails/tree/config/chroot_local-includes/usr/local/lib/tor-controlport-filter?h=feature/7870-include_onionshare
>
> Thoughts about the configuration format are highly welcome (but I doubt
> I'd like to move away from YAML)!
Looks good!
> It would be interesting to see if this works for you in Whonix. You
> definitely will have to look at the --listen-address option (0.0.0.0 or
> the address the gateway connects to), and maybe the
> --control-cookie-path and --control-socket-path options (yes, the filter
> requires a cookie protected Tor ControlSoket for now -- patches welcome
> for other modes!).
Yes, no longer using ControlPort is a very good path. ControlSocket just
matches the defaults also in Whonix.
> I don't know if/how we should proceed, but here's what I think of the
> remaining (according to an earlier email in the thread) tickets you have
> for this in Whonix vs. our filter:
>> - https://phabricator.whonix.org/T562
>
> Solved!
>> - https://phabricator.whonix.org/T564
>
> I'd need more details of what the idea is here.
Prevent (in case of some bug or compromise) that more than X hidden
services are created. The number of hidden service should be tracked. If
more than X are created, requests for creating even more should be rejected.
This is because too many hidden services on the same connection may be
suspicious for ISP level adversaries or even dangerous for other tricky
anonymity reasons.
> Any way, it seems that if one is careful when writing the rules for
> ADD_ONION, one can limit the number simply by making sure there's that
> number of possible matches of [host:]ports. E.g. the above filter for
> onionshare can at most allow 100 ports. Solved?
I guess. Is that already possible?
>> - https://phabricator.whonix.org/T565
>
> I'd need more details of what the idea is here.
Have a script (or even unit test) that runs a loop, that creates a
zillion of hidden services. And then check if this has the chance to
make the whole system unusably slow. That would be considered ddos, and bad.
> ---
>
> Let me end with: if you test our filter in Whonix, and decide it's the
> way to go, then I'll try to do the Debian packaging unless someone wants
> to contribute it!
That's an awesome offer you! Yes, please do.
Cheers,
Patrick
___
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 control port filter proxy in Whonix?
Hi there, sorry for the delay, I got side tracked with other stuff. My first and summary impression is, that this is looking excellent! ./tor-controlport-filter --listen-address 9052 Tor control port filter started, listening on 9052:9051 Do you see any reason in Whonix not to use the following...? match-hosts: - '*' What I found confusing is, that "SIGNAL NEWNYM" is allowed, but being case sensitive, i.e. "signal newnym" being blocked. What do you suggest Whonix should use to pass --listen-address? A system drop-in file overwriting ExecStart? Cheers, Patrick ___ 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] Tails HSTS website error - was: Tails control port filter proxy in Whonix?
> https://git.tails.boum.org/tails/tree/config/chroot_local-includes/usr/local/lib/tor-controlport-filter?h=feature/7870-include_onionshare When I visit that link, I cannot proceed. > Your connection is not secure > > The owner of git.tails.boum.org has configured their website improperly. To > protect your information from being stolen, Firefox has not connected to this > website. > > This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox > only connect to it securely. As a result, it is not possible to add an > exception for this certificate. Thanks anonym, for all your work on tails control port filter and replies. Very exciting developments! I am preparing responses and will test it soonish. Cheers, Patrick ___ 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] Tails control port filter proxy in Whonix?
Hi, as discussed elsewhere, yes, it would be great if we could share code bases! Does it support simultaneous connections? (Such as two applications using ephemeral Tor hidden services plus Tor Browser at once.) Does Tails control port filter proxy support events? I mean, can a client application ask for something and Tor will maybe answer a long time later? Whonix control-port-filter-python TODO, also stuff we need before we can use it: >> - https://phabricator.whonix.org/T561 Is something we must use in Whonix. Not a cpfpy missing feature but a general issue. In essence, for example the onionshare localhost server listener will not be reachable. We somehow must force it listen on all interfaces so Tor running on the gateway can access it. >> - https://phabricator.whonix.org/T562 This is about parsing add_onion and whitelisting sane commands rather than letting through everything. add_onion is not a whitelist/not whitelist. Buggy applications or by user mistake, they could choose the add_onion flag nonanonymous, which would be a disaster. We also don't know what Tor control protocol upgrades are coming in the years to come. So I strongly suggest a only letting through whitelisted syntaxes. Malicious applications could make the Tor HS listener bind on the wrong interface. In Whonix-Gateway, maliciously listen on Whonix-Gateway. Which could be fatal if we had also a real Tor ControlPort open there. Does that make sense? I am not sure it applies to Tails, that depends on your design and threat model, but it is however an interesting thought that can inspire to finding more security issues with it. Also it may be worth making sure it can only bind to specified (and configureable) local ports? For connectivity, we need to remove 127.0.0.1 and replace it with Whonix-Workstation IP. That is currently done with the following code block that I was going to merge with T562. https://github.com/Whonix/control-port-filter-python/blob/6a131266a8dc8f98ff22a3b83fae9d43e38b3127/usr/sbin/cpfpd#L345-L375 >> - https://phabricator.whonix.org/T564 Protecting cpfpy from DDOS from client applications. Not sure that matters for Tails? >> - https://phabricator.whonix.org/T565 Similar to above. >> - https://phabricator.whonix.org/T566 The unit test for T562. Other required features: - Configurable by dropping .d-style[7] configuration snippets. (ex: /etc/cpfpy.d) - Debian packaging. Lesser important features: - Supports logging. - Honors signals sigterm, sigint, keyboard interrupt. - systemd support - When request is 'getinfo net/listeners/socks' answer with a lie '250-net/listeners/socks="127.0.0.1:9150"'. Cheers, Patrick ___ 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 template for Qubes
sajolida: > I just wanted to let you know that people from Qubes started a ticket > about having a Tails template for Qubes. I never used Qubes myself and > barely understand what this means but I'll follow the ticket and maybe > others interested in Qubes should do to: DrWhax, anonym? > > https://github.com/QubesOS/qubes-issues/issues/2024 The scope of the ticket has just now been changed from "create a Tails template" to "[META] Tails-like functionality in Qubes". To illustrate what a Qubes Tails template would mean... In comparative terms... - better integration: comes with Qubes tools installed by default [comparable to a VM with VirtualBox guest additions installed by default or not for mouse integration, clipboard sharing, seamless mode and so forth] - easier installation: installs Tails on Qubes by using the system package manager [comparable to downloading a VirtualBox image from the internet vs downloading/inserting a Tails DVD manually into VirtualBox] [Currently Tails can only be run as a HVM in Qubes: It can be roughly compared to booting Tails inside VirtualBox without having VirtualBox guest additions existing] Cheers, Patrick ___ 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] [Freepto] Let's share username, /etc/hostname and /etc/host among all anonymity distributions
intrigeri: > Hi, > > I've just stumbled upon an issue [1] open by Jake on Subgraph OS bug > tracker, about this topic, so I thought I would close this thread > that's still lying in my inbox, and sum up the process that lead us to > a (not implemented) conclusion. > > Last time we discussed it over 2013 and 2014, first on this list > (threads start at [2] and [3]), we ended up deciding [4] that we > preferred a shared username+hostname among anonymity/privacy-related > distributions. > > The username that was settled upon is "user". > > The hostname that was settled upon was "host" initially, and then most > of us preferred "debian"; but since the goal is to _share_ a common > hostname with other distros, prior art counts. > > Patrick, what does Whonix use currently? Sorry for the delay, this slipped through my inbox and I just now found this by chance. As agreed back then. username: user hostname: host 127.0.0.1 host.localdomain host (Implemented in https://github.com/Whonix/anon-base-files - which is a package supposed to be shared among privacy focused distributions.) Cheers, Patrick ___ 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] [Secure Desktops] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)
I mistyped. Here is the correct version.
day 1
1) Tails user regularly goes to physical place A that provide [free] WiFi.
2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
The user uses the regular way to set up a WiFi connection. Network
Manager etc.
3) Now, Tails would remember FreeWifi832458252823523 and assign entry
guard A.
day 2
3) Tails user goes to the same physical place A that provide [free] WiFi.
2) The name of the wifi has changed to FreeWifi358235892435 with mac
address "B". The user uses the regular way to set up a WiFi connection.
Network Manager etc.
3) Now, Tails would remember FreeWifi358235892435 and assign entry guard B.
intrigeri:
> Hi,
>
> Patrick Schleizer wrote (09 Feb 2016 23:42:22 GMT) :
>> intrigeri:
>>> [can you please decide what mailing-list this discussion should happen
>>> on, and then we can stop cross-posting over 4 mailing-list?]
>
> This still holds.
>
>>> I'm not sure I understand the problem you mean to raise, though.
>>> Can you please elaborate what problem you see if users do exactly this
>>> ("click through whatever hoops required to make the WiFi connect
>>> again", which I agree is very likely)?
>
>> day 1
>
>> 1) Tails user regularly goes to physical place A that provide [free] WiFi.
>> 2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
>> The user uses the regular way to set up a WiFi connection. Network
>> Manager etc.
>> 3) Now, Tails would remember FreeWifi832458252823523 and assign entry
>> guard A.
>
>> day 2
>
>> 3) Tails user goes to the same physical place A that provide [free] WiFi.
>> 2) The name of the wifi has changed to FreeWifi358235892435 with mac
>> address "B". The user uses the regular way to set up a WiFi connection.
>> Network Manager etc.
>> 3) Now, Tails would remember FreeWifi358235892435 and assign entry guard A.
>
> I don't understand why we would pick Entry Guard A in the last step on
> day 2, can you please explain?
I mistyped. Entry guard B.
>> This is the behavior I expect from most users. And this is what I meant
>> by 'users will click through whatever hoops required to make the WiFi
>> connect again'.
>
> Fully agreed!
>> The entry guard selection would now be influenced by by the provider of
>> the [free] WiFi. And I think such an adversary capability is something
>> as we agree that is to be avoided.
>
> Right, it's something we want to limit. anonym and I have been working
> a bit more on it, and have reverted the addition of the ESSID in the
> data we hash, found another attack, thought a bit about potential
> defenses, and discussed it a bit more. See the "First iteration"
> section on our blueprint for details:
>
> https://tails.boum.org/blueprint/persistent_Tor_state/
You quoted me! Glad that I was heard! :)
> In the current state of things we're undecided whether our current
> design is good enough to be worth shipping, or not. We'll probably ask
> someone (probably Isis) for help evaluating it and/or designing
> something better.
Or perhaps consider asking the tor-talk (-dev) mailing list in order to
get more input.
Cheers,
Patrick
___
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 htpdate - why use time information from neutral and foe pools?
Patrick Schleizer: > intrigeri wrote: >>> I can't think of another area in which asking a hostile for advice is a >>> good idea. Maybe "if friend and foe both agree, you can be confident >>> that they're right; if they disagree, look further" - but that's not >>> what Tails htpdate is doing. >> >> Indeed, it should probably discard information that is diverging too >> much from what others tell us. Care to file a "research" ticket >> about it? > > https://labs.riseup.net/code/issues/8283 > Issue #8283 has been updated by intrigeri. > > > Is the reasoning behind Whonix design decision on this topic summed up anywhere? No. To make it quick to save time, let's see if the following of the top of my head sounds already convincing enough... - The burden of proof is on you. The claim here is "asking foes for something is better than just asking pals". -- The absence of an argument in favor of that. Nothing in the design documentation or mailing list discussion explained, why it makes sense ask someone you think to be a foe [by putting them into a pool called foe] for anything. - Try a real life analogy. Would you walk around and ask someone likely to work against you "what time is it please?" I think not. You probably try to avoid these and ask people you consider 'pal'. - The marketing argument. Try to explain why you must connect to nsa.gov [made up foe example]. In the absence of a good explanation why this is useful, I would avoid it. Therefore if you have the option of only asking pals, why involve foes? The only case I could think of to ask foes would be if there are too few pals. But I don't think this is the case. Cheers, Patrick ___ 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] [Secure Desktops] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)
[quoting you in full since this mail was eaten by the whonix-devel list for some reason even though I manually allowed it] intrigeri: > Hi, > > [can you please decide what mailing-list this discussion should happen > on, and then we can stop cross-posting over 4 mailing-list?] > > Patrick Schleizer wrote (02 Jan 2016 22:36:13 GMT) : >> But I think location aware Tor entry guards (LATEG) are wrong headed. >> The topic of LATEG is so difficult to explain to the user, that as you >> plan, you cannot add it the the UI. Perhaps buried under an advanced >> setting, but that's not worth so much. So it cannot be manual by >> default. Only automatic. > > I agree. > >> Which brings me to the issue. > >> There is a reason, why Tor picks a Tor entry guard and sticks to it. By >> changing it more often than Tor would do, you are subverting the reason >> for using Tor entry guards in the first place. In a sense, you are to a >> small degree thereby becoming a Tor developer, and modifying Tor's relay >> choosing algorithm. > > I think I see what you mean, and indeed it's the kind of things about > which my self-confidence is pretty low, and I'd personally rather > avoid fiddling with things I don't understand. > > But the thing is: by using random guards every time Tails starts, we > are _already_ making the very same kind of decisions. Only, we are > making it very badly, and this has been going on for too many years > already. > > Let's face it: as distro integrators, in the current state of things, > we have to make a decision to compensate for the fact that Tor's guard > selection wasn't designed with our threat model in mind. > Keeping things as-is would be a decision. Using fully persistent entry > guards (not location aware), like Tor Browser users get currently, > would be another decision. We cannot escape it, so we're trying to > make this decision in a way that's much better for the vast majority > of Tails users. The simplest answers to give it are "same as Tor default", "same as Debian system Tor" and/or "same as TBB". Since you can install Debian and Tor on USB or TBB and USB, then be on travel, The Tor Project has decided to keep entry guards across geographical location. The would imho be the best [as closest to TPO] solution that any Tor focused distribution can do. >> I wonder, if the whole LATEG thing would not be much better implemented >> in Tor itself. If so, then any (further) research of the entry guard >> topic would still apply to Tails, and not to Tor only. > > With my (lazy by design) distro integrator's hat, I can only agree: > the more work is done by little-t-tor, the less I have to deal with > myself, and the more is shared cross-distro. Yay. > > However, taking a step back, I'm not sure it makes a whole lot of > sense: to be location-aware, tor would have to gain knowledge about > new concepts, and interface with OS services, that it can currently > happily ignore so far; add to this that tor is multi-platform; > I expect it's not an easy problem to deal with at this specific place, > but again: if someone solves it, I certainly won't complain :) > >> The documentation advice for advanced users caring about AdvGoalTracking >> could be to use obfuscated [private] bridges and to alternate >> them per travel location. > > Right, I think it's important that people who what more control can > get it this way, and IIRC our current best proposal does not prevent > anyone from doing this. > >> Or perhaps you might be able to explain in tor-launcher / >> anon-connection-wizard [1] [2] [3] the LATEG / AdvGoalTracking issue. > > If the configuration GUI has good facilities to document a broad and > complex problem, yay, bringing the doc closer to the software is > probably a winning strategy. >>> [...] By adding the SSID, we prevent attackers from being able to >>> spoof only the MAC address of the router to reuse a given Tor state; >>> they also have to spoof the SSID which is visible to the user and might >>> be detected as malicious. [...] > >> I find it unlikely, that users might judge an often changing SSID >> malicious. FreeWifi832458252823523 vs FreeWifi358235892435. How many >> users are going to remember that? I would guess, they would just click >> through whatever hoops required to make the WiFi connect again. I'll rephrase this below. > I have no time/energy to think seriouly about it now, and I've been > postponing my reply for a month due to this, so I'll try to be > pragmatic: I'm adding this as a FIXME on our bl
[Tails-dev] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)
sajolida: > https://tails.boum.org/blueprint/persistent_Tor_state/ Persistent Tor state would be a good improvement. Could be the first iteration. It would make Tails less fingerprintable and more secure for people staying in the same location and/or not carding about AdvGoalTracking. But I think location aware Tor entry guards (LATEG) are wrong headed. The topic of LATEG is so difficult to explain to the user, that as you plan, you cannot add it the the UI. Perhaps buried under an advanced setting, but that's not worth so much. So it cannot be manual by default. Only automatic. Which brings me to the issue. There is a reason, why Tor picks a Tor entry guard and sticks to it. By changing it more often than Tor would do, you are subverting the reason for using Tor entry guards in the first place. In a sense, you are to a small degree thereby becoming a Tor developer, and modifying Tor's relay choosing algorithm. I wonder, if the whole LATEG thing would not be much better implemented in Tor itself. If so, then any (further) research of the entry guard topic would still apply to Tails, and not to Tor only. The documentation advice for advanced users caring about AdvGoalTracking could be to use obfuscated [private] bridges and to alternate them per travel location. Or perhaps you might be able to explain in tor-launcher / anon-connection-wizard [1] [2] [3] the LATEG / AdvGoalTracking issue. > [...] By adding the SSID, we prevent attackers from being able to spoof only the MAC address of the router to reuse a given Tor state; they also have to spoof the SSID which is visible to the user and might be detected as malicious. [...] I find it unlikely, that users might judge an often changing SSID malicious. FreeWifi832458252823523 vs FreeWifi358235892435. How many users are going to remember that? I would guess, they would just click through whatever hoops required to make the WiFi connect again. Cheers, Patrick [1] https://github.com/Whonix/anon-connection-wizard [2] https://www.whonix.org/blog/connection-bridge-wizard [3] python rewrite of tor-launcher ___ 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] MAC changer "blend into the crowd" by only using common manufacturer MAC (OUI part) addresses broken by design?
Tails' current implementation... only spoof the NIC part: yes [1] OUI part unchanged: yes [2] quu9ohch [1]: > [...] It is not possible to "blend into the crowd" with a "typical-looking" mac address when so many users allow themselves to be uniquely fingerprinted and tracked. The tradeoff of using a weird (or never manufactured) mac address is like the tradeoff of using tor. It follows from the pigeon hole principle that one cannot hide the fact that they are trying to hide (it is up to other users to hide you), but the best one can do is become statistically exchangeable with the largest possible set of anonymity participants via randomness. [...] [2] An argument of mine... Quote Tails MAC changer design. > [MAC OUI] lists do not take into account that some devices are pretty much only used in some geographical areas I conclude, for someone who traveled far or bought an uncommon notebook, by not changing the OUI part, one could stand out more. Because always that uncommon OUI shows up that is rare in that geographical area. And worse so, the uncommon OUI with an always changed NIC. This would lead to AdvGoalIdMacSpoof, AdvGoalIdTails and AdvGoalTracking. That particular user with that uncommon OUI would be better off with a fully random (OUI part and NIC part) MAC address. It would lead to AdvGoalIdMacSpoof, but not to AdvGoalTracking. In my opinion, the better compromise. Cheers, Patrick [1] https://tails.boum.org/contribute/design/MAC_address/#index13h2 [2] https://tails.boum.org/contribute/design/MAC_address/#index12h2 [3] https://github.com/quu9ohch [4] https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-155679213 ___ 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] Avoiding real MAC address in Tails macchanger being harmful?
Tails does verify, that randomly chosen MAC does not equal the real MAC
by chance.
>From tails-spoof-mac [1] (code: [A])
> # There is a 1/2^24 chance macchanger will randomly pick the real MAC
> # address. We try to making it really unlikely repeating it up to
> # three times. Theoretically speaking this leaks information about the
> # real MAC address at each occasion but actually leaking the real MAC
> # address will be more serious in practice.
quu9ohch [2] [3]:
> P.S. Avoiding the "real" mac address is a bogus approach as well. If
all users were to avoid their real mac addresses all the time then, with
enough data, a local passive adversary could identify each user by
estimating which mac address they never pick. [3]
marmarek:
> If you _randomly_ hit your own MAC address, I think this isn't a
problem at all. Actually changing that behavior may introduce some bias
in that randomness. But if you're talking about some error which results
in not changing the MAC (even if randomly chosen one was different than
original), that's the problem.
Cheers,
Patrick
[1]
https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/usr/local/sbin/tails-spoof-mac
[2] https://github.com/quu9ohch
[3]
https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-155684781
[4]
https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-151239727
[A]
for i in 1 2 3; do
if ! spoof_mac "${NIC}"; then
# If our MAC spoofing primitive fails, we fail safe by forcing
# us to enter into panic mode.
unset NEW_MAC
break
fi
NEW_MAC="$(get_current_mac_of_nic "${NIC}")"
if [ "${OLD_MAC}" != "${NEW_MAC}" ]; then
break
fi
done
___
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] Tails' MAC 'leak prevention' question
I understand Tails' MAC 'leak prevention' [1] [2] as this... Without 'leak prevention', things would happen like this: a) 1) system boots 2) kernel module loaded 3) MAC leaked 4) macchanger started 5) MAC changed 6) NetworkManager started So the MAC leaked even before NetworkManager, before the the interface has been uped, before macchanger may have had a chance to change it. Therefore Tails does as this: b) 1) system boots with kernel modules blacklisted 2) user makes decision [to spoof MAC] 3) MAC changed 4) kernel module loaded 5) NetworkManger started But if there hypothesis was true... They still have a small window between tails-unblock-network, service network-manager start and macchanger. Can the MAC be changed without having the kernel module loaded? - if yes -> great - if no -> then there would be room for MAC leaks like in a), right? Quote Tails Design > It is conceivable that NICs may send packets before the user has made a decision about whether to use MAC spoofing or not. In fact, someone on tails-dev@ alluded [3] to this being possible for wireless NICs although without any references (this may refer to so called "active probing"; see section below). If this is the case it at the very least implies that we must enforce the MAC spoofing setting as early as possible. [...] That does not sound very certain. Just because of being alluded [3] you done quite some effort to not load the kernel modules? Wouldn't it be possible, and simpler, to block all networking with iptables to prevent early MAC leaks so kernel module blacklisting could be avoided? Cheers, Patrick [1] https://tails.boum.org/contribute/design/MAC_address/#index5h1 [2] http://www.webcitation.org/6dJWAQUDz [3] https://mailman.boum.org/pipermail/tails-dev/2013-January/002491.html ___ 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] Tails: Protect against fingerprinting via active Wi-Fi networks probing implemented?
Active probe fingerprinting https://tails.boum.org/contribute/design/MAC_address/#index6h1 says, No - "No protection against this is implemented yet". but https://labs.riseup.net/code/issues/6453 says "yes", 100 % done. Please confirm, which one it is. What happened to https://mailman.boum.org/pipermail/tails-dev/2014-January/004690.html ? If it's implemented, could you link to the implementation please? Cheers, Patrick ___ 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 fails to run inside Qubes OS
intrigeri: > If you really tried Tails 1.6, then I suggest you retry with > a Jessie-based experimental build: > > http://nightly.tails.boum.org/build_Tails_ISO_feature-jessie/lastSuccessful/archive/ Tried. - It's not affected by the X issue. Boots up without `vga=`. - Mouse does not work in Tails greeter (very first screen) (tab key works) - Probably works, but only with keyboard navigation. Which I don't know how to use, since keys like alt + tab are used by the host operating system. Cheers, Patrick ___ 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 fails to run inside Qubes OS
intrigeri:
> It would be good to know what version of Tails you tried, because the
> bug report is self-contradicting ("I've downloaded Tails 1.6.
> Stored in my iso-download (debian-8 based) AppVM").
Really was Tails 1.6.
Austin English:
> I don't think it's self contradicting. debian-8 based describes the
> Qubes VM that the ISO was downloaded in, not a description of which
> Tails version was used.
Right.
Cheers,
Patrick
___
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] redmine watch button broken
u: > Hi Patrick, > > Patrick Schleizer: >> When I go to https://labs.riseup.net/code/issues/5606 and press 'watch', >> it redirects to >> https://labs.riseup.net/code/watchers/watch?object_id=5606&object_type=issue >> and I am getting the following error message. >> >>>> Page not found >>>> >>>> The page you were trying to access doesn't exist or has been removed. >>>> > > I think this happens when you do not have JavaScript enabled. > > Could you confirm? Right. Cheers, Patrick ___ 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] Tails fails to run inside Qubes OS
Hi! For some reason I cannot answer to any Tails redmine tickets. So here is my test report of Tails inside Qubes OS. I've downloaded Tails 1.6. Stored in my iso-download (debian-8 based) AppVM. Then followed the https://www.qubes-os.org/en/doc/hvm-create/ instructions. Initially Tails boots. You can see the Tails boot menu. Whatever you choose, the default option or failsafe, same result. Where it hangs is a black screen only showing `_`. There is a partial workaround. Booted with smaller resolution, `vga=788`. But that workaround still leaves one with an unusable Tails. It boots up until the graphical target just fine. The problem is, that the bottom side of the window reaches below dom0's taskbar. So for example the "ok" button in Tails launcher outside the visible monitor area. Related tickets: Tails: Try running Tails inside of Qubes OS https://labs.riseup.net/code/issues/8607 Qubes: Tails does not boot in Qubes HVM: https://github.com/QubesOS/qubes-issues/issues/1343 Cheers, Patrick ___ 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] redmine watch button broken
Hi! When I go to https://labs.riseup.net/code/issues/5606 and press 'watch', it redirects to https://labs.riseup.net/code/watchers/watch?object_id=5606&object_type=issue and I am getting the following error message. > Page not found > > The page you were trying to access doesn't exist or has been removed. > > Back Previously it has worked for me. User account name: adrelanos Cheers, Patrick ___ 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] entropy mixing: rngd vs haveged
Hi David! Could you follow up intrigeri's questions on this ticket please? https://labs.riseup.net/code/issues/5650 Cheers, Patrick ___ 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] Can TCP Sequence Numbers leak System Clock?
Hi! Is it possible to derive and/or estimate the system clock by observing TCP sequence numbers? Jacob Appelbaum [1]: > In the Linux kernel, TCP Sequence numbers embed the system clock and then hash it. Yet another way to leak the system clock to the network. As I understand the paper 'An Improved Clock-skew Measurement Technique for Revealing Hidden Services' [2] (6/23 = pdf page 3), it implies that TCP sequence numbers can leak the system clock. > Some clocks can be queried remotely: > Clock: TCP sequence numbers > Firewall: Cannot be blocked > Other: Linux specific, very difficult to use Is this the case or does that paper mean something else? On the other hand, I've read the claim "The kernel embeds the system time in microseconds in TCP connections.", but I haven't found the code in question to confirm, that this is so. Any idea? Was also recently raised on Tor's issue tracker. [3] More resources: [4] [5] Cheers, Patrick [1] https://twitter.com/ioerror/status/509159304323416064 [2] http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf [3] https://trac.torproject.org/projects/tor/ticket/16659 [4] http://lxr.free-electrons.com/source/net/ipv4/tcp_ipv4.c [5] http://stackoverflow.com/questions/12231623/initial-sequence-number-generation-in-linux-tcp-stack/12232126#12232126 ___ 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] Announcing control-port-filter-python - a fork of tor-controlport-filter by Tails
Hi! intrigeri: > Patrick Schleizer wrote (09 Mar 2015 01:47:23 GMT) : >> I would like to inform you about the existence of >> control-port-filter-python, a fork of tor-controlport-filter by >> Tails. > > Thanks! Glad you like it! >> * Configurable by dropping .d-style configuration snippets into >> /etc/cpfpy.d. I.e. whitelist can be extended by dropping snippets. > > Looks useful too, for easier code sharing between distros! Yes, that is part of the idea. Another idea is to allow other, optional packages dropping a configuration snippets. For example, if there was a "hidden-services-configurator" or so package, it could just drop a snippet as required. (Similar to /etc/rsyslog.d, where everyone drops what one needs without getting into each others way.) >> * Support to answer 'getinfo net/listeners/socks' with the lie >> '250-net/listeners/socks="127.0.0.1:9150"'. > > The idea is to reply to Torbutton whatever it wants to hear when it > builds about:tor and its green onion icon, right ? Partly, yes. [The other minor one in small font is this "We're keeping it, because it is not necessary for Tor Button get a full list of all ports Tor is listening on. If an attacker compromised Whonix-Workstation, hiding that list has an advantage. The attacker can probe what ports are available to that Whonix-Workstation, but if the user added extra ports not available to the compromised Whonix-Workstation (only available to another Whonix-Workstation listening on another IP), at least those remain secret. (This is a bit theoretical, because a compromised Whonix-Workstation can spoof it's LAN IP and most likely very few users are using ARP spoofing defenses. Should we add ARP spoofing defenses by default at some point, we at least don't have to worry about this point.)"] >> * Honors signals sigterm, sigint. > > Do you mean that Tails' current version ignores such signals? I didn't explicitly test this inside Tails, but I would wonder if Tails' current version supports those. Because this was one of the original limitations, we imported, I think. >> * Complete sysvinit script. > > The great news is that the boilerplate that makes that script 159 > lines long will soon be unnecessary, and be replaced by something a > little bit nicer (to my eye at least), such as: > > https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/lib/systemd/system/tor-controlport-filter.service?h=feature/jessie > > :) Thanks. Systemd support is planned (for whole Whonix). I think forking that file makes sense as well. Are maintainers expected, Debian policy, convention or otherwise to remove sysvinit scripts from packages once they have a systemd unit and are ready to jessie? Or to keep those? I don't mind either way. > * The amount of global variables usage is troubling. * Some exception > catching feels a bit too wide. * The list of "if line.startswith" > that follows "for line in c" wants to be replaced by a dispatch table > or something more readable. troubadour might work on these. See: https://phabricator.whonix.org/T243 >> * Supports logging. > > It feels strange to me to add direct log files handling (as opposed > to using the syslog interface or the native systemd journal's one) > to a system-wide daemon in 2015: that's one more log file that won't > be aggregated in the systemd journal, so one has to look in one more > place when trying to debug something. Anyway, that's probably a > matter of taste :) > > The good news is that the logging module supports syslog, so it > seems easy enough to adjust according to one's taste. Perhaps that > could be supported with a command-line option? (I guess the answer > will be "patches welcome" -- fair enough :) The answer is not yet "patches welcome". troubadour's comment was: > About logging, would it be an advantage to use syslog or systemd journal instead of a dedicated log file? For debugging, it seems better to keep it separate. I don't have a strong opinion either way. Well, having a "just show me only control-port-filter-python log entries" command seems important, but that will most likely be possible either way? Having a separate file also seems simple and useful or is that not hip anymore nowadays? Not required, once is accustomed to enter the required systemd command to show only the log one wants to see? What [python] lib / function / way would be a standard, policy, and whatnot conform, good one for logging? What's the usual way to do that nowadays? Cheers, Patrick ___ 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] Announcing control-port-filter-python - a fork of tor-controlport-filter by Tails
Dear Tails developers, I would like to inform you about the existence of control-port-filter-python, a fork of tor-controlport-filter by Tails. Improvements: * Supports parallel connections. * Configurable by dropping .d-style configuration snippets into /etc/cpfpy.d. I.e. whitelist can be extended by dropping snippets. * Supports logging. * Support to answer 'getinfo net/listeners/socks' with the lie '250-net/listeners/socks="127.0.0.1:9150"'. * Honors signals sigterm, sigint. * Complete sysvinit script. * Lintian clean /debian packaging folder. Code: https://github.com/Whonix/control-port-filter-python Main script: https://github.com/Whonix/control-port-filter-python/blob/master/usr/lib/control-port-filter-python/cpfp.py Wiki page: https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy It has been mostly written by troubadoour with some reviewing and testing by me. We would like to hear your feedback, comments, etc. A comparison of the three Tor ControlPort filters that exist so far can be found here: https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy#Comparison_of_Control_Port_Filters Thank you for writing tor-controlport-filter! Cheers, Patrick ___ 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] keeping up with pluggable transports by using TBB's Tor and tor-launcher
Hi! intrigeri wrote: > Hi, > > Patrick Schleizer wrote (21 Nov 2014 15:17:08 GMT) : >> intrigeri wrote: >>> Patrick Schleizer wrote (15 Nov 2014 15:38:09 GMT) : >>> Unless I'm mistaken, the server-side of these PTs needs to be in >>> Debian anyway, so that people running Debian-based distros can >>> actually provide bridges supporting these PTs. And then, while one is >>> at it, I suspect that maintaining and packaging the client-side while >>> one is at it doesn't involve much more effort. So, I'm not convinced >>> by this specific argument. > >> Maybe we're having different things in mind here. For meek bridges, >> there is a google and an amazon one. I guess most users just happily use >> those. Or is anyone eager to host a meek bridge? Maybe I am mistaken. >> It's also not an important point. Having meek's server component in >> Debian surely would be a nice to have. But in that particular case, I >> think it's not that important. Unless I'm mistaken. > > Sure, for meek we don't really need the server side component to be in > Debian. But I believe my point still holds in general. > >>>> This requires tor-launcher having a features such as: >>> >>> I'm afraid I don't understand why we would need any such changes >>> for Tails. May you please clarify? > >> I try to reword/elaborate a bit. > >> General idea: trying to modify/use tor-launcher so it works more like >> Vidalia (a Tor config/start/stop utility). > > Well, that's already more or less how we're using it in Tails: we're > using Tor Launcher as a standalone application, not as part of the Tor > Browser. We don't use it to start/stop Tor, but we use it to configure > it whenever the user chose so in the Greeter. That is probably the main difference. Using it as standalone application by only using tor-launcher vs using tor-launcher from an original TBB tarball / folder. I'll elaborate below. >> - Just start Tor Browser without configuring Tor (we already got that >> TOR_SKIP_LAUNCH). -> It's useful so you can boot with a usual desktop. >> Not autostarting a browser. And when the user wants to start the >> browser, you use that (without starting tor-launcher or Tor). > > That's what we're doing in Tails already. > >> - Just start Tor with current configuration (missing feature?) -> For >> users who choose "no network obstacles", Tails would just run TBB's Tor >> as the new "system Tor". > > We already have this behaviour, so why would we need Tor Launcher to > do that? For non-bridge users the advantage would be arguable: using the version of Tor that comes with TBB rather than the version of Tor that comes with Debian. If I remember right, there was a time where TBB's version of Tor (and deb.torproject.org's version) included a new feature that helped to cope up with the issues causes by that huge botnet that abused Tor. >> - Configure Tor (using tor-launcher), but don't >> start Tor or Tor Browser (missing feature?). -> For users who choose >> "got obstacles", Tails would start the tor-launcher add-on to let them >> configure Tor. Then Tails would use the "just start Tor with current >> configuration" feature. And if the user notices it doesn't work, go back >> to this one. > > I don't understand what problem this solution is trying to solve. Glad you're asking! Thanks so much for not just quickly dismissing this! Somehow I failed to explain the general idea well. Need to work on that. Tails current implementation differs from what I am having in mind here. - Currently: You are using /usr/bin/tor-launcher and ~/.tor-launcher. Somehow extract tor-launcher from TBB or its repo during build time? - Alternative: Simpler implementation (from Tails side - probably requires tor-launcher patches) + patching tor-launcher. Using a regular Tor Browser Bundle tarball, extracted to /home/user/tor-browser_en-US/ or saner location. - Currently: You are using the Debian "tor" package. The "real" system Tor. - Alternative: Use /home/user/tor-browser_en-US/Browser/TorBrowser/Tor/ as "fake system Tor". Advantage... When you use that folder, you ship the same pluggable transports as TBB. - Currently: When choosing "no extra settings" in Tails Greeter, the user cannot change its mind and try different settings. At least as far as I know. I haven't found tor-launcher / Tor settings start menu / on desktop. And if the user types (/usr/bin/)tor-launcher in terminal, it will show an error message. - Alternative: The user cou
Re: [Tails-dev] keeping up with pluggable transports by using TBB's Tor and tor-launcher
Hi! intrigeri wrote: > Hi, > > Patrick Schleizer wrote (15 Nov 2014 15:38:09 GMT) : >> Idea: > >> - Come with a recent release of original TBB from TPO installed by >> default with every new release of Tails/Whonix. > >> - Use the TBB, tor-launcher add-on and pluggable transports from TBB as >> the new "system Tor". > > Indeed, this would allow us to stay on top of things, and probably > make the UX clearer, since we would support just the same set of PTs > as Tor Browser supports. I must say it's quite tempting. Glad you like it! > OTOH, given the amount of complicated stuff we already need to get the > Tor Browser itself properly integrated in Tails, I'm not too thrilled > at the idea of seeing more and more kludges added to do the same for > PTs... but maybe an actual implementation wouldn't be that scary, and > my fear would be proved to be irrational. >> Seems like an approach that needs low maintenance from distribution >> developers (Debian/Tails/Whonix) as well as from tor-launcher/TBB >> developers? Needs no extraction of stuff like meek, flashproxy, >> scramblesuit for packaging (policy conform) for Debian. > > Unless I'm mistaken, the server-side of these PTs needs to be in > Debian anyway, so that people running Debian-based distros can > actually provide bridges supporting these PTs. And then, while one is > at it, I suspect that maintaining and packaging the client-side while > one is at it doesn't involve much more effort. So, I'm not convinced > by this specific argument. Maybe we're having different things in mind here. For meek bridges, there is a google and an amazon one. I guess most users just happily use those. Or is anyone eager to host a meek bridge? Maybe I am mistaken. It's also not an important point. Having meek's server component in Debian surely would be a nice to have. But in that particular case, I think it's not that important. Unless I'm mistaken. >> This requires tor-launcher having a features such as: > > I'm afraid I don't understand why we would need any such changes > for Tails. May you please clarify? I try to reword/elaborate a bit. General idea: trying to modify/use tor-launcher so it works more like Vidalia (a Tor config/start/stop utility). - Just start Tor Browser without configuring Tor (we already got that TOR_SKIP_LAUNCH). -> It's useful so you can boot with a usual desktop. Not autostarting a browser. And when the user wants to start the browser, you use that (without starting tor-launcher or Tor). - Just start Tor with current configuration (missing feature?) -> For users who choose "no network obstacles", Tails would just run TBB's Tor as the new "system Tor". - Configure Tor (using tor-launcher), but don't start Tor or Tor Browser (missing feature?). -> For users who choose "got obstacles", Tails would start the tor-launcher add-on to let them configure Tor. Then Tails would use the "just start Tor with current configuration" feature. And if the user notices it doesn't work, go back to this one. - anything else? I don't know Tails / tor-launcher specifics good enough. Maybe you have a better idea how to implement it best? Perhaps it would be best to design tor-launcher in a way, so it would for plain Debian users? Because if that works, it should work for Tails/Whonix users as well. Cheers, Patrick ___ 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 htpdate - why use time information from neutral and foe pools?
intrigeri wrote: >> I can't think of another area in which asking a hostile for advice is a >> good idea. Maybe "if friend and foe both agree, you can be confident >> that they're right; if they disagree, look further" - but that's not >> what Tails htpdate is doing. > > Indeed, it should probably discard information that is diverging too > much from what others tell us. Care to file a "research" ticket > about it? https://labs.riseup.net/code/issues/8283 ___ 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] keeping up with pluggable transports by using TBB's Tor and tor-launcher
Hi! intrigeri wrote: > [...] > Still, the landscape of pluggable transports is quickly evolving, and > indeed we have a hard time staying on top of things in this area. > [...] I think it will be simply impossible to keep up with pluggable transports. We at Whonix are facing the same issue. Idea: - Come with a recent release of original TBB from TPO installed by default with every new release of Tails/Whonix. - Use the TBB, tor-launcher add-on and pluggable transports from TBB as the new "system Tor". Seems like an approach that needs low maintenance from distribution developers (Debian/Tails/Whonix) as well as from tor-launcher/TBB developers? Needs no extraction of stuff like meek, flashproxy, scramblesuit for packaging (policy conform) for Debian. This requires tor-launcher having a features such as: - just start Tor Browser without configuring Tor (we already got that TOR_SKIP_LAUNCH) - just start Tor with current configuration (missing feature?) - configure Tor (using tor-launcher), then just start Tor, but don't start Tor Browser (missing feature?) - anything else? What do you think? Cheers, Patrick ___ 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] State of TAILS accessibility with Orca; Tor totally works within Iran using Pluggable transports (ScrambleSuit)
Hi, Le 04/11/2014 00:18, Hadi Rezaee a écrit : > Would i be able to select obfs3 for my tor connection if i skip the > greeter? No, sorry. It seems only the greeter allows that. In fact, it's possible to launch Orca without a sighted person only if we don't need the greeter. Regards. -- Patrick ZAJDA Skype: gansta93 ___ 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] State of TAILS accessibility with Orca; Tor totally works within Iran using Pluggable transports (ScrambleSuit)
Hi, Le 01/11/2014 23:42, Hadi Rezaee a écrit : > What do you think, Should i download both of them, and with a help of > a sighted person launch Orca and test both of them? You can boot on the Tails device, press enter after some second to close the greeter because no solution to launch Orca from it, wait some second, press alt+f2, wait for one or two seconds than type orca then press enter. By this way, I can launch Orca to use Tails. Sure it is approximative, but no sighted person required. [A little bit off topic @intrigeri] During Tails hackfest, I said Orca was not launched on login screen. It was a mistake from me, it works well. This topic remind it to me. [/off topic] Regards, -- Patrick ZAJDA Skype: gansta93 ___ 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] git (submodule) security
boyska wrote:> On Sat, Nov 01, 2014 at 08:07:04AM +0000, Patrick Schleizer wrote: >> By chance I found https://github.com/boyska/git-verify repo. > > hey, that's me :P That's why I explicitly added you to cc. :) >> At Whonix we're currently discussing various aspects of git security. >> Especially since git still uses SHA-1 and if git (submodule) >> verification is safe against adversaries, that can produce SHA-1 >> collisions. > > Seems a really good point, but... can't you just recursively run > git-verify? Not sure if required or a solution. As I understand - using git submodules or not - git verify also is only a gpg verification of a SHA-1 hash. ___ 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] git (submodule) security
Hi! By chance I found https://github.com/boyska/git-verify repo. At Whonix we're currently discussing various aspects of git security. Especially since git still uses SHA-1 and if git (submodule) verification is safe against adversaries, that can produce SHA-1 collisions. I was wondering, if you might be interested to join the discussion? [1] Cheers, Patrick [1] https://www.whonix.org/forum/index.php/topic,538.0.html ___ 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] TCP Sequence Numbers leak System Clock
Hi, you might be interested in this: https://twitter.com/ioerror/status/509159304323416064 Why could it be relevant? Tor Browser (and other applications?) leak the system clock in default settings [1]. At the same time, the system clock leaks to ISP level observers through TCP sequence numbers. This opens up to "quite simple" end-to-end correlation attacks, I think. Cheers, Patrick [1] https://trac.torproject.org/projects/tor/ticket/3059 ___ 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] merging 7508 [was: Re: Contributing to Tails's website]
Hi, I am on vacations unteal the end of the next week. Then I'll care about merging these modifications to Ikiwiki. Cheers, Patrick Message d'origine De : intrigeri Envoyé: 9 septembre 2014 21:15:03 CEST À : The Tails public development discussion list Objet : Re: [Tails-dev] merging 7508 [was: Re: Contributing to Tails's website] sajol...@pimienta.org wrote (02 Sep 2014 17:55:53 GMT) : > I don't know much about the ikiwiki upstream but apparently this is done > through ikiwiki itself: http://ikiwiki.info/patch/ Right. Patrick, if you need hints about upstreaming this, please let me know. I've been contributing to ikiwiki a lot in the past, so I might be of some help. 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. -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ 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] I2P & Tails 1.2 (0.9.15, browser, network-manager)
>> I2P-browser >> === > >> I got a bit of work done for the separate browser for use with I2P, >> based upon the unsafe-browser script. I haven't pushed it anywhere yet, >> but will do once I do a bit more testing with it. (ticket #7725) > > Great! Note that this code probably depends on what browser we happen > to ship in Tails 1.2. There are chances that we ship something based > on the TBB tarball, so some paths etc. will likely need to be adapted. Glad to hear you are working on this! Wondering, wouldn't it anonymity wise be a good idea to also use (a separate) Tor Browser for browsing i2p? ___ 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] meek debian packaging brainstorming
Hi, as you may already know, meek [1] is a pluggable transport. Quite a convenient one for TBB users. They don't even have to obtain bridges and it just works out of the box. I've recently posted a feature request for packaging it for Debian. [2] Unfortunately it won't be that simple because it is coupled with Tor Browser. Eventually you have some ideas how that could be done. Off-topic: Do you appreciate/mind "here check out that trac ticket it may interest you" mails or is this unnecessary noise because you have a mechanism to stay posted? Cheers, Patrick [1] https://trac.torproject.org/projects/tor/wiki/doc/meek [2] https://trac.torproject.org/projects/tor/ticket/13160 ___ 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] [Freepto] (senza oggetto)
Hi! u: > I'd be glad to help with some packaging. Cool! Please also look through the one or two lines package summaries. Then we may discuss packages that are of interest to you. :) > Some of the stuff i see in that list could probably be integrated into > existing packages (AppArmor profiles) troubadoour [1], who maintains the AppArmor profiles, might work on upstreaming the AppAmror profiles. Might take a while though. [2] > or possibly upstream > (modifications to Pidgin)? Upstreaming pidgin-improved-privacy specially, would require lots of more skill and effort than the current workaround using debian packaging. Perhaps scurl and curl-scripts could be realistically upstreamed. Generally, besides the ones mentioned (apparmor, pidgin-improved-privacy, scurl, curl-scripts), I wouldn't know what to upstream. Cheers, Patrick [1] https://github.com/troubadoour [2] https://github.com/micahflee/torbrowser-launcher/issues/124 ___ 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] [Freepto] (senza oggetto)
Hi! intrigeri: > [sorry for the late reply. any reason to drop most addresses from the > Cc list?] Sorry, mistake. > Patrick Schleizer wrote (03 Jul 2014 14:55:57 GMT) : >> I am currently working on splitting Whonix into multiple packages. >> Having ability to be used by other privacy distributions on general >> Libre Software users in mind. > >> I hope that a lot of functionality can and eventually will be used by >> other privacy and/or general distributions. > >> Have a look at what packages/functionality is provided: >> https://github.com/Whonix > >> (~6 pages; ~100 packages) > > Thanks! Wow, that's a *lot* of stuff. I've no idea where to start > looking at. Understandably it could seem overwhelming. ~6 pages; ~100 packages sounds a lot... But... Maybe start at https://github.com/Whonix. Just have a quick look at the short package descriptions. Those are just one or two lines. No need to read the full package description at that point. The two line summary should be quite concise. You could see something like this: > swap-file-creator > > Adds encrypted swap file to the system - for better protection of locally stored data and to aid environments with low RAM. Or: > bootclockrandomization > > Randomizes clock when systems boots by adding a few seconds and nanoseconds to enforce the design goal, that the host clock and Gateway/Workstation clock should always slightly differ (even before secure timesync succeeded!) to prevent time based fingerprinting / linkablity issues. For better anonymity and privacy. Etc. Then see what catches your interest, maybe one or another package. > Any hint wrt. what could possibly be closer to be reusable > in (and useful for) e.g. Tails, Re-usable for Tails should be much simpler than uploadable to Debian. Even if a package would only contain a single config file, which was useful for Tails, it could be re-used in Tails. While Debian ftp masters might reject the package. (No complaint here - maybe rightly so - I haven't walked in their shoes.) Here are some packages that may be useful and easily re-usable for Tails. - tor-ctrl [perhaps rather boring, but I need it for a newnym tool] - timezone-utc - tcp-timestamps-disable - timesanitycheck - shared-folder-help - scurl - pkg-manager-no-autoupdate - ipv4-forward-disable - poweroff-passwordless - damngpl [ _maybe_ useful for https://labs.riseup.net/code/issues/5548 ] - bootclockrandomization - ipv6-disable - curl-scripts - power-savings-disable-in-vms - anon-icon-pack - pkg-manager-longer-timeouts - various kde-[...] packages, but that is more hyptotehtically, perhaps for Tails custom builds of if Tails some day comes with an alternative KDE desktop, you could set many settings by using the kde-[...] settings packages https://github.com/Whonix?query=kde- > or would be ready in your opinion to > be uploaded to Debian? Since packages that contain only config files or worse, only a single config file are not allowed, this will be much fewer. The packages usually have no lintian warnings. But I don't know what an actual DD will say. I really don't know. Maybe bootclockrandomization if it's not too small. >> Help with getting packaging ready to be acceptable for Debian [etc.], >> mentoring, finding Debian maintainer, etc. is welcome! > > I can maybe help finding sponsors. I already have enough mentoring and > package maintenance on my plate, though. Very nice. Maybe let's start with a really simple package to get me bootstrapped. That I will polish for Debian derivatives or even Debian itself. The bootclockrandomization package is kinda simple. Should I port to systemd first? Maybe bootclockrandomization interests you. Or any other package that catches your interest. Cheers, Patrick ___ 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] Tails htpdate - why use time information from neutral and foe pools?
Hi! I've got a question for Tails' design regarding to HTP source pools [1]. > [...] The HTP pools used by Tails are based on stable and reliable webservers that get great amounts of traffic. They are categorized into three different pools according to their members' relationship to the members in the other pools; any member in a one pool should be unlikely to share logs (or other identifying data), or to agree to send fake time information, with a member from the the other pools. The pools are as follows: > - The "pal" pool are run by groups that are likely to take great care of their visitors' privacy. > - The "foe" pool are managed by adversaries of the "pal" pool. > - The "neutral" pool members have a neutral raltionship to both the "pal" and "foe" pool. [...] Even if they don't agree to send fake time information, I don't understand why connecting to a foe/hostile server and using their time information is any useful. Why would you for example trust nsa.gov to share legit time information? If you assume the time information by nsa.gov might be malicious in any way in your opinion, and you'd probably express that opinion by adding the to the foe pool, why bother asking them? How can their time opinion be any useful for getting a good time guess? I can't think of another area in which asking a hostile for advice is a good idea. Maybe "if friend and foe both agree, you can be confident that they're right; if they disagree, look further" - but that's not what Tails htpdate is doing. Or asked the other way around: How much worse would you be off if basically, Tails htpdate would pick three random servers from the pal pool, and then build the mediate of the three advertised dates. Cheers, Patrick [1] https://tails.boum.org/contribute/design/Time_syncing/ ___ 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] [Freepto] Let's share username, /etc/hostname and /etc/host among all anonymity distributions
Hi! sajol...@pimienta.org: > Note that in the case of Tails, we recommend our users against doing > this. Which is mix different identities in a same working session: > > https://tails.boum.org/doc/about/warning/#index8h1 Whonix has a similar warning: https://www.whonix.org/wiki/Warning#Whonix_doesn.27t_magically_separate_your_different_contextual_identities > If you don't take care about this yourself, there are probably other > ways that you can fuck it up (through the browser, the Tor config, etc.). > But still, I totally understand your point and I'm wondering whether the > same assumption "not mixing identities" apply to all the distros that we > are talking about. For example to Whonix? Applies to Whonix as well. > And also, it's not because we recommend our users against doing > something that we should take for granted that they will handle their > contextual identities in perfect way (given this can be a really > subjective topic). And we should still try our best to limit the > consequences in case they do mix them or simply commit a mistake. That's the thing. Realistically only a small fraction of users reads, remembers and really applies what is recommended in documentation. Murphy's law also agrees. So the best way is to work towards solutions that assume, that the user didn't apply that advice. Having that said and after thinking about Tobias Frei's reasoning, I am now more convinced that shared values should be preferred over random values. Cheers, Patrick ___ 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] Contributing to Tails's website
[...] Le 19/08/2014 12:38, BitingBird a écrit : > Concerning ticket #7508 i suppose you will need to edit > wiki/src/templates/page.tmpl. > > That means editing a template which is more or less shipped by ikiwiki > as is. There is another ticket #7027 which might be related to this > intervention. > > I have looked into the issue before and saw that our templates are still > pretty close to the upstream version. But you might want to check this > out before working on #7508. > > It would be great to upstream the changes to ikiwiki once they look > good, so that other ikiwiki site become accessible too :) > OK, so I can edit the template to add HTML landmarks? If so I'll care of #7508 now. Thanks, -- Patrick ZAJDA Skype: gansta93 ___ 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] Contributing to Tails's website
Hi u, Le 19/08/2014 11:05, u a écrit : > I am wondering: if i edit the email and cut some parts of the > conversation, will this still be easily readable or interpretable by a > braille reader? > > For now, i will just leave everything intact and answer inline until you > tell me how to do it the best way. > It's OK for me, in fact it will be easier to read if there are only useful informations. I haven't removed anything because I don't know what is better between keeping all the content to have all the history in the message or to keep only what is relevant to the answer. And sometimes I have problems to delete large portion of text. > Patrick ZAJDA: >> Hi, >> >> >> Le 18/08/2014 22:06, u a écrit : >>> Hi, >>> >>>> Hi all, >>>> >>>> I want to contribute to the Tails website code. >>> Great! Welcome on board. >>> >> Thank you. >>>> I read everything about contributing to Tails I found on tails website >>>> contributors pages. >>>> But I didn't find a lot of things about contributing to the website >>>> (design or code). >>> At the moment we are in the process of thinking what exactly we will do >>> to restructure and redesign our website. There have been some >>> discussions at the Tails HackFest. We did not agree on anything in >>> particular yet though. >>> >>> We have created a blueprint [0] about the website structure. Different >>> people made different drafts about how we could reorganize the website. >>> >>> The discussion about these issues should take place on the tails-ux >>> mailinglist [1]. I say "should" because in practice we have had little >>> time recently to discuss more on the proposals. But we are keen to get >>> more input on these ideas. >>> >>> Furthermore you can find tickets related to the website on our >>> bugtracker [2][3]. Tickets which do not yet have an assignee can be >>> taken by you, if interested. >>> >>> Please tell us what kind of work you would be interested in in >>> particular (design, code, documentation, reorganizing, something else?) >>> Are you familiar with ikiwiki, CSS, markdown, anything else or do you >>> need guidance? Please don't hesitate to ask. >>> >>> Sajolida is the one here who knows the website best and who can give you >>> more information, or tasks. >>> >> OK, in fact for the moment I'd like to begin with some accessibility >> related tickets : #7508 and #7506 >> If all is OK after that I'll think about harder tasks :) > That is great. > > You can set yourself as an assignee on these two tasks on > https://labs.riseup.net/code/issues/7506 > and https://labs.riseup.net/code/issues/7508 > So we know that somebody is working on them. > OK, done now. > Concerning ticket #7508 i suppose you will need to edit > wiki/src/templates/page.tmpl. > Yes, that's the solution I though. > That means editing a template which is more or less shipped by ikiwiki > as is. There is another ticket #7027 which might be related to this > intervention. > > I have looked into the issue before and saw that our templates are still > pretty close to the upstream version. But you might want to check this > out before working on #7508. > OK, I'm going to read it, thanks. > For the other ticket, i think you might need to edit a lot of different > pages. (I'll let sajolida confirm this, as i am not 100% sure of what > has been said already on the subject.) In fact I though I could edit the template, because it is the main thing for all pages. But I'll check again what pages should be edited to add this level 1 header,. >> I have a little experience with markdown, I prefer avoiding CSS because >> I'm blind so difficult to check my work before submitting but HTML is >> not really a problem. >>>> What branch should my work be based on? >>> We tend to create a new branch based on master for every modification. >>> >> OK, thanks. > Do you need any help with this in particular or did you manage to > checkout the repository already? I forked on repo.or.cz and cloned it. Thanks >>> You will also need to be able to build the wiki locally in order to >>> verify your modifications before asking for review. [4] >>> >>>> Thanks, >>> If you are available on september 3rd, please do not hesitate to >>> participate in the contributor meeting on IRC too. This might be easier >>> to sort some things out. >> OK, I'll try t
Re: [Tails-dev] Contributing to Tails's website
Hi, Le 18/08/2014 22:06, u a écrit : > Hi, > >> Hi all, >> >> I want to contribute to the Tails website code. > Great! Welcome on board. > Thank you. >> I read everything about contributing to Tails I found on tails website >> contributors pages. >> But I didn't find a lot of things about contributing to the website >> (design or code). > At the moment we are in the process of thinking what exactly we will do > to restructure and redesign our website. There have been some > discussions at the Tails HackFest. We did not agree on anything in > particular yet though. > > We have created a blueprint [0] about the website structure. Different > people made different drafts about how we could reorganize the website. > > The discussion about these issues should take place on the tails-ux > mailinglist [1]. I say "should" because in practice we have had little > time recently to discuss more on the proposals. But we are keen to get > more input on these ideas. > > Furthermore you can find tickets related to the website on our > bugtracker [2][3]. Tickets which do not yet have an assignee can be > taken by you, if interested. > > Please tell us what kind of work you would be interested in in > particular (design, code, documentation, reorganizing, something else?) > Are you familiar with ikiwiki, CSS, markdown, anything else or do you > need guidance? Please don't hesitate to ask. > > Sajolida is the one here who knows the website best and who can give you > more information, or tasks. > OK, in fact for the moment I'd like to begin with some accessibility related tickets : #7508 and #7506 If all is OK after that I'll think about harder tasks :) I have a little experience with markdown, I prefer avoiding CSS because I'm blind so difficult to check my work before submitting but HTML is not really a problem. >> What branch should my work be based on? > We tend to create a new branch based on master for every modification. > OK, thanks. > You will also need to be able to build the wiki locally in order to > verify your modifications before asking for review. [4] > >> Thanks, > If you are available on september 3rd, please do not hesitate to > participate in the contributor meeting on IRC too. This might be easier > to sort some things out. OK, I'll try to be here. > Cheers, > u. > > [0] https://mailman.boum.org/pipermail/tails-ux/2014-July/28.html > [1] https://mailman.boum.org/listinfo/tails-ux > [2] https://labs.riseup.net/code/projects/tails/issues?query_id=115 > [3] https://labs.riseup.net/code/issues/7627 > [4] https://tails.boum.org/contribute/build/website/ > Thank you for your answer, -- Patrick ZAJDA Skype: gansta93 ___ 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] Why OnionCat + Mumble - why not just Mumble?
ban...@openmailbox.org: > Here is what Bernhard says about authentication: > https://www.whonix.org/w/index.php?title=OnionCat&stable=0&shownotice=1&fromsection=Security#Security Alternative links: - https://www.whonix.org/wiki/OnionCat#Security - http://www.webcitation.org/6Rv71smMB ___ 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] Contributing to Tails's website
Hi all, I want to contribute to the Tails website code. I read everything about contributing to Tails I found on tails website contributors pages. But I didn't find a lot of things about contributing to the website (design or code). What branch should my work be based on? Thanks, -- Patrick ZAJDA Skype: gansta93 ___ 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] [Freepto] Let's share username, /etc/hostname and /etc/host among all anonymity distributions
Hi! intrigeri: > I'm coming back on the shared username/hostname thing, that was > rediscussed a bit lately, with input from Freepto and pointers to > Subgraph OS code, on a Tails ticket: > > https://labs.riseup.net/code/issues/5655 > > As you can see in my comment #6 there, it's unclear to me what's best, > between sharing fixed values and randomizing it. Each solution has > pros and cons. What do you think? It is indeed a hard decision. Let's think again of examples where this might happen. And then determine with which strategy users would be better off in which case. - ssh uses for login if not explicitly told otherwise -> server knows you're a Tor user anyway -> better off with shared value - (as part of the path) is sometimes encoded into user created content (images, firefox screenshot addon). Maybe only in user installed extra packages. -> when you upload them, server knows you're a Tor user anyway -> better off with shared value -> when you send the file to a third party (a journalist or so) who "hides" the users use of Tor -> you might prefer a random value over a shared one? - mixmaster (postfix) leaks . to the mailserver. -> server knows you're a Tor user anyway -> better off with shared value - IRC clients not (pre)configured for privacy leak ident = username -> server knows you're a Tor user anyway -> better off with shared value - Please don't nail me for other examples. These are just a few I observed. Having these cases in mind, I slightly prefer shared value. Cheers, Patrick ___ 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] Why OnionCat + Mumble - why not just Mumble?
Hi, thank you for your interest! By the way this has now been documented in Whonix's wiki as user friendly as I could make it for now: https://www.whonix.org/wiki/Voip#linphone Just now tested by me. One machine had speaker off and microphone on, the other one vice versa. Could hear myself. There was a 1 or 2 s delay, but that shouldn't annoy one much. I yet have to test this setup with an actual calling partner. Maybe Jason will test it with me, but we yet have to find a time when we're both online due to different time zones. So if anyone does not mind revealing its voice to me and interested in testing, please get in contact. This linphone setup currently talks Tor hidden service to Tor hidden service. I am wondering how much delay and perhaps quality loss this will produce compared to alternative setups. I am still curious to see setups with just one hidden service as server and a client as well as setups using third party clearnet servers. The latter would have to include, that the server can long nothing useful, just notice, that two random pseudonyms have an encrypted voice chat. ban...@openmailbox.org: > On 2014-08-14 23:26, ban...@openmailbox.org wrote: >> Hi. I found out why onioncat wasn't working and configured it >> accordingly with help from Bernhard. It was a peculiarity that had to >> do with our specific two machine design. >> >> Now VOIP works. Linphone is what we'll be using. Thought I'd tell you >> so you guys can add that too. >> >> Details: >> https://www.whonix.org/forum/index.php/topic,407.msg3360.html#msg3360 > > Unfortunately the Linphone version in Debian stable does not have zrtp > support. But wouldn't Hidden Services and onioncat be providing the > authentication layer? > > Note that Linphone does have a text messaging mode but its completely > plaintext. Again it shouldn't matter if what I'm saying about Hidden > Services is correct. Since we're using Voip over onioncat over Tor hidden services, all that ZRTP would give us would be a second layer of encryption and authentication, so I think this assertion is correct. But, if it comes available, why not use it. Cheers, Patrick ___ 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] Why OnionCat + Mumble - why not just Mumble?
intrigeri: > Patrick Schleizer wrote (05 Aug 2014 02:04:30 GMT) : >> Mumble has a TCP mode. Why involve QnionCat? > > Without involving Tor Hidden Services, Well, with OnionCat you must involve Tor Hidden Services as well? > how do you initiate > a peer-to-peer conversation between two Tails users using Mumble? > > In other words: which Mumble server do you use, and how much do you > need to trust it? I would assume, that documentation would say, that one of the two Tails user must bite the bullet and set up a Tor Hidden Service Murmur server. Maybe I am missing something here. Would OnionCat improve usability and ease the process? One must run Murmur so or so? Or does Mumble have a mode for serverless peer-to-peer connections? Cheers, Patrick ___ 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] Why OnionCat + Mumble - why not just Mumble?
Hi! Quote https://tails.boum.org/blueprint/VoIP_support/ : > Preliminary testing showed OnionCat + Mumble to be a working and relatively easy to setup Tor-enabled VoIP solution; the 1/2s - 1s delay is only slightly annoying. Why OnionCat + Mumble - why not just Mumble? Mumble has a TCP mode. Why involve QnionCat? Cheers, Patrick ___ 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] How to seed urandom (or not)?
David Goulet: > Their big issue is the Ubuntu Cloud Image for which they rely on > https://launchpad.net/pollinate, TL;DR; it fetches random bytes over > HTTPS to seed /dev/random. (They do pin the certificate in the client > which is less crazy :). > > See: > http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html > > To be honest, I don't have a good way of fixing this issue. Feeding the > urandom-seed with the date might be better than nothing but again I > think that if a NTP correction occurs before seeding it, an attacker > could end up knowing the seed if the NTP server or the link is > malicious. > > Is it crazy to think that Tails could provide a "seeding server" and use > pollinate? I found an interesting comment about pollinate. [1] > Sooo, let me get this right. Your VM has no good random seed to start from. To deal with that you make an HTTPS request to some server on the internet. That HTTPS connection requires a session key, which you have to generate from your random source that, well..., is not well-seeded at that point. Hence all the encryption of that seed is pretty much pointless. Discussion is also interesting. [1] What do you think? Is the https session key argument a good one against pollinate? [1] https://plus.google.com/wm/1/+LennartPoetteringTheOneAndOnly/posts/K22yyHRc6hn Cheers, Patrick ___ 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] How to seed urandom (or not)?
coderman: > tls-tor-random to torproject What do you mean by that? ___ 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] How to seed urandom (or not)?
intrigeri: > 2. drop the publicly known value => urandom is seeded by date +%s.%N >only If you are going that route, would it make sense to drop the dot in date +%s%N as well to remove another publicly known value? ___ 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.2] feature/6579-disable-tcp-timestamps [Was: Risks of enabled/disabled TCP timestamps?]
Hi, I haven't found the commit where you actually added /etc/sysctl.d/tcp_timestamps.conf. Does this implementation involve anything besides /etc/sysctl.d/tcp_timestamps.conf? http://www.tmltechnologies.com/html-2012/index.php/linux-rescue-kits/82-secret/91-disable-tcp-timestamps-on-linux recommends: > To be on the safe side, add the following 2 lines to your firewall script: > iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP > iptables -A OUTPUT -p icmp --icmp-type timestamp-reply -j DROP What do you think? Cheers, Patrick ___ 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 and merge] filename problem
Hi, I Am on Windows 7 64-bits and I would like to contribute to #7506 and #7508 but I have this error too when cloning the repo. Creating a virtual machine is a solution, but it would be better if Windows contributors could clone the repo. Regards, Patrick Le 16/07/2014 15:53, DP Tor-Contact a écrit : I am using a Windows Vista 32-bit machine. (yeah pretty awful but I'm at work) I have tried to cole the repo again, it showed the same mistake. I also saw that there are some more filenames with colons. Is there a contributer-base of Windows users? If not we should leave it in that way, I can switch to a virtual machine with Debian. And the documentation should be updated regarding to that. Regards spriver Am 2014-07-16 14:53, schrieb u: intrigeri: u wrote (16 Jul 2014 11:28:59 GMT) : as seen on tails-l10n, there is a folder in the wiki which contains a colon. This results in problems on Windows systems, where contributors might want to translate.. but can't checkout this folder. Can one build the website (with ikiwiki) on Windows? (I'm fine with adding constraints on filenames if it *really* allows people to do their translation work on Windows. If it's removing one stumbling block only to then unhide the next one, I'm not sure it's worth it.) you are absolutely right. Let's ask the person first. Eventually, we should then also update the documentation accordingly. cheers u. ___ 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 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. -- Patrick ZAJDA Skype: gansta93 ___ 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] Sharing wiperam package between Freepto and Tails?
intrigeri: > @Patrick: why is the build-dep on config-package-dev versionned to > 0.5.1? Isn't Wheezy's 4.13 good enough for our needs? (Worst case, we > can fetch 0.5.1 from wheezy-backports, but still :) Even it has been obsoleted by now, I like answering it maybe for the future. wheezy: config-package-dev (4.13) CDBS modules for building configuration packages wheezy-backports config-package-dev (5.1.1~bpo70+1) Debhelper (and CDBS) modules for building configuration packages I was using Debhelper. Looked like the better choice than learning CDBS just for this. >>> = litian warning init.d-script-missing-dependency-on-remote_fs = > >>> E: wiperam: init.d-script-missing-dependency-on-remote_fs >>> etc/init.d/tails-reconfigure-kexec: required-start >>> E: wiperam: init.d-script-missing-dependency-on-remote_fs >>> etc/init.d/tails-reconfigure-memlockd: required-start > >>> You probably don't want to add remote_fs as dependency. Should I add a >>> lintian override? Lintian override reason? > >> I'm unsure, will look at it tomorrow. > > Added $remote_fs dependency. Any reason why we should not have? You tell me. :) If it works, everything is fine. ___ 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] Firefox extension for downloading Tails
While you're at it, would it be a lot more effort to make it a generic download extension? I certainly enjoyed to have this issue that many software projects suffer from solved in a generic way. Otherwise it might get forked some day to have a download extension for gpg, TBB, Whonix, etc.? :) ___ 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] Post-backbone collaboration
Jurre van Bergen: > Dear Privacy Distributions, Hi! :) > Or what are you working on? I am currently working on splitting Whonix into multiple packages. Having ability to be used by other privacy distributions on general Libre Software users in mind. I hope that a lot of functionality can and eventually will be used by other privacy and/or general distributions. Have a look at what packages/functionality is provided: https://github.com/Whonix (~6 pages; ~100 packages) Help with getting packaging ready to be acceptable for Debian [etc.], mentoring, finding Debian maintainer, etc. is welcome! > - Feature #5655: Share username and hostname amongst all anonymity > distributions > https://labs.riseup.net/code/issues/5655 > > I included the last one, since I brought it up at backbone409 and might > be interesting to have as an discussion. I have no strong opinion about this yet. Fine either way. The feature "Share username and hostname amongst all anonymity" has been implemented as a Debian package: https://github.com/Whonix/anon-base-files All the best, Patrick Schleizer (a maintainer of the Whonix privacy distribution) ___ 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] Sharing wiperam package between Freepto and Tails?
Hi! = news = Did some work on this... Link: https://github.com/adrelanos/wiperamFreepto Package builds fine. ./build script produces deterministic wiperam_0.1.orig.tar.gz, wiperam_0.1-1_all.deb and wiperam_0.1-1.debian.tar.gz. Package installation and actual functionality untested. = copyright = Can you tell me please who claims copyright on what file, so I can finish debian/copyright? I guess most files copyright is (C) Amnesia License: GPL-3+ On what files Freepto does claim copyright? For my own copyright, I plan on being relaxed. For now, GPLv3+ as well, but for this minor thing also something more lax could be used. Nevermind. = source folder name = I appreciated, if we could rename source folder to wiperam. That would make the ./build script work out of the box. = git url = I appreciated, if we could name the repository https://github.com/AvANa-BBS/wiperam instead of https://github.com/AvANa-BBS/wiperamFreepto. = kexec-load = We probably do not need to use invoke-rc.d after " update-rc.d kexec-load defaults" in maintainer scripts? = tails-* filenames = Do we wish to wipe the tails-* part from files names? Replace it with "wiperam-*"? I think it would be a good idea. = lintian etc/init.d/kexec-load = W: wiperam: init.d-script-not-marked-as-conffile etc/init.d/kexec-load E: wiperam: init.d-script-not-included-in-package etc/init.d/kexec-load I think we should override them, because we're shipping an insserv override. (It complains because we're using update-rc.d in maintainer scripts, so the insserv override gets activated.) Alternatively, we could also ship the forked /etc/init.d/kexec-load and displace it using config-package-dev. = litian warning missing man page = Let's move files in /usr/bin/* to /usr/lib/wiperam/*, since these are not useful to users anyway? = litian warning init.d-script-possible-missing-stop = You tell me. Want a lintian override? Lintian override reason? = litian warning init.d-script-missing-dependency-on-remote_fs = E: wiperam: init.d-script-missing-dependency-on-remote_fs etc/init.d/tails-reconfigure-kexec: required-start E: wiperam: init.d-script-missing-dependency-on-remote_fs etc/init.d/tails-reconfigure-memlockd: required-start You probably don't want to add remote_fs as dependency. Should I add a lintian override? Lintian override reason? = kexec, memlockd init scripts = The old packaging used: PATCHED_INITSCRIPTS=" kexec memlockd " insserv -r $PATCHED_INITSCRIPTS insserv $PATCHED_INITSCRIPTS $CUSTOM_INITSCRIPTS I don't understand why running update-rc.d on kexec or memlockd's init script would be required - their init scripts were not modified. /etc/init.d/kexec is not modified at all and only /etc/memlockd.cfg gets displaced, but that should not require running "update-rc.d /etc/init.d/memlockd defaults". Therefore, those init scripts remain untouched. If I am wrong here, we can do this. = answer = intrigeri: > This would be terrific. I've planned to work a bit on it with > ono-sendai around June 27-29. Do you think you can get the package in > a better shape before? Yes. > Suggestions: > > * switch to non-native package, to ease maintaining the delta > Freepto, Tails, Whonix and others might have to insert Done? > * standard git-buildpackage repo layout I don't understand git-buildpackage and couldn't make friends with it yet. If you wish, I can solve some more packaging issues raised above and, would be happy if my work turns out as being useful and wouldn't mind if you take over from there. Also I wouldn't mind if you forked the package / wanted git write access and/or quickly fixed the debian/control 'Maintainer:' to your name and so forth. > 3.0 (quilt) source format Done? > * Lintian is your friend :) Answered above. Cheers, Patrick ___ 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] Sharing wiperam package between Freepto and Tails?
Hi! Terrific! I also would like to see this getting packaged and ideally even entering Debian. Maybe I can help a bit packaging it. I advise against directly using dpkg-divert for config file diversions. That may cause issues later when attempting to upgrade the package. In my opinion config-package-dev [0] [1] [2] [3] [4] [5] provides a fine abstraction to handle this in a more tested and robust way. If you're interested, you could have a look at the anon-base-files [6] package as example, which diverts a few config files. For such simple [7] config package, I also think the files structure of the anon-base-files package is simpler. So if you're interested in my help, I could do the initial packaging, i.e. getting files in place, diverting config files... But it would be up to you to get the actual ram wipe working. Could you make the github readme English by default? Cheers, Patrick [0] http://debathena.mit.edu/config-packages/ [1] >= 5.1.1 [2] with debhelper support (don't bother CDBS) [3] https://packages.debian.org/wheezy-backports/config-package-dev [4] only a build dependency [5] not an install dependency [6] https://github.com/Whonix/anon-base-files [7] The packaging seems simple at first. Figuring out the config (Thanks to the Tails devs!) is anything but simple. ___ 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] dead link
Hi! Quick one.. Here: https://tails.boum.org/contribute/design/#index42h3 Is: https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/lib/live/config/201-pidgin Should be: https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/lib/live/config/2010-pidgin Cheers, Patrick ___ 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] Tor Launcher as a standalone XUL app in Tails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 anonym:> Conclusion: if my analysis above is correct, and my assertions/questions > are the way I expect, then the standalone XUL approach is in fact > cleaner, simpler, more flexible, more portable (outside the Tails > context) and more maintainable than the "exit the browser" one. I > can see no disadvantage with it, now that the research has been > done. Therefore I think we should change the old plan and go with > the standalone XUL application approach instead. Hi, As system Tor, Whonix user and Whonix maintainer, I'd be happy to have a vidalia replacement as well. The "exit the browser" attempt seems like a hack and depending on a browser wrong. Standalone XUL app would be much preferred. Cheers, Patrick -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTBInVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxIinIP/3z+lZW4k/cJRRbjHj63MEeJ rC26aUsbjxuxSsyRj9VO7bBPkHIbGJFU0e2sMMJC5PsHhO0pguJjeY0fZOLlK8lc I6YCzM6FX/WyGDTTdGAu8Tg8cmD4xn2YM1zmub8x+pixfv6UDItkKJ/Cg3D7cAvZ 4k03mBBSW/LfIlfFXoiID8O5PhgvEruYg1GXZTubcgatYKMKUXKsEbVeQ95vDryB UloanXG+8M677o4a6UYgoz4D4EPo5+1SFE5wBci4urerU1leHOH9zhX/vgT6njEA E5Rxzg1NBfC4FlQmDhIgg4r+BBjCYZ1qYIUc7SWtieVVsQb7uuEyeoRI9Q1Ud6MR EnQ4x0kc1+UbuEuVPncvrPw4r/wpId3tOCHREm/BuJVS9uXZGVM3MU6aeplchqpJ F3icxxm+6FIwXZWhA9g4tGkc8kg/NOVCZZ2UZLS6AVr37aZWamShl0OD6n93uq6F z1tXQJfZ8/QaCXRXj3eiDx3OE78AF3C/ElyyYD3EXioLgph6Xu+rX+8RAo/UZEOz gvsD3yVn2S0TaPjzNdmo47Ve+lP7sF1DPZue2pTxiLhtVPphJxlwrrz/hUR8Cf13 Xl8yrYUASHX+8WE9NLpKc8sZkMmyPMtksc42SPkqrehsR6rGrC6FUM9vKEl+r4Lk vKTlkQ7eqvNnc2UUKuEu =Wefx -END PGP SIGNATURE- ___ 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] Manual Installation Using Mac Documentation Feedback
Hello, on the page : https://tails.boum.org/doc/first_steps/installation/manual/mac/index.en.html It should be noted that step 1, rEFInd setup is only required if you want to USE the TAILS usb on the mac, not if you are simply using the mac to create the bootable USB drive. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Risks of enabled/disabled TCP timestamps?
Hi, TCP timestamps are created using the systems clock, is that correct? Would it make sense to, - when Tails starts: save system clock - before Tor starts: randomize system clock (+/- a random amount of milliseconds [and seconds?]) - when Tails is shut down: undo system clock randomization ? That should at least prevent linkage between Tails and non-Tails sessions? Cheers, Patrick ___ 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] PGP Smart Cards
On Mon, Aug 27, 2012 at 6:11 PM, wrote: > Just to share experience: I tested an OpenPGP smartcard reader on Tails. > The required packages were installer *but* there were permission issues > that prevented gnupg from reading the smardcard without being root. For > root however it worked fine. Ran into those same issues myself. Root is necessary unless the amnesia user is added to the pcscd group. For some reason I needed newer versions of those packages when using the 'Gemalto USB Shell Token V2'. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] PGP Smart Cards
>On Sun, Aug 26, 2012 at 6:24 PM, intrigeri wrote: > Maxim Kammerer wrote (25 Aug 2012 19:59:33 GMT) : >> Hi, what's the big deal about having support for PGP SmartCards? > > We had not included such software yet due to lack of hardware for > testing if it would actually be useful at all. > > Patrick reports that software newer than what's in Debian Squeeze is > needed for their hardware. Hence the need for a backport. Yup, I needed smart card packages for my own purposes and Tails had already been interested in supporting this. >OK. I suggest kindly asking the maintainer of these two Debian >packages to prepare and upload updated versions to squeeze-backports: I just emailed Ludovic and CC'd you. A squeeze-backport would definitely be the right solution until Wheezy is here. I'll try my hand at it if Ludovic doesn't respond. As Clean Room develops hopefully we can merge some of the work from that back into tails. I know I will use the pcscd packages in Tails for pgp mail when I don't have access to my own computer. Regards, Patrick ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] PGP Smart Cards
On Fri, Aug 24, 2012 at 12:34 PM, intrigeri wrote: > Are you interested in trying to backport these two packages for > Squeeze, or testing backports we would prepare, and see if that's > enough to get things working? I can't say i'd be the best person to make the back ports as I have no experience with that, but I'd be more then happy to help test them. Let me how I can help and I will get back pretty fast about things. Abel, a developer for the guardian project is working on a fork of Tails called 'Clean Room'. Basically, it would just be a Tails distribution that includes this drivers, removes all networking, and adds script that facilitates creating and managing an offline master key. I think it'd still be very useful to have the drivers in Tails and other support that doesn't conflict with the more general computing environment that is Tails. He plans to release an early version this week I believe. I'll make its gets mentioned on the list if anyone is interested. Regards, patch ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
