Hello all,
Just a quick heads up for where this is going:
* 'GET_ONIONS' was changed to be 'GETINFO' subcommands for consistency.
* Code is in 'needs_review', for the 2nd round.
As a proof of concept I wrote: https://github.com/Yawning/onionwrap
It's a dumb quick and dirty hack that works like
On Wed, 11 Mar 2015 02:35:10 +
Yawning Angel wrote:
> The code: https://github.com/Yawning/tor/compare/feature6411
> The spec: https://github.com/Yawning/torspec/compare/feature6411
Minor updates to both over the course of yesterday, thanks to all that
gave useful feedback and corrections.
On Wed, 25 Feb 2015 16:14:47 +
Yawning Angel wrote:
> Anyway now that master is 0.2.7.x, I'm looking to revisit this in the
> form of:
[snip]
I talked to a few people at Valencia about this, including discussing
the outstanding issues and made the following changes since the last
discussion:
>
> FWIW this is already how Debian (and presumably other distros') tor packages
> work: tor runs as a dedicated user. Already it is possible to grant other
> users
> access to the control port (from which they can already create and remove
> hidden services). The reason why HS applications that c
On Sat, Feb 28, 2015 at 02:40:29PM +0100, carlo von lynX wrote:
> Thanks "Angel", appreciate your effort.
>
> On Thu, Feb 26, 2015 at 09:29:05AM +0100, Andreas Krey wrote:
> > On Wed, 25 Feb 2015 13:51:59 +, carlo von lynX wrote:
> > ...
> > > What is useful here is if I can use existing $app
Thanks "Angel", appreciate your effort.
On Thu, Feb 26, 2015 at 09:29:05AM +0100, Andreas Krey wrote:
> On Wed, 25 Feb 2015 13:51:59 +, carlo von lynX wrote:
> ...
> > What is useful here is if I can use existing $app with existing
> > tor router and just have a shell script drop the glue inst
On Wed, 25 Feb 2015 13:51:59 +, carlo von lynX wrote:
...
> What is useful here is if I can use existing $app with existing
> tor router and just have a shell script drop the glue instructions
> into the tor unix socket.
One way to do that would be to tie the hidden service to the existence
of
Hello,
Not sure about the renaming thing. I'm open to doing so, but a lot of
the user facing stuff (the torrc configuration variables etc) use the
HS terminology, so I'm not sure if being inconsistent is good.
On Wed, 25 Feb 2015 13:51:59 +0100
carlo von lynX wrote:
> On Wed, Feb 25, 2015 at 07
On Wed, Feb 25, 2015 at 07:41:01AM +0100, Andreas Krey wrote:
> The AF_TOR listener would go away with closing the listener socket
> as well (and thus is bound to the lifetime of the process); so binding
> a hidden service to the control connection is the obvious analogy.
Yes, but as it stands AF_
On Wed, 25 Feb 2015 05:06:37 +, carlo von lynX wrote:
> the advantages of that aren't obvious to me. why would i need to
> make every networking app hold the hand of its router to let it
> know it's still needed?
You answer your question yourself:
> tor is on its way to becoming an AF_TO
> > Concerning the "ephemerality" of it, I can imagine services
> > being configured en passant by a cat >> socket from a shell
> > script or so, [..]
>
On Tue, Feb 24, 2015 at 09:05:38PM +0400, meejah wrote:
> You still need to authenticate. I do like the simplicity, but it will be
> a little mo
carlo von lynX writes:
I like your suggestion, and while we're bikeshedding ;) what if we use
the recently-proposed naming system and call it "ADD_ONION"?
> Concerning the "ephemerality" of it, I can imagine services
> being configured en passant by a cat >> socket from a shell
> script or so,
On Fri, Feb 13, 2015, at 04:45 PM, Yawning Angel wrote:
> Yes, this means that if you run "kittensomgmewmew.onion" and are scared
> of the NSA's persistent attempts to extract your hidden service key,
> via ultrasonic laser beamed from their satellites,
...or the backdoor in the firmware on your
Let me chime in on saying that this looks to me like a great
development. I even imagine that in a couple of years most
end-to-end encrypted services on the Internet may be using
this interface, so for the sake of accessibility for future
devs, I would suggest something totally superficial:
On Sa
On Tue, 17 Feb 2015 02:22:54 +0400
meejah wrote:
> From my perspective, the entire point of this feature is to allow
> applications to use "the system Tor" (or, at least "some
> already-running tor") to put their hidden services on.
The design the way it is with more isolation than usual also al
On 2/16/15 11:22 PM, meejah wrote:
>
> I guess to put another way: I can't see a use-case to keep the hidden-
> service around if the application that added it went away.
+1 from globaleaks perspective
-naif
___
tor-dev mailing list
tor-dev@lists.torpr
>From my perspective, the entire point of this feature is to allow
applications to use "the system Tor" (or, at least "some already-running
tor") to put their hidden services on.
(Or, looking at it another way, if you don't want to share a tor
instance with other applications, you can do that eas
> As an app developer this strikes me as the right approach. But having
> said that, I wouldn't actually need this feature because Briar already
> uses __OwningControllerProcess to shut down Tor if the control
> connection is closed. I imagine the same would apply to any app that
> manages its own
On Mon, 16 Feb 2015 19:35:58 +
Michael Rogers wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> (CCing the hidden-services list.)
(Wonder if my reply will bounce.)
> On 16/02/15 16:11, Leif Ryge wrote:
> >> If someone has a suggestion for an alternative interface that
> >> can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
(CCing the hidden-services list.)
On 16/02/15 16:11, Leif Ryge wrote:
>> If someone has a suggestion for an alternative interface that
>> can handle applications crashing (possibly before they persist
>> the list of HSes they need to clean up), appl
On Mon, 16 Feb 2015 16:11:55 +
Leif Ryge wrote:
[snippity]
> However, it seems like in the case of applications which are not
> HS-specific this will necessitate keeping another process running
> just to keep the HS alive. I'd rather see two modes: one as you
> describe, and another in which t
On Mon, Feb 16, 2015 at 03:47:07PM +, Yawning Angel wrote:
> On Mon, 16 Feb 2015 10:17:51 -0500
> David Goulet wrote:
> [snip]
> > A hidden service is created using the key and list of
> > port/targets, that will persist till configuration reload or the
> > termination of the tor process.
On Mon, 16 Feb 2015 10:17:51 -0500
David Goulet wrote:
[snip]
> A hidden service is created using the key and list of
> port/targets, that will persist till configuration reload or the
> termination of the tor process.
>
> Now, an HS bound to a control connection might be a good idea, I'm n
On 14 Feb (00:45:24), Yawning Angel wrote:
Hey Yawning, great stuff btw! I have a questions below regarding
meejah's comment and
https://trac.torproject.org/projects/tor/ticket/6411#comment:32
"Ephemeral hidden services are tied to the control port connection that
created them. This means, that w
On Sat, 14 Feb 2015 13:46:04 -0800
Damian Johnson wrote:
> One gotcha to think about is that ADD_EPH_HS is using a variable
> number of positional arguments. This will limit your ability to expand
> this command in the future with new arguments. Also, I'd suggest
> renaming addrPort to addrTarget
Hi Yawning, nice addition! As requested moving from irc to here.
One gotcha to think about is that ADD_EPH_HS is using a variable
number of positional arguments. This will limit your ability to expand
this command in the future with new arguments. Also, I'd suggest
renaming addrPort to addrTarget
Yawning Angel writes:
Cool! I added a quick try at using this in txtorcon, with an example;
see the following branch:
https://github.com/meejah/txtorcon/tree/yawning-feature-6411
(Most of that example code would actually end up in the
endpoint.listen() code and be hidden from most users of the
On 2/14/15 1:45 AM, Yawning Angel wrote:
> Hi,
>
> The Warning: DO NOT USE MY BRANCH YET, IT HAS HAD MINIMAL TESTING AND
> REVIEW. IT IS NOT DONE. IT WILL BROADCAST YOUR SECRETS
> TO THE NSA'S ORBITAL SPACE STATION.
>
> Trac Ticket: https://trac.torproject.org/projects/
On Fri, Feb 13, 2015, at 07:45 PM, Yawning Angel wrote:
> Yes, this means that if you run "kittensomgmewmew.onion" and are scared
> of the NSA's persistent attempts to extract your hidden service key,
> via ultrasonic laser beamed from their satellites, you could run your
> tor instance entirely in
Hi,
The Warning: DO NOT USE MY BRANCH YET, IT HAS HAD MINIMAL TESTING AND
REVIEW. IT IS NOT DONE. IT WILL BROADCAST YOUR SECRETS
TO THE NSA'S ORBITAL SPACE STATION.
Trac Ticket: https://trac.torproject.org/projects/tor/ticket/6411
Branch: https://github.com/Yawning/tor
30 matches
Mail list logo
