<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 27, 2022 at 5:03 AM Sergey Ponomarev <<a href="mailto:stokito@gmail.com">stokito@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I’m working on a firmware for routers based on OpenWrt  and it needs<br>
Tor out of the box for NAT punching i.e. SSH and Web admin access. It<br>
will expose a Single Onion Service i.e. not "hidden" with just 3 hop<br>
for a better performance.<br></blockquote><div><br></div><div>Hi, Sergey! This sounds like a neat project.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The Tor is already ported to OpenWrt but its binary is more than 2mb.<br>
For 16mb routers this is not critical but a lot and I need to keep<br>
space.<br>
So is it possible to compile Tor without some features?<br>
As far as I understood from autoconf I can disable Relay functionality.<br>
But maybe I can also disable some admin api parts and SOCKS proxy.<br>
Also OpenWrt out of the box has WolfSSL so is it possible to compile<br>
tor with it instead of OpenSSL?<br>
<br></blockquote><div><br></div><div><div>So, you've seen the options  `--disable-module-relay` and 
`--disable-module-dirauth`, and those are the only ones there are at the moment.  We don't support WolfSSL, but you could try it out (it supposedly has an OpenSSL compatibility layer?) and see if it works.<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another problem is files sizes inside of /var/lib/tor/:<br>
     20,442 cached-certs<br>
2,303,443 cached-microdesc-consensus<br>
8,725,598 cached-microdescs.new<br>
       3,531 state<br>
<br>
I think that all these files may be minimized. E.g. cached-certs<br>
contains keys in PEM format which is just Base64 form of DER.<br>
So switching to plain DER certs can significantly reduce size.<br></blockquote><div><br></div><div>That isn't likely to happen at this point in the lifecycle of the current directory system; your best bet here is to look in to some kind of compressing filesystem.  You _might_ be able to save a little space by tinkering with the definition of TOLERATE_MICRODESC_AGE and setting it to 3 days instead of 7, but I don't know how well that would work.<br></div><div><br></div><div>I do want us to move to a world where we need a lot less storage to run a client, but that will require an implementation of the "Walking Onions" design [1], which probably won't be possible until we've got a full relay and authority implementation in Arti [2].</div><div><br></div><div>[1] <a href="https://gitlab.torproject.org/dgoulet/torspec/-/blob/master/proposals/323-walking-onions-full.md">https://gitlab.torproject.org/dgoulet/torspec/-/blob/master/proposals/323-walking-onions-full.md</a></div><div>[2] <a href="https://arti.torproject.org">https://arti.torproject.org</a><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As a side question: is it possible to make a small relay proxy that<br>
can work part time when I sleep?<br>
Imagine that each router already has a Tor. This is potentially<br>
thousands of relay nodes and all of them have a motivation to support<br>
the network which they are using themselves.<br>
<br>
But users don’t want to lose bandwidth. I see that I can set some<br>
traffic or bandwidth limits.<br>
But maybe I can write some script that will enable or disable the<br>
relay by schedule in the evening.<br>
As far I know relays must be always online so this will make the relay<br>
unstable and it won’t be used by Tor.<br>
Is it technically possible?<br></blockquote><div><br></div><div>It's a cool idea, but it's not something we support with our current design.  To deliver good performance to users, we need relays to have good, fast, reliable connections.  Having a relay that drops off the network once a day, or that changes its capabilities too frequently, doesn't really work so well (as I understand it).  This is an area where others understand the design space better, though, so maybe somebody will figure something out.</div><div><br></div><div>cheers,</div><div>-- <br></div><div>Nick<br></div></div></div>