On 06/17/2016 12:53 PM, Henry de Valence wrote:
> On Thu, Jun 16, 2016 at 10:19:15AM -0400, Nick Mathewson wrote:
>> On Thu, Jun 16, 2016 at 10:06 AM, nusenu wrote:
>>> What is the Tor Project's motivation for providing RPMs (instead of
>>> relying on the RPM distro maintainer)?
>>
>> Frankly, I d
On Fri, Jun 17, 2016 at 12:53 PM, Henry de Valence
wrote:
> On Thu, Jun 16, 2016 at 10:19:15AM -0400, Nick Mathewson wrote:
> > On Thu, Jun 16, 2016 at 10:06 AM, nusenu wrote:
> > > What is the Tor Project's motivation for providing RPMs (instead of
> > > relying on the RPM distro maintainer)?
>
On 05/25/2015 12:32 AM, Lars Boegild Thomsen wrote:
> On Sunday 24 May 2015 20:32:41 Ondrej Mikle wrote:
>> There is also patchless way by adding "-std=gnu99" to CFLAGS (aside from C99
>> it
>> enables GNU extensions needed for compiling against uClibc on OpenWrt).
On 05/24/2015 05:19 AM, Lars Boegild Thomsen wrote:
> On Friday 22 May 2015 09:20:29 Shawn Nock wrote:
>> Will you post the Makefile for the buildroot package?
>
> Sorry guys, I sorted this one out. The culprit was actually my added
> -std=c99 that made lots of other stuff break. Taking that ou
On 10/24/2014 12:37 AM, Nusenu wrote:
> [I felt it is better to discuss this via email if you feel otherwise
> feel free to move the discussion back to trac.]
Please continue in the trac ticket, it's much easier to have it in once place
(https://trac.torproject.org/projects/tor/ticket/12871#commen
On Thu, Aug 14, 2014 at 4:47 PM, Nusenu <
bm-2d8wmevggvy76je1wxnpfo8srpzt5yg...@bitmessage.ch> wrote:
>
> >> Ondrej Mikle:
> >>> If possible, I'd like to avoid the if-defs. Do you perhaps have
> >>> a tip how to make the spec file "nice"
On Tue, Aug 12, 2014 at 6:47 PM, Nusenu <
bm-2d8wmevggvy76je1wxnpfo8srpzt5yg...@bitmessage.ch> wrote:
>
> Ondrej Mikle:
> > If possible, I'd like to avoid the if-defs. Do you perhaps have a
> > tip how to make the spec file "nice" and have it work both
On 08/09/2014 06:02 PM, Nusenu wrote:
> Hi Ondrej,
>
> I filed a bug regarding the rpm packages [1]: "hardcoding" config
> options in torctl.
I re-packaged 0.2.5.6 in tor-testing repo with the --defaults-torrc option and
updated torctl file so that there are no hardcoded defaults. Seems to work o
On 08/10/2014 10:40 AM, Nusenu wrote:
> Nusenu: While reading fedora's tor.spec [1], I noticed #8368 [2] and the
> fact that tor includes already a systemd service file but the RPMs do not
> make use of it yet?
I have looked at the tor.spec files - current one, EPEL one and Fedora one,
trying to
On 07/30/2014 10:22 PM, obx wrote:
> is somebody working on a rpm for centos 7?
>
> Is there an ETA?
The RPM packages for CentOS 7 are ready. See
https://www.torproject.org/docs/rpms.html.en
Ondrej
___
tor-dev mailing list
tor-dev@lists.torproject.org
On 08/20/2012 02:43 AM, Mike Perry wrote:
> Thus spake Ondrej Mikle (ondrej.mi...@gmail.com):
>
>> I've revised the DNS draft, attaching it. In section 4 there are some options
>> for integration with libunbound, but each of them requires some work with the
>> stock
Hi Nick,
I've revised the DNS draft, attaching it. In section 4 there are some options
for integration with libunbound, but each of them requires some work with the
stock libunbound code.
Ondrej
Filename: xxx-dns-dnssec.txt
Title: Support for full DNS and DNSSEC resolution in Tor
Authors: O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2012 04:46 PM, Arturo Filastò wrote:
> On 7/16/12 2:15 AM, Ondrej Mikle wrote:
>> On 07/15/2012 02:56 PM, Arturo Filastò wrote:
>>> I would like to follow up on the discussion we had in Florence on some
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/17/2012 10:08 PM, Isis wrote:
> On Mon 16 Jul 2012 at 02:15, thus spake Ondrej Mikle:
>> On 07/15/2012 02:56 PM, Arturo Filastò wrote:
>>>
>>> # What properties we would like it to have note: these are not
>>
On 07/15/2012 02:56 PM, Arturo Filastò wrote:
> I would like to follow up on the discussion we had in Florence on some
> design choices behind OONIB.
>
> In particular the most controversy was around using HTTP or rsync.
[...]
> # What properties we would like it to have
> note: these are not or
On 05/05/2012 03:05 PM, Ian Goldberg wrote:
> On Sat, May 05, 2012 at 01:47:45AM +0200, Ondrej Mikle wrote:
>> One trick I had in mind was create "secret hash function" (take the following
>> with a grain of salt, algebra is not my "primary thing"):
>>
&
On 05/04/2012 01:04 PM, Karsten Loesing wrote:
> On 5/4/12 2:21 AM, Ondrej Mikle wrote:
>> On 05/03/2012 01:32 PM, Karsten Loesing wrote:
>>> On 5/2/12 9:35 PM, Sebastian G. wrote:
>>>> [...]
>>>> "We don't need it, so better remove i
On 05/03/2012 01:32 PM, Karsten Loesing wrote:
> On 5/2/12 9:35 PM, Sebastian G. wrote:
>> [...]
>> "We don't need it, so better remove it." I really like that.
>
> I think we're really conservative with giving out bridge data, and
> that's good.
>
> At the same time there's a value in giving ou
On 03/12/2012 07:08 PM, Nick Mathewson wrote:
> On Sat, Mar 10, 2012 at 9:22 AM, Ondrej Mikle wrote:
>>
>> 1. Design
>>
>> 1.1 New cells
>>
>> There will be two new cells, RELAY_DNS_BEGIN and RELAY_DNS_RESPONSE (we'll
>> use DNS_BEGIN and DNS_R
The proposal seems quite thought through. Some comments inline:
On 03/09/2012 06:02 PM, Nick Mathewson wrote:
>
>
> 1.2. Allow externally generated certificates
>
>It should be possible for a Tor relay operator to generate and
>provide their own certificate and secret key. This will al
On 03/10/2012 03:22 PM, Ondrej Mikle wrote:
>
> The draft is here (full text pasted at the end of this mail):
>
> https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnssec.txt
Just a quick fix, I've noticed I have two sections named "Imple
pasted proposal (hopfully will wrap well)
Filename: xxx-dns-dnssec.txt
Title: Support for full DNS and DNSSEC resolution in Tor
Authors: Ondrej Mikle
Created: 4 February 2012
Modified: 10 March 2012
Status: Draft
0. Overview
Adding support for any DNS query type to Tor, as well as DN
Hi,
I've updated the Tor DNS/DNSSEC draft from what was said in this thread. Short
summary of changes:
- drop IDs (use StreamID), drop length from DNS_RESPONSE, keep just uint16_t
total_length
- separate tool for AXFR so that server can be specified
- validation always on client side by default
-
On 02/10/2012 08:20 AM, Jakob Schlyter wrote:
> On 7 feb 2012, at 22:08, Ondrej Mikle wrote:
>
>> 1. full packet might leak identifying information about OS or resolver used,
>> quoting Nick:
>>> There are parts of a DNS packet that we wouldn't want
>>
On 02/09/2012 10:58 PM, Ondrej Mikle wrote:
> On 02/09/2012 12:24 AM, Jacob Appelbaum wrote:
>> On 02/08/2012 11:47 PM, Ondrej Mikle wrote:
>>> On 02/08/2012 02:59 AM, Nick Mathewson wrote:
>>>> On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle
>>>> wrote:
&
On 02/09/2012 12:24 AM, Jacob Appelbaum wrote:
> On 02/08/2012 11:47 PM, Ondrej Mikle wrote:
>> On 02/08/2012 02:59 AM, Nick Mathewson wrote:
>>> On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle wrote:
>>>
>>> I think if we want an extra field in the future, we wan
On 02/08/2012 09:09 AM, Peter Palfrader wrote:
> On Tue, 07 Feb 2012, Nick Mathewson wrote:
>
>> On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle wrote:
>>> On 02/07/2012 07:18 PM, Nick Mathewson wrote:
>>>> Like Jakob, I'm wondering why there isn't an
On 02/08/2012 02:59 AM, Nick Mathewson wrote:
> On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle wrote:
>
> I think if we want an extra field in the future, we want to put it
> after the end of the response (that is, after total_len), rather than
> having it be optionally in
On 02/07/2012 07:18 PM, Nick Mathewson wrote:
> On Sat, Feb 4, 2012 at 10:38 PM, Ondrej Mikle wrote:
>> First draft is ready here:
>>
>> https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnssec.txt
>
> Some initial comments:
>
>> DNS
On 02/07/2012 03:18 PM, Jakob Schlyter wrote:
>
> I may have missed parts of the previous discussion, but why are you not
> encapsulating the whole DNS request from the client? Various flags and other
> options (e.g. EDNS0) would be quite useful to be able to transport across the
> TOR network.
On 02/01/2012 10:01 AM, Jacob Appelbaum wrote:
>
> That sounds good. I'll wait for the first draft and send feedback.
First draft is ready here:
https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnssec.txt
Hopefully I reflected all the main points made in the DNS threads. Th
On 01/31/2012 09:35 PM, Roger Dingledine wrote:
>
> I totally agree that writing our own dnssec code would be absurd.
>
> But I'm confused here about why we're adding dns support to Tor itself.
> Are we doing it to be able to proxy more requests from applications to
> dns servers? Or are we doing
On 01/31/2012 03:42 PM, Nick Mathewson wrote:
> On Tue, Jan 31, 2012 at 1:08 AM, Jacob Appelbaum wrote:
>>
>> I think that seems OK. I think the first step is a proposal,
>
> Anybody volunteering for this, or should I throw it on my pile?
I volunteer for writing the proposal.
Ondrej
__
On 01/31/2012 05:17 PM, Watson Ladd wrote:
> I've got a more basic question: does the OP get enough information to
> validate the DNSSEC data, or does it have to trust the OR? I don't
> quite know enough to tell from the above.
I forgot to mention: validation on the client side is not finished in
On 01/30/2012 11:18 AM, Jacob Appelbaum wrote:
> On 01/30/2012 01:09 AM, Christian Grothoff wrote:
>>
>> In summary, I think begin_dns is a good idea, but I'm not sure you need
>> to then talk TCP to the nameserver -- UDP ought to suffice.
>>
>
> I think begin_dns is a good idea as well.
Seconded
On 01/30/2012 10:45 AM, Roger Dingledine wrote:
> On Thu, Jan 26, 2012 at 10:42:53PM +0100, Ondrej Mikle wrote:
>> Also, this seems to be a bug in
>> relay.c:connection_edge_process_relay_cell_not_open(), the
>> RELAY_COMMAND_RESOLVED case:
>>
>> answer_len =
On 01/30/2012 07:34 AM, Roger Dingledine wrote:
> On Thu, Jan 26, 2012 at 10:42:53PM +0100, Ondrej Mikle wrote:
>> I decided to give it a shot in implementing full DNS/DNSSEC resolution
>> support
>> for Tor, here's the branch:
>>
>> https://github.com/hivi
Hi,
I decided to give it a shot in implementing full DNS/DNSSEC resolution support
for Tor, here's the branch:
https://github.com/hiviah/tor
ATM the biggest limitation is that reply DNS packet must fit in a single cell
(i.e. max size is RELAY_PAYLOAD_SIZE).
How it's implemented:
There's new co
On 01/19/2012 11:13 PM, Nick Mathewson wrote:
> On Thu, Jan 19, 2012 at 7:39 AM, Linus Nordberg wrote:
>> Hi,
>>
>> After some interesting discussions irl last week with knowledgeable DNS
>> and security people (hi Jakob) I'd like to hear from people involved
>> with DNS in Tor what current status
39 matches
Mail list logo
