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,
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 instructio
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
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
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 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
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 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
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
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:
On 16/04/14 15:56, George Kadianakis wrote:
Ximin Luo infini...@torproject.org writes:
snip
So instead of having, as currently:
(old, hacky) Bridge flashproxy (dummy addr)
We would have the following cases:
(1) Bridge flashproxy (real addr)
(2) Bridge flashproxy (real addr
On 16/04/14 16:11, Ximin Luo wrote:
On 16/04/14 15:56, George Kadianakis wrote:
Ximin Luo infini...@torproject.org 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 address or a fingerprint
## 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 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 for it though, to explicitly
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 spec is
about, even though it does
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 conspicuous
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 running, but don't show a
browser
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. Users
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
programming
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 infini...@torproject.org
Date: Fri Mar 7 13:39:31 2014 +
remove failed connections from proxy_pairs
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:
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
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
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
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 ephemeral proxy.
If an exit node
On 12/12/13 23:40, George Kadianakis wrote:
David Stainton dstainton...@gmail.com 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
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:
-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
these
-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
which look as
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 obfsproxy fix
I agree with this, except that I
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 this in
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.)
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 what I
36 matches
Mail list logo
