Re: [tor-dev] Namecoin .onion to .bit linking
On Tue, May 19, 2015 at 09:43:30 -0500, Jeremy Rand wrote: > One of the criticisms of Namecoin which seems to be raised sometimes > is that the current domain namespace spec doesn't have a method for a > .bit domain owner to prove that they are in control of a .onion. > (This is also an issue for .bit domains that point to .i2p.) I'm > interested in improving this situation, and am looking for feedback. > > First off, I'm curious what the various use cases are for this. The > main use case I'm aware of is if a user is aware of a .onion domain > already, and is trying to find a human-memorable way to access it. I'm not familiar with Namecoin, but I thought I'd just point out that someone will be working on OnioNS, the onion name system, as part of the SoP in Tor. The person who will be working on it just sent an e-mail to this very list yesterday. You two seem to be after the same "human-readable way to access .onion domain names" target as you yourself described, so there might be room for collaboration. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgps8KbRXSLPG.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!
On Mon, Apr 13, 2015 at 14:30:04 -0400, Nathan Freitas wrote: > We were previously using linux/arm for the PT compiling, and it mostly > worked, but it turns out there are enough small differences in the > Android API from Linux, that it does matter to target Android > specifically. This is similar to why we need the Android NDK for tor > cross-compile, and not just a generix linux ARM build. Fair enough. It would then be good to know whether android/x86 is planned for 1.5. Either way, that won't be out until july/august, so perhaps using obfsclient in the meantime is for the best. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!
On Mon, Apr 13, 2015 at 13:09:30 -0400, Nathan Freitas wrote: > > > One interesting issue is that GoLang 1.4.1, which we are using to > > > cross-compile the Meek and Obfs4 pluggable transports to Android, only > > > supports targeting Android ARM for right now... I assume that will > > > change soon, but if not, we may have to add Obfsclient back into Orbot > > > for supporting x86 devices. > > > > Hmm, maybe I should add obfs4 support to obfsclient. I have code for > > all of the crypto I would need to add. > > Let me reach out to the GoLang Android community and see what the > blocker is... I was thinking the same thing though, it wouldn't be hard > to still support Obfsclient, along with the Go-based PT's. All I could find is this: https://groups.google.com/forum/#!msg/golang-dev/BtGFDUmJX-U/YEoQz0eP4rgJ But there is no android/x86 in the current changelog for 1.5 (to be released in ~july) so I don't know. Possibly stupid question, but wouldn't a static linux/x86 binary work just fine as long as you're executing it directly? As far as I know the Android port is just for all the bindings involved in e.g. writing a game in Go that does OpenGL calls back to Android. For example, I found this bit in a blog post online: > Copy myexectuable under your Android project’s ./libs/armeabi/ folder. > If you’re targeting one of the rare x86 Android devices, build to > x86/Linux and copy the resulting binary to ./libs/x86 (and yes, you > can include both in a single APK, and it will deploy whichever one is > appropriate). But then this would mean that we wouldn't need android/arm either, since we could just use linux/arm instead :) -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Consensus diffs - Sixth report
Hello everyone, This is the sixth and last status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. Two weeks ago I had two main tasks left for the project to get to a minimal functioning state. The first was to figure out a clean way to cache old consensuses on disk. The second was to write the fetching of consensus diffs, and the corresponding serving of consensus diffs via spooling. Both of these were done, and last week I was able to launch a small local network via chutney and finally see consensus diffs be properly generated, served, fetched and applied. The hard pencils down date is tomorrow evening. I want to polish things up a bit and try to find last-minute bugs. Of course there will be quite a bit of work left once GSoC is over to get the outcome of this project included in Tor. Other than that, I'm quite happy with how the project turned out. I intend to continue contributing to Tor, at least to the extent of getting the code merged into master and fixing any bugs that may arise until it is suitable for a stable release. I'll continue pushing my work on Github [1] for now. See the "readme" branch for reference on what the consdiff-N branches mean. Regards. [1] https://github.com/mvdan/tor -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [PATCH 1/4] Remove some unused variables
Signed-off-by: Daniel Martí
---
lib/chutney/TorNet.py | 5 ++---
lib/chutney/Traffic.py | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py
index 3685ec0..9d8efd1 100644
--- a/lib/chutney/TorNet.py
+++ b/lib/chutney/TorNet.py
@@ -297,7 +297,6 @@ class LocalNodeBuilder(NodeBuilder):
"""
datadir = self._env['dir']
tor = self._env['tor']
-idfile = os.path.join(datadir,'keys',"identity_key")
cmdline = [
tor,
"--quiet",
@@ -445,9 +444,9 @@ class LocalNodeController(NodeController):
def hup(self):
"""Send a SIGHUP to this node, if it's running."""
pid = self.getPid()
-running = self.isRunning()
+running = self.isRunning(pid)
nick = self._env['nick']
-if self.isRunning():
+if running:
print "Sending sighup to %s"%nick
os.kill(pid, signal.SIGHUP)
return True
diff --git a/lib/chutney/Traffic.py b/lib/chutney/Traffic.py
index 7202c3d..57250f7 100644
--- a/lib/chutney/Traffic.py
+++ b/lib/chutney/Traffic.py
@@ -312,7 +312,6 @@ import sys
def main():
"""Test the TrafficTester by sending and receiving some data."""
DATA = "a foo is a bar" * 1000
-DATA_CORRUPT = "a foo is a baz" * 1000
proxy = ('localhost', 9008)
bind_to = ('localhost', int(sys.argv[1]))
--
Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/
PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC] Consensus diffs - Fifth report
On Sun, Aug 03, 2014 at 02:11:37 +0200, Sebastian Hahn wrote: > On 02 Aug 2014, at 21:25, Daniel Martí wrote: > > This is the fifth status report of my Google Summer of Code project, > > which is to implement consensus diffs for Tor. My mentors - Sebastian and > > Nick - and myself usually hold meetings on IRC on wednesday at 16h UTC. > > 14h UTC. Oh well, I can't math. Thanks! -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Consensus diffs - Fifth report
Hello everyone,
This is the fifth status report of my Google Summer of Code project,
which is to implement consensus diffs for Tor. My mentors - Sebastian and
Nick - and myself usually hold meetings on IRC on wednesday at 16h UTC.
As described in my last report, I have spent the past couple of weeks
integrating my work into the main Tor repository. It builds fine with
the rest, all gcc/clang warnings were solved (mostly just C89
declaration errors) and all make check-spaces warnings were also fixed.
You can see the result on the repository I created a few weeks ago on
github [1]. You want the branch 'consdiff-1', where you will find
src/or/consdiff.{h,c} and src/test/test_consdiff.c.
I also added some very basic logging, so that the public consdiff_*
functions will log what went wrong when returning NULL. I used
LD_GENERAL for now, which I assume is wrong - suggestions welcome.
I also simplified some bits for easier readability and usage, which can
be found in the commit history. But most notably, I improved the docs
and comments. The idea is to be able to stumble upon consdiff.c for the
first time and be able to understand what it does, how and why in just a
few minutes. It's hard to tell whether I did a good job at that -
criticism very much appreciated.
Most of that happened during the first week, as I was on a quick holiday
during the second. Nick gave me some pointers on how to continue with
the integration, and that's what I'll be doing in the next few days. The
first thing to do is figure out a way to store multiple consensuses on
disk, to be used to fetch and create diffs accordingly.
There are now just over two weeks left, but I am confident that I can
finish all the coding early enough to be able to test the whole thing
properly.
Regards.
[1] https://github.com/mvdan/tor
--
Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/
PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Consensus diffs - Fourth report
Hello everyone, Apologies for the delay, I'm a couple of days late. This is the fourth status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. My mentors - Sebastian and Nick - and myself usually hold meetings on IRC on wednesday at 16h UTC. On the first week I finished implementing the consensus diff headers as described in the updated proposal #140 [1], including full SHA256 hashes of each of the two consensuses involved: the base one and the resulting one. I also finished the tests for that bit. Moreover, I thought it would make sense to make sure that the diff generation process never takes too long. In theory it should always be linear in time given any two realistic consensus files, since it would navigate the router entries and take advantage of them being sorted alphabetically. But if no matching router entries are found between the two consensuses, the algorithm would run in quadratic time. Running in quadratic time over two sets of 25K lines takes about 20 seconds on my laptop, which is pretty bad. So I made the algorithm error if 10K lines are found on both sides without any matching router entry id. Which makes perfect sense for any pair of consensuses - even if you take consensuses months or years apart, it would never occur that they shared so few router ids. And if they did, generating a diff between them would make no sense. Unfortunately, I wasn't able to do much else during that week since I was at RMLL running a Free Your Android workshop for the whole week. And just when I got home on Saturday, my laptop broke down, which kept me busy for a few days as well. Nevertheless I am still on schedule. What I must do now is start merging my code into a Tor feature branch, so that I can write the bits of code that will glue everything together. To do that, I've begun rewriting my git history so that it is simpler to understand and read. If you have a look at my new repo on github [2], you'll notice that the number of commits went down from 122 to 95, and quite a few were rewritten as well. Open to suggestions about how to further improve it. By the time the next report is due - August the 1st - I should have completed the integration of my code into Tor. Then comes writing some more tests and testing Tor with the new feature in place. [1] https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/proposals/140-consensus-diffs.txt [2] https://github.com/mvdan/tor/branches -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Consensus diffs - Third report
Hello everyone, This is the thid status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. We hold weekly meetings every Wednesday at 14h UTC with the project mentors Nick and Sebastian. Two weeks ago I sent the second report, which explained how I had working versions of both the ed diff generation and application code, and that I would move on to writing tests, fixing bugs and starting the integration into Tor. And that's what I've done these past two weeks. I have restrured my codebase to make it fit into the main repository (I came up with the 'consdiff' name, so consdiff.c and consdiff.h - criticism or better names welcome). I have also started writing tests in test_consdiff.c, which are extensive but still have room for improvement. Most importantly, while writing the tests and adding assertions I found a handful of issues which are now solved. I'll try to come up with as many edge cases as I can to get rid of any remaining bugs. All the code is up on github: https://github.com/mvdan/tor_sample Our schedules this week have been difficult in part due to the tor-dev summer meeting, so not much else has happened other than my coding. Hopefully we'll be back at full speed soon! -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Consensus diffs - Second report
Hello everyone, This is the second status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. We hold weekly meetings every Wednesday at 14h UTC with the project mentors Nick and Sebastian. When I sent my first report I was a bit behind schedule as per my own timeline, mainly due to finals. These past two weeks I've been catching up on that timeline. I am now finishing the first part of it, which is to implement the diff generation code. If you read the last report, you might remember that the biggest issue at the time was performance. The code I had worked, but it was very pricy due to the quadratic time it took to compute a consensus diff, translating in running times from 10 to 20 seconds. In that e-mail I explained an idea I had in mind to overcome that. It got implemented and tested, and it works as expected. Now a diff generation between two consensus files takes roughly 0.04 seconds, which is almost the same amount of time that 'diff -e' takes. No precision seems to have been lost, but we'll have to do some edge case tests to verify that. The code was also missing documentation and some tor_asserts to make it more robust and understandable. That is what I'm finishing up at the moment, and then the tests will be the only task left. On to the second timeline item, which is the diff application code - The code sample I wrote for my application was a very simple version of it, supporting only 'delete' ed commands and just writing to stdout line-by-line. Taking that code as a starting point, plus being able to re-use some chunks from the diff generation code, I was able to have a working version in a few hours. So, like the diff generation bit, now that it seems to work properly it's time to document it properly and do some tests. I have until July 5th to finish these two tasks as per my own timeline, so I should be well able to have them done by then. The upcoming timeline item will be the joining of these chunks of code with Tor, at which point I expect some issues to arise. So I would like to get started with that bit the sooner the better, to have more time to get everything working and tested before we run out of time. As usual, any comments or ideas are very welcome. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC] Consensus Diffs - First report
I forgot a couple of things: * My code is on github at the moment: https://github.com/mvdan/tor_sample This repo contains client.c, the code sample I used for my application, and server.c, what I am currently doing as part of the timeline. * stats/stats.go in that same repo This is a chunk of code I wrote last month to try and get approximate numbers on how would consensus diffs affect the users. Following proposal 140, we wanted to see for how long would they be useful, how much transfer would be saved and if it would make sense to keep nonrunning routers in consensuses for a number of hours. I stopped writing stats.go because it was all approximated and not really of much use. I thought I'd continue it once the server side algorithm is done, at which point we can have exact numbers on how much the diffs will weigh. And then the stats will be of use to decide on the matters above. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Consensus Diffs - First report
Hello everyone, This is my first status report regarding my GSoC project, Implementing consensus diffs. We weekly meetings with Nick and Sebastian, my mentors, every Wednesday at 14h UTC, if you want to take a closer look at the project's progress or want to participate. In the application timeline I specified that I would spend the first weeks coding the server side part, which is mostly just the generation of diffs. And that's what I've been doing thus far. I'm a bit behind on schedule due to exams, but I'm not too far off. I first implemented a dynamic algorithm, quadratic in both time and space, which seemed to work fine. Of course it didn't work for consensuses, since that would mean an allocation of nearly 3GB. So the next thing I did was switching to Hirschberg's algorithm, which still takes quadratic time but only takes linear space due to a divide-and-conquer approach. But that still leaves us at a horrible 16 seconds of runtime to generate a regular microdescriptor consensus diff, whereas 'diff -d' only takes a fifth of a second. That is largely due to the fact that we're not taking advantage of the consensus properties yet. So what I will do next is improve the algorithm, which should make it very close to linear in time. The idea is to navigate the two consensuses, looking at the digests that will already be sorted for us. That's part of the 'r' line for descriptor consensuses, and the 'm' line for microdescriptor consensuses. This should take linear time. Now, the part of Hirschberg's algorithm that makes it quadratic in time is finding 'k', the column at which the problem can be split in half wihtout losing precision. This is well explained here: http://wordaligned.org/articles/longest-common-subsequence But once we are navigating the nodes ordered by digests, we can avoid having to calculate 'k'. Given that we are at any pair of matching digests, we can assume that this is already a point 'k' because all the nodes that are before the digest on the first consensus can only be found before the digest on the second consensus, and the same goes for later digests. So the final algorithm should travel both consensuses in linear time, and use our quadratic time algorithm on the small chunks between these matching digests. The quadratic time algorithm would at worst be used for maybe a couple hundred lines, a size at which it still performs fairly well. You may be wondering why I went with an O(MN) algorithm when I could have gone with the more common O(ND) algorithm, which I understand is the one used in the GNU diffutils. The main reason is the use-case. O(ND) performs worse than O(MN) when the differences are large, because then D=2N. In our case, when we are running the algorithm it's because nodes disappeared, appeared or simply to find changes in nodes that are still there. So it will be very common that we find diffs D that are very close in size to N or M. Plus, as far as I understand, the divide-and-conquer algorithm is pretty clean and easy to understand while the O(ND) algorithm by Myers would probably be harder to implement in a clean way. I'm in no way an expert in diff/lcs algorithms, so suggestions and comments are very welcome. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Revising Proposal 140
On Thu, May 01, 2014 at 09:37:12 -0400, Nick Mathewson wrote: > I think the only change we'll need for this case is to add URLs for > the microdescriptor consensus diffs. Cool. > This nice thing about this approach is that the client doesn't need to > know whether the directory supports consensus diffs. If it does, > great: it will send a diff. If not, the directory will ignore the > X-Or-Diff-From-Consensus header and just send the consensus as before. > > Clever idea? Silly idea? I think it's a neat idea - one less thing to worry about on the client side. We don't know yet whether keeping multiple consensuses will be of practical use, but we can always roll back to providing only one available consensus hash. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpEQdfPJ2QOE.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Revising Proposal 140
On Thu, May 01, 2014 at 09:27:38 -0400, Nick Mathewson wrote: > One alternative in this case would be to include non-running relays in > the consensus. This would make each individual consensus longer, but > (if your guess is right) might make compressed diffs shorter. That's an interesting idea. We could include non-running relays in the consensus for, say, half a day. I don't know how often do relays temporarily stop running, or how long do they generally do it for - I shall investigate. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpQmI8BmkVQq.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Revising Proposal 140
Hello everyone, Last week I introduced myself [0] on this list, shortly after being accepted into GSoC to work on Consensus Diffs. My GSoC proposal is heavily based on the Tor proposal #140 [1], which is close to being six years old now. This is why, after some discussion with Nick, Sebastian and Weasel (the original author of the proposal), it became obvious that it needs some revising. Here are the improvements we discussed on IRC: * Microdescriptors didn't exist back then, so the proposal makes no mention of microdescriptor consensus diffs. We should support these too. * Weasel added the 's' command just so that a line with just one dot could be produced. Since consensuses should never have such a line, I think it would be best to drop 's' and not support such a line as an input when generating the diffs. * In response to my introduction mail, Ian mentioned that fetching a diff is leaking data about when you last used Tor. Nick proposed to have a time limit on these diffs, to e.g. 24 or 36 hours, which should mitigate this problem. * Regarding their size, #140 suggests that they are not useful past 16 hours. I thought we could compare the compressed size of the diffs when creating them, since they may be of use for a longer time. We could do this relative size limit first as well as the time limit mentioned above. That is all that we came up with for now, what do you think? Ideas about what might be missing or needing an update are welcome, of course :) Regards. [0] https://lists.torproject.org/pipermail/tor-dev/2014-April/006744.html [1] https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/proposals/140-consensus-diffs.txt -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgp98OZLC9eoN.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC: Implement consensus diffs
On Tue, Apr 22, 2014 at 11:10:27 -0400, Ian Goldberg wrote: > The proposal (140) doesn't appear to discuss the client > fingerprintability aspect of this: they reveal the last time they used > Tor (if recentish). Say you're a mobile client that gets a dynamic IP > address. With this, you reveal that you probably aren't or maybe are > the same person that was last seen over there at that particular time. > > What are the implications here? As far as I understand, Tor clients fetch the consensus documents from a random authority at first, and then from caches at somewhat random times - reading from [0] at section 5.1. Since it starts using caches and building circuits after fetching the first consensus from an authority, I don't see how anyone could identify a client. Sure, a cache will know for how long has a client been disconnecten when it asks for a diff starting at e.g. yesterday. But was it that same cache who gave it the previous diff? Or are you talking about regular traffic too? I might have not understood you well - if that's the case, please explain with a bit more of detail. Anyway, downloading the entire consensus file from either an authority or a cache will always be possible, if that's what you are concerned about. But we want diffs to be usable in a secure manner just like entire consensuses are. [0] https://gitweb.torproject.org/torspec.git/blob/refs/heads/master:/dir-spec.txt -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpKixfa_1FLD.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] GSoC: Implement consensus diffs
Hello everyone, My name is Daniel and this summer I'll be working on consensus diffs [0], heavily based on proposal 140 [1]. This should allow for quicker and scalable consensus udpates, which will have more weight as the consensus grows larger. I've never gotten involved in Tor before, so I'm really looking forward to this summer. My intention is to use a simplified ed format as described on proposal 140, but I am open to alternatives and suggestions. As far as the diff creation algorithm, I plan on using a dynamic programming algorithm for the Longest Common Substring problem. Like before, comments are very welcome. I will spend the following couple of weeks looking at alternative diff formats and algorithms, rather than start coding this early. It would be appreciated if any ideas regarding any of the two aspects were posed during this time, so that afterward I can start their implementation. I will always be lurking on #tor-dev, #tor-project and #tor under the nick 'mvdan'. I am also subscribed to the tor-dev and tor-talk mailing lists. And lastly, my PGP fingerprint is below - encrypted mail is welcome :) Regards. [0] https://www.torproject.org/getinvolved/volunteer.html.en#consensusDiffs [1] https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/proposals/140-consensus-diffs.txt -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpitSPQNrbXY.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [Orbot patch] Properly skip tests when building libevent
On Thu, Mar 27, 2014 at 13:41:21 -0400, Nathan Freitas wrote: > On 03/27/2014 12:30 PM, Daniel Martí wrote: > > This fixes the remaining $(top_srcdir) errors and properly > > generates event2/event-config.h > > Thanks. Will review and integrate shortly. Great, thanks! Make sure to clean and reset the submodules completely, since your chaning of the target 'all' for 'all-am' on libevent should have definitely broken your build. It didn't, so I'm thinking that your external/libevent/include/event2/event-config.h was kept there between test builds. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpm8aggAkrDt.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [Orbot patch] Properly skip tests when building libevent
This fixes the remaining $(top_srcdir) errors and properly generates event2/event-config.h Signed-off-by: Daniel Martí --- external/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/external/Makefile b/external/Makefile index bce8d83..7a9f637 100644 --- a/external/Makefile +++ b/external/Makefile @@ -116,6 +116,8 @@ openssl-clean: # libevent libevent/Makefile: + sed -i 's@\(SUBDIRS = . include\) sample test@\1@' libevent/Makefile.am + sed -i 's@\(AC_OUTPUT(Makefile include/Makefile\) test/Makefile sample/Makefile)@\1)@' libevent/configure.in cd libevent && ./autogen.sh cp config.sub libevent cp config.guess libevent @@ -126,7 +128,7 @@ libevent/Makefile: --disable-shared libevent-build-stamp: libevent/Makefile - $(MAKE) -C libevent all-am + $(MAKE) -C libevent ./include/event2/event-config.h all-am touch libevent-build-stamp libevent: openssl libevent-build-stamp -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgp7ApV5DnQi4.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [Orbot patch] Add all /external build stamps to .gitignore, cleanup
Signed-off-by: Daniel Martí --- .gitignore | 21 - 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/.gitignore b/.gitignore index 4824f92..f3fb750 100644 --- a/.gitignore +++ b/.gitignore @@ -1,16 +1,11 @@ -external/bin/ -external/include/ -external/jtorctl-build-stamp -external/lib/ -external/libevent-build-stamp -external/obfsproxy-build-stamp -external/openssl-static-build-stamp -external/privoxy-build-stamp -external/privoxy/ -external/test.c -external/test.h.gch -external/tor-build-stamp -external/translation/ +/external/bin/ +/external/include/ +/external/*-build-stamp +/external/lib/ +/external/privoxy/ +/external/test.c +/external/test.h.gch +/external/translation/ bin gen native -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpD3ZApMYvLR.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [Orbot patch] Fix building of openssl on newer systems
This is probably due to newer auto-tools having slightly different configuration options. On a recent setup, the following occured: make[2]: arm-eabi-/opt/android-ndk/[...]/arm-linux-androideabi-gcc: Command not found It was, for some reason, making CC be arm-eabi- plus the path to the NDK. Forcing CC when running make works around this problem. --- external/Makefile | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/external/Makefile b/external/Makefile index 875fa90..0310bb2 100644 --- a/external/Makefile +++ b/external/Makefile @@ -84,17 +84,15 @@ all: assets lib/libcrypto.a: cd openssl && \ - CC="$(CC)" \ ./Configure android -DL_ENDIAN && \ - ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr make build_libs + make CC="$(CC)" ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr build_libs lib/libssl.a: cp config.sub openssl cp config.guess openssl cd openssl && \ - CC="$(CC)"\ ./Configure android -DL_ENDIAN && \ - ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr make build_libs + make CC="$(CC)" ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr build_libs openssl-build-stamp: lib/libcrypto.a lib/libssl.a touch openssl-build-stamp -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpnMk7UfDcWn.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
