[tor-dev] Acceptable clock skew in tor 0.4.1
Hi, recently, tor has become more tolerant to skewed system clocks; great, thanks! At Tails, we would like to take advantage of these improvements in order to remove as much as we can of our not-quite-safe clock fixing code. Our testing suggests that: - A ±24h clock skew is now acceptable in most cases¹: tor bootstraps successfully. - While with a ±48h clock skew, tor fails to bootstrap. Could someone on the network team please confirm that these empirical results match what the code is currently supposed to do? Thanks in advance! [1] In some corner cases I see weird behavior (#32438). And obfs4proxy is stricter than that, which I should report on Trac. Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Browser for arm64/v8 on RPi3
Hi, procmem: > We at Whonix are currently porting to (non-VM) physical builds on arm64 > - specifically RPi3. While this is great for headless applications we > are interested in GUI user adoption. Without Tor Browser for arm64 this > won't be as safe as it can be. Can you please consider releasing builds > for this hardware platform? A few suggestions to improve the chances your proposal/request gets some more traction: - describe the expected benefits for users - send this to tbb-dev: https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev - give it (building on arm64) a try so everybody can have an idea of how much work is required - look at the work done on Tor Browser for Android, that probably builds for some kind of ARM platform :) Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Setting NumEntryGuards=2
Mike Perry: > 2. Guard fingerprintability is lower with one guard > An adversary who is watching netflow connection records for an entire > area is able to track users as they move from internet connection to > internet connection through the degree of uniqueness of their guard > choice. There is much less information in two guards than three, but > still significantly more than with one guard: > https://trac.torproject.org/projects/tor/ticket/9273#comment:3 > But, even with one guard, if there are not very many Tor users in your > area, you still may be trackable. "Guard bucket" designs are discussed > on the blog post and in related tickets, but they are complicated and > involve tricky tradeoffs (see > https://trac.torproject.org/projects/tor/ticket/9273#comment:4). The > best solution that I see to this is to make Tor maintain separate guard > choices depending on the current SSID, BSSID, or default gateway router > MAC from ARP. The default gateway ARP MAC is probably easiest for us to > implement cross-platform and stable across wifi to ethernet. FWIW we at Tails have started working on this topic a couple years ago. We came up with a (far from perfect) plan that is documented there: https://tails.boum.org/blueprint/persistent_Tor_state/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] apparmor in lxc containers [#17754]
Hi, Peter Palfrader wrote (15 Dec 2015 08:24:25 GMT) : > https://bugs.torproject.org/17754 reports that tor no longer works in > LXC containers. > I have set up an ubuntu wily VM, and a wily LXC container in it, and I > can confirm that with the AppArmorProfile= line in the service file, tor > will not launch. Given the logs I see on the ticket, it looks like systemd was not allowed by the container to apply our AppArmor policy. Linux namespaces support more and more stuff these days, but they didn't go as far as supporting stacking AppArmor policies yet: https://bugs.launchpad.net/apparmor/+bug/1379535 ... not even mentioning limitations that AppArmor has with stacked filesystems such as aufs and overlayfs, which are commonly used for containers. > Do you have any ideas how to properly fix this? Or what the best > workaround would be to document? Sadly, I don't know what we can do better at the moment than disabling AppArmor when running in such environments, like: https://trac.torproject.org/projects/tor/ticket/17754#comment:6 Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) : Just copy the /lib/systemd/system/tor.service file to /etc/systemd/system and edit it there -- it will take precedence over the one in /lib . You don't want to edit the one in /lib directly, since it is meant to be for distribution files that can/should be replaced on upgrades. Right. And even better: using drop-in override files would avoid having to maintain a local forked copy of the unit file. Look for .conf in systemd.unit(5). Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
aexlfow...@web.de wrote (08 Jul 2015 17:57:24 GMT) : (Both packages for 0.2.5.12 and 0.2.6.9 contain an apparmor profile. Only change and new line is /usr/bin/obfs4proxy PUx, in /etc/apparmor.d/abstracions/tor) FTR, the systemd unit file in Debian sid's 0.2.6.9-1 doesn't enable the AppArmor profile (yet), so I doubt AppArmor has anything to do with this problem (aa-status will tell you). However, it has: PrivateTmp=yes PrivateDevices=yes ProtectHome=yes ProtectSystem=full ReadOnlyDirectories=/ ReadWriteDirectories=-/var/lib/tor ReadWriteDirectories=-/var/log/tor ReadWriteDirectories=-/var/run ... which explains why /media/cRAID/Tor/lock isn't writable. So you'll want to add what is called a drop-in override file in systemd's terminology (that can be created e.g. with `systemctl edit'), that adds a ReadWriteDirectories= directive pointing to the directory you want. Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The future of GetTor
Hi, ilv wrote (15 Jun 2015 23:14:54 GMT) : With this in mind, we have been discussing about the idea of having a signed and verified distributor app (desktop), available on official channels (OSX app store, Google Chrome store, etc), which could ease the process of downloading and verifying the integrity of Tor Browser. You might be interested in the work that's happening there: https://tails.boum.org/blueprint/bootstrapping/extension/ (I'm not directly involved in this, for more information ask sajol...@pimienta.org.) Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] #14995: systemd unit files - review
nusenu wrote (02 May 2015 16:04:13 GMT) : intrigeri: This is being worked on there: https://bugs.debian.org/761403 (which should be a more appropriate forum to discuss this topic.) Also for the ubuntu packages? AFAIK the Ubuntu packages are just the Debian one, rebuilt for Ubuntu. I'm not aware of any Ubuntu-specific Tor packaging effort. Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [Tails-dev] Aspirant for Tor Summer of Privacy ( for Improving Tails)
Hi, Saket Sinha wrote (07 Apr 2015 18:04:13 GMT) : I was looking at the bug list and found that https://labs.riseup.net/code/issues/7567 has finally led to Docker as a choice for the future build system for Tails. [...] Indeed, that's our best bet so far, and the PoC we came up with is promising. Better ideas are welcome, though. I also went though https://tails.boum.org/blueprint/Linux_containers/ and the corresponding issue https://labs.riseup.net/code/issues/6178 which says certain security issues prevent Tails to use LXC. Indeed. I say we can reconsider once Wayland is here (Debian Stretch, I would say). Both the above projects interests me and I would love to work with Tails developer community on either of them. So, I've discussed this on IRC with someone who claimed to be Saket Sinha. Here's a report: * The Docker thing may not be large enough for a 3 months full-time project, especially since Saket Sinha isn't fluent in Puppet, and thus can't take care of the infrastructure bits. I may be wrong, so Saket Sinha is now aware that he may try to build a project timeline, with time estimates and bi-weekly milestones, about this Docker thing, and then come back to us and discuss if it seems worth it. * The container thing is blocked by too many other things for which we're not on the driver's seat, in particular when it comes to delivering a good enough UX. * Since Saket Sinha has some experience with kernel development, we've discussed a bit the overlayfs vs. AppArmor issue, and tried to find a mentor. On #apparmor we've learnt that the ball is currently in David Howells' court, but John Johansen (AppArmor kernel hacker) will get in touch with him and see if some help would be welcome. If the answer is yes, then John is happy to give a hand for mentoring, but I suspect he won't have enough time to handle this alone, so another kernel hackers would be more than welcome to help. I guess I could help a little bit on the organizational side of things, but I definitely can't be a good technical mentor in this area. I've reached out to a few other people who have the right skills, and so far everyone is busy with other matters. Also, it might be that the Tor project sees this topic as too remote from the Tor Summer of Code's scope -- I'm all ears :) Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [Tails-dev] Aspirant for Tor Summer of Privacy ( for Improving Tails)
Hi, Saket Sinha wrote (06 Apr 2015 18:57:47 GMT) : I would like to participate to Tor Summer of Privacy by contributing to Improve Tails by working on Debian. I have worked on Debian packaging and build systems and find this project a match for my technical skills. Great! I have to say it comes as a surprise for me, since I didn't realize that the SoP homepage [0] pointed to Tor's projects page [1], that indeed lists Tails. Given that, depending on what exact project you want to work on, we may be in a position to find a mentor for you on our team, or not. I hope it'll work, but sadly, I doubt we'll be able to clarify this before you have told us what exactly you would like to work on. Kindly let me know how to go ahead with this. Please: 1. Read the SoP homepage [0] entirely. It actually answers this question of yours. 2. Come up with a great project. Once you have an idea or two, feel free to come discuss it on tails-...@boum.org: we can help you adjust it to better match your skills and desires, and the Tails project's current needs. 3. Send your application as instructed on that page. When you'll do that, please Cc ta...@boum.org (our core team's private mailing-list) when emailing tor-assistants@, so that we're in the loop. Please include as much specifics as you can regarding your past experience with Debian packaging and build systems (pointers to actual VCS repositories and code would help). Also: * Was your GSoC application with CentOS accepted? * At some point, I'd like to be put in touch with the mentor(s) you had when you were working with CERN during GSoC 2013. This can wait until you've reached step #2 as described above. [0] https://trac.torproject.org/projects/tor/wiki/org/TorSoP [1] https://www.torproject.org/getinvolved/volunteer.html.en#Projects Regards, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Producing automated screencasts for Tor Browser
Hi, Karsten Loesing wrote (19 Mar 2015 10:04:56 GMT) : 5. Start a screen recorder and run the Sikuli script for all three systems and all supported languages. The Tails automated test suite uses cucumber to drive Sikuli and libvirt virtual machines. It is able to record the screen on video. Note that last time we checked, Sikuli's OCR was too fragile for us so we look for images instead. But this was 2 years ago, so maybe things have improved since. Design doc: https://tails.boum.org/contribute/release_process/test/automated_tests/ Example cucumber feature: https://git-tails.immerda.ch/tails/tree/features/torified_browsing.feature?h=stable The script to run it is: https://git-tails.immerda.ch/tails/tree/run_test_suite?h=stable The Sikuli glue code lives there: https://git-tails.immerda.ch/tails/tree/features/support/helpers/sikuli_helper.rb?h=stable Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] #14995: adding multi-instance support to debian packages (patch)
Hi, Nusenu wrote (16 Mar 2015 14:09:13 GMT) : many relay operators run multiple tor instances to overcome certain limitations. Currently the official deb packages do not come with an easy configurable way to run multiple tor instances. Just for the record, we've discussed this a few months ago with weasel, and the plan was to use a systemd unit template, that allows to support this feature in a nice and elegant way: * introductory blog post about it: http://0pointer.de/blog/projects/instances.html * http://www.freedesktop.org/software/systemd/man/systemd.unit.html (look for unit template) I've no opinion regarding adding such support to the SysV initscript, except I'm not personally interested in working on it myself (contrary to the systemd-based solution). Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] #14995: adding multi-instance support to debian packages
Nusenu wrote (17 Mar 2015 12:15:22 GMT) : intrigeri: Just for the record, we've discussed this a few months ago with Is there a trac entry? I don't think so. I'll prepare a unit file for this and add it to the trac entry. \o/ Weasel wrote: Tor trac is not the place to discuss Debian packaging enhancements Right. In the specific case of systemd unit templates, I think that a great part of the work will have to be done upstream first, before the Debian packaging can take benefit of it, so perhaps Tor's Trac is appropriate for the time being. Unless we want to support systemd unit templates only in Debian, but that would be a bit sad. Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [RELEASE] Torsocks 2.0.0 stable
Hi, David Goulet wrote (11 Aug 2014 16:59:20 GMT) : Following the discussion of bug #10007[1], this is the *stable* release 2.0.0 for torsocks. Nothing major went in since -rc7, see the change log below. Congrats! Thanks to this stable release, we've finally uploaded the new torsocks in Debian unstable (while the RCs only went to Debian experimental). Kudos to Lunar who did most of the work. Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX Idea - A controller inside TBB
Hi, Mark Smith wrote (29 Jul 2014 13:38:55 GMT) : Just so others are aware: Arthur is actively working on this ticket: Create Browser UI indication for current circuit status and exit IP https://trac.torproject.org/projects/tor/ticket/8641 Thanks for pointing to it. This might be enough for Tails to stop shipping Vidalia, finally :) However, ideally we would also need a UI that allows monitoring circuits created by non-web usage, which is apparently not covered by that ticket. Not sure if it's a real blocker. Damian, what's the status wrt. providing this feature in arm? Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [announce] Tails HackFest, July 5-6, Paris
Hi, I'm looking forward to see quite a few of you there! Join us at the Tails HackFest, 2014! July 5-6, 2014 -- Paris, France Description and goals = Join us to make online anonymity and digital privacy usable by the masses! Whether you're a writer, a software developer, a designer, a system administrator or just plain interested, come learn about the challenges faced by Tails, and how you can be part of the solution. The Tails HackFest will bring together anyone interested in making Tails more usable and more secure. This open event will be an intense mix of teaching, drawing, coding, sharing, learning and celebrating. Logistics = * Where: the venue for the event is IRILL, Paris, France (https://www.irill.org/about/information-for-guests). * Dates: Saturday, July 5, 2014 - Sunday, July 6, 2014 * Time: 10 AM - 10 PM * Registration: if you want to attend, please consider dropping us a note about it. This is optional, but would help organizing this event. * Contact: tails-hackfest-2...@boum.org, #tails-hackfest on irc.oftc.net * Details, scheduling and updates: https://tails.boum.org/blueprint/HackFest_2014_Paris/ Host and sponsors = Many thanks to Debian, IRILL, Mozilla and the Tor project for supporting this event! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] 2014WinterDevMeeting/notes/TBBReleaseProcess
Hi, FWIW, from my Tails PoV: * I concur, it would be very helpful for us to have some better visibility on what's coming in the next TBB. * Mike has answered us in a very kind, timely and detailed way every time we've asked him this information. Many thanks! Also, I figured it would be good if the Tor Browser team was aware that we've been playing a kinda dangerous game lately: we are generally building our browser and ISO on the Sunday before a Firefox release is scheduled, so that we can test it on Monday, and release on Tuesday at the same time as Firefox. The rebased Tor browser patches are usually published at a time when we've already built our browser. Until now, it has been fairly smooth and painless: the slightly older patches apply nicely on the new tree, and the resulting browser works fine. Worst case, we've missed some last-minute improvements. However, I'm a bit scared that one these days, Tails users are hit by an important problem caused by this scheduling mismatch. I'm not expecting the Tor Browser folks to work week-ends and make our life easier, so the best we can do is possibly to go on automatizing things, so that we can reduce the time manual testing of Tails releases takes, and build our browser later. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Torbirdy - IMAP issue
Sukhbir Singh wrote (06 Dec 2013 05:49:26 GMT) : (If I recall correctly, this issue was discussed before also but I can't seem to find the thread/ticket.) IIRC it was discussed recently on libtech. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
Hi, David Goulet wrote (02 Nov 2013 15:58:52 GMT) : For now, it would only be .i2p address support (like .onion). In torsocks, it's not that difficult to support both addressing. I guess that people who use both I2P and Tor within Tails would be very happy with this. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Attentive Otter: Analysis of xmpp-client
Hi, Jurre van Bergen wrote (07 Oct 2013 17:21:42 GMT) : Below you can find the analysis of xmpp-client for the Attentive otter project, written by dgoulet, nickm, arlo, asn and myself. Thanks a lot. *Linux* Packaged in most distributions. Unfortunately, it's not in Debian. I've found no RFP or ITP either. Anyone here with sufficient understanding of both Go and Debian packaging, and wants to add it to Debian? Or should I file a RFP? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] final torsocks RC 1.3 tar.gz up for testing
Hi, Jacob Appelbaum wrote (29 Jan 2013 18:58:10 GMT) : Thus, I am declaring the following tar.gz to be the final RC for 1.3: https://people.torproject.org/~ioerror/src/torsocks-1.3.tar.gz Awesome! I believe that if no one has any objections and if intrigeri, nickm, Oscar and/or meejah sign off on it, I'll call it a release, tag it and push it the tag to master with no other changes. I'll try to build and test it soon, but I'd like to be able to verify the tarball with a cryptographic signature first. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] First-time tails/tor user feedback
apps. None understood what happened. After an explanation, one person suggested changing the red outline with snake to an actual message written inside, along the lines of 'this app blocked for your protection. click here to unblock it.' I explained why that wouldn't work (because there is no flash, java, silverlight plugins installed) and their answer was 'then do not show it at all'. Inside noscript, I unchecked the 'show placeholder..' option and had them browse again. they were happy. It seems if the user cannot do anything about the blocked apps, not showing them may be preferred. I'm convinced. Adding as todo/NoScript:_hide_blocked_and_unsupported_elements to our TODO list. # Seventh issue: shutdown I asked all 8 to shutdown tails and let me know when they thought their data was safely no longer on the system. 1 of 8 figured out how to shutdown tails by clicking the big red button in the upper right corner. The rest hit the power button on the laptop. This is unfortunate, but I'm not sure we can do much better than a big red button for first time users. Hopefully users who care (or should care) about RAM forensics eventually notice that button, or learn documentation... After rebooting, i showed them all they could just pull the usb drive to do it as well. As soon as tails started shutting down, they all assumed everything was safe and tried to power off the laptop. Any chance a graphical splash screen would work any better than the text-mode version of that we already have, which already explains what's going on (but probably a bit lost among other confusing text-mode message most users are not inclined to read)? Thanks again, cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC] Tails Server
Hi, jvoisin wrote (19 Jun 2012 01:53:43 GMT) : I am sorry but I won't be able to pursue/achieve my GSoC[1] for personal reasons that I prefer not disclose on a public mailing list. Sorry about this. I hope things will be better for you soon. If we can help, please feel free to ask. I'd rather not pressure you now, but if you want to come back and work on Tails server with us at any later time, you are *much* welcome! Take care, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Self publishing over Tor Hidden Services
Hi,
Arturo Filastò wrote (23 Mar 2012 22:45:39 GMT) :
I believe this project has some common goals with the work TAILS
wants to do on the TAILS server edition [1].
Sure. There's probably some work that can be shared. It's unclear to
me what part of it yet, but we'll see.
It's striking how different those projects are, but not as much as the
fact we independently thought of proposing them for GSoC the very same
year. I think it confirms something like this is needed, and I'm
glad of seeing this happen.
Tails server and APAF share something important: they don't exist yet.
There are a few big differences between Tails server and APAF, though.
Let me mention some of those, and we'll see what we can learn from
this. At least I'm sure comparing Tails server with APAF will help
clarify what Tails server would be :)
Amnesia vs. post-mortem analysis of the equipment -- Tails server is
likely to be based on Tails (no kidding), inheriting much, if not all,
of its threat model and specification, including taking radical
measures to avoid writing anything to local storage media unless the
user explicitly asks for it. I did not see any such thing in the APAF
description. Is this part of the APAF threat model? I must say I am
impressed with how far something like the TBB goes to satisfy this
requirement at the application level. At some level, things get out of
control of most applications anyway (hints: swap, usage of various OS
functionality that may, or may not, write stuff to disk), but even if
we disregard that level, I'm not sure how a webapp framework for
a generic language such as Python could try to satisfy this
requirement as well as the TBB.
Target hardware and usage model -- As far as I understand it, APAF is
aimed at running on the Desktop (that is on a desktop or laptop
computer that's running a full-blown desktop environment such as
GNOME). We expect most of the services provided by Tails server to run
24/7 in cupboards, garages and basements. I don't expect users to keep
their desktop or laptop running and online 24/7. This is one of the
reasons why Tails server should be fully functional on boxes people do
not want, or cannot, use as Desktop computers anymore, e.g. because of
hardware being half-broken or not powerful enough to run a modern
Desktop environment plus server software.
Applications -- Tails server is meant to run any existing application
we add and maintain support for, building on existing blocks such as
Gobby and a few others. As far as I understand it, APAF is a framework
to write, and maintain, a set of brand new applications that would be
bound to this specific environment -- in other words, people not
interested in Tor are unlikely to ever contribute to such an
application. I find the APAF approach to be very ambitious.
Future -- Tails server would be a practical contribution to the
FreedomBox project, that should explore some of the FreedomBox
aspects:
1. In a way that's immediately useful to lots of people.
2. In a way that _practically_ attacks some of the FreedomBox
technical challenges (e.g. configuration management on the long
term, upgrade management, unlocking encrypted storage at boot
time on a potentially headless machine).
3. With a specific threat model in mind, that's not shared by all
people who {are, should be, are supposed to be, could, might} be
working on the FreedomBox project. Showing them deployed, working
code and systems will be much better an advocacy for anonymity,
storage encryption, and location hiding, than trying to explain
them why they should write support for all of this themselves.
Ideally, the purpose of Tails server should be taken over by the
FreedomBox some day, and the process that leads to Tails server should
help the FreedomBox to actually exist some day. Sometimes, it's great
to start a project while knowing right from the beginning it could
very well become obsoleted by something even greater that will be
maintained by, or with, entirely different people.
Tails server should be able to run APAF applications, right?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Deployability of Python software.
Hi, Fabio Pietrosanti (naif) wrote (07 Mar 2012 08:24:50 GMT) : So two activists for example would be able to have a redundant, anonymous, 0-maintenance, easy-to-be-setup web application server. This rings a bell: https://www.torproject.org/getinvolved/volunteer.html.en#tailsServer https://tails.boum.org/todo/server_edition/ I'm sorry I did not read this thread, so this may be totally OT. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Did you exchange a walk on part in the war | for a lead role in the cage? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor and DNS
Hi, Ondrej Mikle wrote (21 Jan 2012 01:47:56 GMT) : So far I've seen ttdnsd used only in Tails, TorDNSd was seen mentioned only in the Tor mailing lists (not sure how many individuals may be using it though). ttdnsd: kind of works, unless validation is required (ttdnsd fails as unbound forwarder, most likely because of not handling DS queries correctly) It seems that bunch of people who experimented with DNS over Tor came to conclusion that using existing caching resolver like unbound is simpler than specialized resolvers like ttdnsd. For the record, Tails uses a combination of the pdnsd caching DNS server, the Tor resolver (for request types it supports) and ttdnsd (fallback for other requests); details: https://tails.boum.org/contribute/design/Tor_enforcement/DNS/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Using a conf.d instead of a monolithic config file
Hi, warms0x wrote (07 Jan 2012 06:35:10 GMT) : Has there ever been plans or discussion about using a conf.d-style directory to store configuration file fragments? https://trac.torproject.org/projects/tor/ticket/1922 Regards, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Did you exchange a walk on part in the war | for a lead role in the cage? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Requesting feedback on TorDNSd v1.1
Hi, LETO wrote (24 Jul 2011 15:46:11 GMT) : Could some of you be so kind to try out my latest version of TorDNSd? It works a lot like ttdnsd with some additional features: Does TorDNSd use a single remote recursive DNS listener as its main source, like ttdnsd does? Or does it use the Tor resolver for requests it is able to deal with (namely: A requests)? Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Requesting feedback on TorDNSd v1.1
Hi, LETO wrote (26 Jul 2011 22:45:21 GMT) : It can use one or multiple remote dns servers (by default the google ones) meaning you can perform all queries (not just 'A' ones) Ok. I see the point of using ttdnsd-like functionality to supplement what the Tor DNS resolver is able to achieve itself. See our page about this issue on the Tails wiki in case you want to understand the place I'm speaking from: https://tails.boum.org/todo/support_arbitrary_dns_queries/ I also see the point of not granting one (and maybe a few) company/ies the power to decide example.com does not exist for TorDNSd (and Tails) users. Hence my past, present and future questions: How exactly does TorDNSd deal with multiple remote DNS servers? What issues could be possibly caused by using multiple remote DNS recursive servers by default in TorDNSd? What additional recursive servers would you consider worth adding to the default TorDNSd configuration? Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Did you exchange a walk on part in the war | for a lead role in the cage? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor meets real users
Hi, Andrew Lewman wrote (18 May 2011 19:37:28 GMT) : I like what TAILS has done here. They strip out all of the configuration options from Vidalia, so you can't click to change any settings. FWIW, the Settings dialog is nevertheless reachable, in Tails, from the menu one get by right-clicking the Vidalia taskbar icon. Many users sometimes need it to workaround so-called Internet access with filtered egress, and our upcoming bridges support needs it as well. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
