libc is dynamically linked so one distribution-level upgrade will fix one libc
problem. As opposed to having to rebuild every single program and trying to
ship that to users in a huge update. The former is less complex.
Statically linking shifts the burden of tracking and fixing security bugs, a
Dafwig:
> Ximin Luo:
>> I made something like this a few years ago:
>>
>> https://people.debian.org/~infinity0/apt/pool/contrib/t/tor-bridge-relay/
>
> A general question, but related to the sample configuration you've
> provided here, as well as other instr
Ximin Luo:
> Nima Fatemi:
>> [..]
>>
>> After some discussion on #tor-project a little while ago, the idea of
>> having a meta-package that includes all or the most recent transports
>> came up. Where people would install this meta package and it would
>>
Nima Fatemi:
> [..]
>
> After some discussion on #tor-project a little while ago, the idea of
> having a meta-package that includes all or the most recent transports
> came up. Where people would install this meta package and it would
> automatically take care of the required steps to get the late
Hi, ex-Freenet developer here.
konst...@mail2tor.com:
> Is the extra traffic desirable in Tor? Reading asn's comment, I was under
> the impression that you are interested in adding higher latency traffic
> such as Freenet or mixnets for better anonymity:
> https://blog.torproject.org/blog/crowdfun
On 02/02/16 18:56, Peter Palfrader wrote:
> On Tue, 02 Feb 2016, Nick Mathewson wrote:
>
>> The tl;dr here is:
>>* By default Git doesn't verify the sha1 checksums it receives by default.
>>* It doesn't look like we've got any inconsistencies in our
>> repositories I use, though. That's go
Hey, thanks for this!
I'd like to ask please upload this (or 15.1) to F-Droid soon. The version
currently in F-Droid is RC-4 and is broken with orwall -
orwall-allowed/redirected apps see no internet, but tor is connected and orfox
can access it. RC-7 fixes this issue, I just tested it out.
X
On 05/03/15 00:53, Ximin Luo wrote:
> From the binaries, one should install both meek-client and
> xul-ext-meek-http-helper; the latter depends on xfvb and xauth.
>
> meek-client has been modified slightly to run meek-http-helper in a headless
> firefox using Xfvb(1)
ahem
Source package: https://mentors.debian.net/package/meek
Binary packages: https://people.torproject.org/~infinity0/bin/
From the binaries, one should install both meek-client and
xul-ext-meek-http-helper; the latter depends on xfvb and xauth.
meek-client has been modified slightly to run meek-htt
On 20/02/15 23:01, Tyrano Sauro wrote:
> I got tor build with libressl. it works. Is this a good idea?
>
> TY
>
Could you write some more details about how you got this to work? For example,
did you link in libressl during the build, did you have to change anything, or
did you just drop-in lib
On 09/11/14 12:50, George Kadianakis wrote:
> Hidden Service authorization is a pretty obscure feature of HSes, that
> can be quite useful for small-to-medium HSes.
>
> Basically, it allows client access control during the introduction
> step. If the client doesn't prove itself, the Hidden Service
On 18/09/14 16:41, David Fifield wrote:
> On Thu, Sep 18, 2014 at 02:02:42PM +0100, Ximin Luo wrote:
>> On 18/09/14 03:31, David Fifield wrote:
>>> Currently in the bundles we're not setting a bridge fingerprint, so
>>> relays wouldn't have to share a key.
>
On 18/09/14 03:31, David Fifield wrote:
> Currently in the bundles we're not setting a bridge fingerprint, so
> relays wouldn't have to share a key.
>
This is something to be *fixed*, not to build future components on top of.
Previously you mentioned that "the user could set their circuits to 4
On 16/09/14 03:12, David Fifield wrote:
> The meek pluggable transport is currently running on the bridge I run,
> which also happens to be the backend bridge for flash proxy. I'd like to
> move it to a fast relay run by an experienced operator. I want to do
> this both to diffuse trust, so that I
(Disclaimer, I don't know the details of how consensus documents work. Some
assumptions I made might be wrong.)
In section 2 Motivation, you mention a partition attack. I think the rest of
the document neglects the topic of *actually protecting against this*, instead
focusing only on running th
Hi Steven, Nikita, I was told that you two are interested in the idea of
composing multiple PTs together. Here are our ideas on it. We have a GSoC
student, Quinn also at Illinois, working on turning this into reality.
## Concepts
On the most abstract level, pt-spec.txt defines an "input interfa
Hi all,
I decided to create a new calendar, since the old one is out-of-date and we
seem to have lost the access.
View as a web page:
https://www.google.com/calendar/embed?src=dt92shou5q1ooe1kptubhclo4s%40group.calendar.google.com
Import into your calendar program:
https://www.google.com/calend
On 16/04/14 16:24, Ximin Luo wrote:
> On 16/04/14 16:11, Ximin Luo wrote:
>> On 16/04/14 15:56, George Kadianakis wrote:
>>> Ximin Luo writes:
>>>
>>> Hm, but this kind of kills the magic of indirect PTs, right? That is,
>>> users who want to use f
On 16/04/14 15:56, George Kadianakis wrote:
> Ximin Luo writes:
>
>>
>>
>>
>> So instead of having, as currently:
>>
>> (old, hacky) Bridge flashproxy (dummy addr)
>>
>> We would have the following cases:
>>
>> (1) Bridge flashp
On 16/04/14 16:11, Ximin Luo wrote:
> On 16/04/14 15:56, George Kadianakis wrote:
>> Ximin Luo writes:
>>
>> Hm, but this kind of kills the magic of indirect PTs, right? That is,
>> users who want to use flashproxy in the way above, will have to know
>> an addre
On 15/04/14 19:36, David Fifield wrote:
> On Tue, Apr 15, 2014 at 02:03:43PM +0100, Ximin Luo wrote:
>> ## The problem
>>
>> The problem with the above structure, is that it is incompatible with the
>> metaphor of connecting to a specific endpoint. This is what the PT sp
On 15/04/14 14:03, Ximin Luo wrote:
> (3, not-ideal) Bridge flashproxy (dummy addr) (fingerprint)
>
> Option (3) is quite nice, since in indirect PTs the actual address is
> irrelevant - the Tor client never tries to connect to it. I suggest that we
> have a special syntax fo
## Background
Pluggable Transports are proxy programs that help users bypass censorship.
[App client] -> XXX EVIL CENSOR HAS YOU XXX ACCESS DENIED XXX
[App client] -> [PT client] -> (the cloud!) -> [PT server] -> [App server]
The structural design, on the client side, is roughly:
1. App client
On 09/04/14 16:31, Ximin Luo wrote:
> On 09/04/14 07:29, David Fifield wrote:
>> It gets the job done, but it sucks because the first thing you see is
>> the dialog and you have to know not to close it. Is there a way to
>> accomplish the same thing (keep the browser runn
On 09/04/14 07:29, David Fifield wrote:
> It gets the job done, but it sucks because the first thing you see is
> the dialog and you have to know not to close it. Is there a way to
> accomplish the same thing (keep the browser running, but don't show a
> browser window) without raising a conspicuou
On 26/03/14 16:54, Michael Rogers wrote:
> Hi all,
>
> (Please let me know if this belongs on tor-talk instead of here.)
>
> I'm working on a messaging app that uses Tor hidden services to
> provide unlinkability (from the point of view of a network observer)
> between users and their contacts. U
On 14/03/14 20:56, quinn jarrell wrote:
> Hi Tor Devs,
> I'm a computer engineering undergrad at University of Illinois
> Urbana-Champaign. I am interested in working on a GSoC pluggable transports
> project.
> I mainly code in python or common lisp and have worked with asynchronous
> programmin
On 10/03/14 17:02, David Fifield wrote:
> On Fri, Mar 07, 2014 at 02:39:18PM +, infini...@torproject.org wrote:
>> commit 05b9c101ba9afe4653d1eff6f5414f90f22ef042
>> Author: Ximin Luo
>> Date: Fri Mar 7 13:39:31 2014 +
>>
>> remove failed con
On 22/02/14 04:08, David Fifield wrote:
> 2. Run a second browser, apart from Tor Browser, that receives commands
> from a client PT program and makes the HTTPS requests it is
> commanded to.
You might want to look at MozRepl. More summary here:
https://lists.torproject.org/pipermail/tor
This would be a nice-to-have, but not a priority for Tor. OTOH, that
functionality is more vital for i2p, who are exploring the idea of integrating
into Tor's PT system:
https://trac.torproject.org/projects/tor/ticket/10629
Also, right now, no PT servers can actually traverse NAT. In the future
> I imagine the anonymity set would be much smaller for these combined
> transports... fewer people using them.
In my understanding, the anonymity set doesn't apply to use of PTs since this
is only at the entry side. The exit side does not know[1] what PT the
originator is using, so is unable to
On 31/12/13 12:35, Jeroen Massar wrote:
> On 2013-12-31 12:07, Ximin Luo wrote:
>> Hey all,
>>
>> Flashproxy[1] helps to bypass entry-node blocks. But we could apply
>> the general idea to exit-nodes as well - have the exit-node connect
>> to the destination via an
Hey all,
Flashproxy[1] helps to bypass entry-node blocks. But we could apply the general
idea to exit-nodes as well - have the exit-node connect to the destination via
an ephemeral proxy. The actual technology probably needs to be different since
we can't assume the destination has a flashproxy
On 12/12/13 23:40, George Kadianakis wrote:
> David Stainton writes:
>
>> Excellent! I was thinking of making this change but lately I haven't had
>> much time.
>> Merging that patch specified in the 1st ticket comment? That looks good.
>>
>> I'd be happy to update the bananaphone transport to us
Hey Kevin, to get you updated on what we've discussed so far, you could try to
build the diagrams from this repo:
https://github.com/infinity0/tor-notes/blob/master/pt-compose.rst
The build-dependencies are short and listed in the Makefile. There is also a
sketch at the bottom of #9744:
https:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/11/13 14:22, dardok wrote:
> Hi,
>
> I've been reading about Selenium web-browser driver thing and I
> consider that is not very handy to do what an HTTP PT client side
> needs, that is to forge HTTP requests and embbed the TOR traffic into
>
On 11/11/13 15:40, Roger Dingledine wrote:
> On Mon, Nov 11, 2013 at 02:42:24PM +0000, Ximin Luo wrote:
>> Whilst we're on that topic, labelling the final link from the exit node
>> to the destination as "unencrypted" is unnecessarily scary as well Perhaps
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/11/13 14:10, Lunar wrote:
> Justin Findlay:
>> Item h under
>>
>> https://www.torproject.org/getinvolved/volunteer.html.en#OtherCoding
>>
>> discusses (at least) the images at this page,
>>
>> https://www.torproject.org/about/overview.html.en
>
On 07/11/13 17:20, m...@pagan.io wrote:
>
>> We've been doing regular meetings for little over a month now, and I'd
>> like to get some feedback and solicit suggestions, complaints, and
>> ways to make the meetings suck the least they can. Please let me know
>> what's working for you, what isn't w
On 20/10/13 07:02, David Fifield wrote:
> It's not that I'm trying to neglect unglamorous development--I'm really
> not. This is how I see it: As a software engineer, I am always trying to
> reduce risk. Refactoring code reduces risk in the long term but
> increases risk in the short term. Sticking
On 19/10/13 06:31, David Fifield wrote:
> On Mon, Oct 14, 2013 at 09:14:25PM +0100, Ximin Luo wrote:
>> Specific remaining tasks:
>>
>> - merge #9349, #6810, #9974
>> - push #7167 to an official tpo repo
>> - do #9976, and #7167#comment:42 might require an obf
On 01/10/13 03:13, Tom Lowenthal wrote:
> Combine obfuscation (obfsproxy) with address-diversity (flashproxy) [#11]
> ---
>
> **[On Track: Minimal]** The work of integrating obfsproxy with
> flashproxy is done. George will include thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/09/13 15:33, Lunar wrote:
> Ximin Luo:
>> I assume people will be interested in creating Debian packages for
>> these too. I am wondering if we should adopt a naming convention like
>> tor-pt-sshproxy, tor-pt-flashproxy,
I assume people will be interested in creating Debian packages for these too. I
am wondering if we should adopt a naming convention like tor-pt-sshproxy,
tor-pt-flashproxy, tor-pt-obfsproxy etc - like how mozilla extensions are all
called xul-ext-*. (We could even start a working group too.)
AT
On 06/09/13 09:58, Vmon wrote:
> Preliminary, we decided to have the meeting on Fridays, cause why not,
> but if you have serious problem with Fridays then we might be able to
> pick a better day.
>
> For the time of the meeting, considering the geographical positions
> of the current transport de
On 28/06/13 10:13, Yawning Angel wrote:
> Hello,
>
> I have been talking about this in #tor-dev for a while (and pestering
> people with questions regarding some of the more nuanced aspects of
> writing a pluggable transport, thanks to nickm, mikeperry and asn for
> their help), and finally have w
46 matches
Mail list logo
