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
On Wed, 11 Mar 2015 02:35:10 +
Yawning Angel yawn...@schwanenlied.me 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
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
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
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 l...@time.to.get.psyced.org wrote:
carlo von lynX l...@time.to.get.psyced.org 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
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_TOR -
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 more complex
On Tue, 17 Feb 2015 02:22:54 +0400
meejah mee...@meejah.ca 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
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 hard
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
On Mon, 16 Feb 2015 10:17:51 -0500
David Goulet dgou...@ev0ke.net 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
On Mon, Feb 16, 2015 at 03:47:07PM +, Yawning Angel wrote:
On Mon, 16 Feb 2015 10:17:51 -0500
David Goulet dgou...@ev0ke.net 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
On Mon, 16 Feb 2015 16:11:55 +
Leif Ryge l...@synthesize.us 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
-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),
On Mon, 16 Feb 2015 19:35:58 +
Michael Rogers mich...@briarproject.org 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
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 Tor
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 easily
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
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
Yawning Angel yawn...@schwanenlied.me 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
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
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:
On Sat, 14 Feb 2015 13:46:04 -0800
Damian Johnson ata...@torproject.org 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
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:
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 a
26 matches
Mail list logo
