446 lines
40 KiB
HTML
446 lines
40 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}Pages/meeting153.html{% endblock %}
|
|
{% block content %}<h3>I2P dev meeting, October 25, 2005</h3>
|
|
<div class="irclog">
|
|
<p>16:24 < jrandom> 0) hi</p>
|
|
<p>16:24 < jrandom> 1) Net status</p>
|
|
<p>16:24 < jrandom> 2) Fortuna integration</p>
|
|
<p>16:24 < jrandom> 3) GCJ status</p>
|
|
<p>16:24 < jrandom> 4) i2psnark returns</p>
|
|
<p>16:24 < jrandom> 5) More on bootstrapping</p>
|
|
<p>16:24 < jrandom> 6) Virus investigations</p>
|
|
<p>16:24 < jrandom> 7) ???</p>
|
|
<p>16:24 < jrandom> 0) hi</p>
|
|
<p>16:24 * jrandom waves</p>
|
|
<p>16:24 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/001079.html</p>
|
|
<p>16:25 * susi23 waves back</p>
|
|
<p>16:26 < jrandom> lets jump on in to 1) net status</p>
|
|
<p>16:26 < jrandom> as I mentioned, things look pretty reasonable so far. </p>
|
|
<p>16:26 <+fox> <Romster> ah meeting sweet</p>
|
|
<p>16:27 < jrandom> there is some good stuff coming down the line too, so we'll have a new release later this week</p>
|
|
<p>16:27 < jrandom> anyone have anything they want to bring up regarding 1) net status?</p>
|
|
<p>16:27 <@cervantes> omg 7 issues</p>
|
|
<p>16:27 <+legion> yup looking good :-)</p>
|
|
<p>16:27 < jrandom> busy week cervantes :)</p>
|
|
<p>16:28 <@cervantes> can only be good</p>
|
|
<p>16:28 <+Complication> Works relatively well, dev.i2p even - I can even pull CVS checkouts without EOF messages.</p>
|
|
<p>16:28 < jrandom> nice :)</p>
|
|
<p>16:28 <+Complication> Might have been release-related overloads, those last ones.</p>
|
|
<p>16:28 <+Complication> But I can't tell.</p>
|
|
<p>16:28 < jrandom> dev.i2p is on the latest build code too (-7), so it'll be hopefully performing substantially better than before</p>
|
|
<p>16:29 < jrandom> s/dev.i2p/cvs.i2p (etc)/</p>
|
|
<p>16:29 <+legion> forums.i2p also seems to be much better than before :)</p>
|
|
<p>16:29 <@cervantes> *ahem*</p>
|
|
<p>16:29 <+fox> <Romster> is i2p safe to let others join etc?</p>
|
|
<p>16:29 <+Ragnarok> ok, now I've got to try this miraculous "cvs checkout that works the first time"</p>
|
|
<p>16:30 <+fox> <Romster> since there is no known limits now</p>
|
|
<p>16:30 <@cervantes> that's because everyone's hammering i2p-list instead of posting to the forum </p>
|
|
<p>16:30 <+legion> hmm you sure cervantes?</p>
|
|
<p>16:30 < jrandom> Romster: well, we've been growing at a pretty good pace lately, but we should hold off on public beta until 0.6.2</p>
|
|
<p>16:30 < jrandom> heh cervantes ;)</p>
|
|
<p>16:30 < jrandom> hush Ragnarok, you'll jinx it!</p>
|
|
<p>16:31 <+Ragnarok> wow... it's true. I'm speechless</p>
|
|
<p>16:31 <+fox> <Romster> k jrandom</p>
|
|
<p>16:31 < jrandom> (man my eyes are watering from the curry my roomates are cooking downstairs)</p>
|
|
<p>16:31 < jrandom> nice1 Ragnarok </p>
|
|
<p>16:32 <+fox> <Romster> lol now that's a strong curry</p>
|
|
<p>16:32 < jrandom> ok, if there's nothing else on 1), we can jump quickly through 2) Fortuna integration</p>
|
|
<p>16:32 < jrandom> (true that Romster)</p>
|
|
<p>16:32 <+fox> <shardy> yay for fortuna integration!</p>
|
|
<p>16:32 <+fox> <Romster> moving onto 2) :P</p>
|
|
<p>16:32 <+fox> <Romster> what is fortuna?</p>
|
|
<p>16:32 < jrandom> heh thought you'd like that shardy :)</p>
|
|
<p>16:32 <+fox> <Romster> i've been a bit behind the last month</p>
|
|
<p>16:32 <+Complication> PRNG algo, if I remember.</p>
|
|
<p>16:33 <+Complication> Supposedly a good one, or so they write. :P</p>
|
|
<p>16:34 * Complication knows nothing about its inner workings, though</p>
|
|
<p>16:34 < jrandom> shardy: I'd love if you could give it a look sometime</p>
|
|
<p>16:34 <+fox> <shardy> of course</p>
|
|
<p>16:34 <+fox> <shardy> you're using the gnu implementation?</p>
|
|
<p>16:34 < jrandom> Romster/Complication: there are some links in the email</p>
|
|
<p>16:34 < jrandom> yeah shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java</p>
|
|
<p>16:35 < jrandom> (integrated with http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java )</p>
|
|
<p>16:36 < jrandom> we vary from the straight gnu-crypto implementation though, since we've already got AES256 and SHA256 code (Cryptix's and Bouncycastle's, respectively)</p>
|
|
<p>16:36 < jrandom> ok, anyway, this looks cool, as we've been hacking through getting that support in there for probably a year now</p>
|
|
<p>16:37 < jrandom> (fortuna integration was one of the main projects driving smeghead to build 'pants' ;)</p>
|
|
<p>16:37 < jrandom> if anyone has any questions/comments/concerns about it, please bounce 'em to the list</p>
|
|
<p>16:37 < jrandom> (or email, or forum, of course)</p>
|
|
<p>16:38 <+fox> <Romster> yeah where is smeghead hes not been around for awhile now</p>
|
|
<p>16:38 < jrandom> smeghead is [redacted] doing [redacted]</p>
|
|
<p>16:39 < jrandom> ok, moving on to 3) GCJ status</p>
|
|
<p>16:39 < jrandom> i2p works on GCJ! [w00t!]</p>
|
|
<p>16:39 <+susi23> nice job</p>
|
|
<p>16:39 <+legion> sweet</p>
|
|
<p>16:39 < jrandom> at least, it does on GCJ 4.0.2 on linux 2.6.12. I haven't tried any other platforms</p>
|
|
<p>16:40 < jrandom> yeah, the GCJ and GNU Classpath folks have worked wonders</p>
|
|
<p>16:40 < jrandom> it was really easy to get it building, the old static reference classes I remember weren't necessary</p>
|
|
<p>16:41 <+Complication> Which sounds quite positive, given Sun Java's less-than complete openness (with regard to distribution, if I remember correct).</p>
|
|
<p>16:41 < jrandom> there's a makefile shipped with I2P now, though for simplicity, I think we'll probably stick with distributing pure java, at least primarily</p>
|
|
<p>16:41 <+susi23> (next we try to run it on J2ME ;)</p>
|
|
<p>16:42 <+fox> <Romster> GCJ to take over Suns JVM></p>
|
|
<p>16:42 < cat-a-puss> how is preformance with GCJ?</p>
|
|
<p>16:42 < jrandom> aye, though sun is entirely open, and we /could/ distribute their JVM along side I2P, but their license prohibits distributing their JVM as a general purpose tool</p>
|
|
<p>16:42 < jrandom> cat-a-puss: comparable</p>
|
|
<p>16:42 < jrandom> most of the heavy work in i2p is already done by assembler code ;)</p>
|
|
<p>16:43 <+fox> <Romster> how would i2p go with C#/mono again with that jave to C# adition (forgot it's name)</p>
|
|
<p>16:43 <+fox> <Romster> i remember jrandom and i both tryed it out ages ago</p>
|
|
<p>16:43 < jrandom> no idea. but if it works with gcj, it might work with ikvm - the mono jvm thing</p>
|
|
<p>16:44 <+Ragnarok> IKVM</p>
|
|
<p>16:44 <+Ragnarok> nm</p>
|
|
<p>16:44 <+fox> <Romster> ah tahts the one ikvm</p>
|
|
<p>16:44 <+fox> <Romster> much difereances with GCJ and IKVM and Sun's?</p>
|
|
<p>16:45 < jrandom> i've never used ikvm</p>
|
|
<p>16:45 <+fox> <Romster> i'm sure you have once with mono or was that eclipse?</p>
|
|
<p>16:45 <+fox> * Romster shrugs</p>
|
|
<p>16:45 < jrandom> and i2p as shipped doesn't currently support the router console, though it does support the router operation, i2ptunnel, and sam</p>
|
|
<p>16:46 <+Ragnarok> what's blocking the router console?</p>
|
|
<p>16:47 <+susi23> xerces, when I remember correctly</p>
|
|
<p>16:47 < jrandom> xerces stuff. the xercesImpl shipped with i2p has sun.* dependencies, and when I naively tried to drop in the latest xerces, getting that and jdom and rome and the rest of jetty GCJed was b0rking</p>
|
|
<p>16:47 < jrandom> there are some additional requirements of the latest xerces, it seems</p>
|
|
<p>16:48 < jrandom> (for jar files we don't currently ship). however, I'm sure we can track it down</p>
|
|
<p>16:49 <+fox> <Romster> jrandom is good at tracking down problems :)</p>
|
|
<p>16:49 < jrandom> even better at making problems</p>
|
|
<p>16:49 <+fox> * Romster featches a coffee</p>
|
|
<p>16:49 < jrandom> ok, anything else on 3) GCJ status?</p>
|
|
<p>16:49 < jrandom> or shall we move on to 4) i2psnark</p>
|
|
<p>16:50 < jrandom> consider us moved</p>
|
|
<p>16:50 < jrandom> ok, i2psnark is back (yay)</p>
|
|
<p>16:51 < jrandom> not much I have to add to whats in the mail... you have anything Ragnarok?</p>
|
|
<p>16:51 <+Ragnarok> nope</p>
|
|
<p>16:51 <+susi23> regarding web frontend</p>
|
|
<p>16:51 <+Ragnarok> more testing would be nice though, so everyone should try it :)</p>
|
|
<p>16:52 <+susi23> supporting it with susibt shouldn't be a problem</p>
|
|
<p>16:52 < jrandom> ooh give us the scoop susi23 :) </p>
|
|
<p>16:52 < jrandom> nice</p>
|
|
<p>16:52 <+fox> <jme___> naive question, why spending time supporting old bt client while other (azureus) support full blown client ?</p>
|
|
<p>16:52 < jrandom> jme___: azureus *is* kickass</p>
|
|
<p>16:52 <+susi23> major release of susibt is scheduled for november :)</p>
|
|
<p>16:53 < jrandom> heh cool susi23 </p>
|
|
<p>16:53 <+Complication> To me, Azureus seemed terribly complex.</p>
|
|
<p>16:53 <+Ragnarok> azureus blows monkey chunks</p>
|
|
<p>16:53 <+susi23> for me, I always need a headless solution</p>
|
|
<p>16:53 <+Ragnarok> not to put too fine a point on it</p>
|
|
<p>16:53 <+fox> <jme___> ok :)</p>
|
|
<p>16:53 < jrandom> jme___: azureus is a bit heavyweight though, but is a great general purpose bt solution</p>
|
|
<p>16:53 <+Complication> (I personally could see the day I'd misconfigure something in it, and dent my anonymity.)</p>
|
|
<p>16:54 <+fox> <jme___> it make sense, just wanted to know</p>
|
|
<p>16:54 <+fox> <Romster> to me azerious never workd well i've moved to bitlord which does work</p>
|
|
<p>16:54 < jrandom> i do still plan on helping further improve the azneti2p plugin with the azureus folks, but i2psnark took literally less than 2 hours before I was swarming data</p>
|
|
<p>16:54 <+legion> Yeah azureus is just too big and complicated for i2p</p>
|
|
<p>16:54 <+Complication> If the goal is bundling a bt client along with i2p, a lightweight client sounds best.</p>
|
|
<p>16:54 <+fox> <Romster> KISS principal</p>
|
|
<p>16:54 <+Ragnarok> I like the official client best, but i2psnark has the major advantage of being simple enough for me to hack on</p>
|
|
<p>16:55 <+legion> thing is i2p doesn't need a heavyweight bittorrent client</p>
|
|
<p>16:55 < jrandom> yeah, its really clean code (with oddball gnu formatting ;)</p>
|
|
<p>16:55 <+Ragnarok> damn gnu</p>
|
|
<p>16:55 <+Ragnarok> worst brace style ever</p>
|
|
<p>16:55 < jrandom> heh</p>
|
|
<p>16:55 <+fox> <Romster> heh code reformatter :)</p>
|
|
<p>16:55 <+Ragnarok> jrandom won't let me :)</p>
|
|
<p>16:55 <+Ragnarok> well, for good reason</p>
|
|
<p>16:55 <+fox> <jme___> independance and simplicity are criteria i definitly agree with</p>
|
|
<p>16:56 <+fox> <Romster> will there be options to enable the bt-torrent program on each i2p node?</p>
|
|
<p>16:56 < jrandom> aye, it'd be nice if we can backport multitorrent, piece selection, and web capacity to mjw's mainline snark</p>
|
|
<p>16:56 <+Ragnarok> the simpler it is, the more likely it will be maintained</p>
|
|
<p>16:56 < jrandom> exaaactly Ragnarok </p>
|
|
<p>16:57 <+legion> yeah backporting those would be killer</p>
|
|
<p>16:57 <+fox> <Romster> as a OT point here take a look at emules KAD network i think it's rather neat.</p>
|
|
<p>16:57 < jrandom> Romster: its now shipped with the build by default, but once we get it into susibt, it'll be on the top nav with the rest of the clients</p>
|
|
<p>16:58 <+Ragnarok> we need to be able to ship a .torrent maker as well, though. And a tracker would be nice.</p>
|
|
<p>16:58 < jrandom> yeah, actually, snark has both of those, I just disabled them because i didn't want to maintain 'em :)</p>
|
|
<p>16:58 <+legion> hmm good point ragnarok</p>
|
|
<p>16:58 < jrandom> but getting them back in wouldn't be much trouble</p>
|
|
<p>16:59 <+Ragnarok> well, the torrent maker at least shouldn't be that bad</p>
|
|
<p>16:59 < jrandom> there's a Tracker.java too, and handling in the PeerAcceptor, but I threw out what wasn't necessary, so one would probably want to look back at http://klomp.org/snark/ for those</p>
|
|
<p>17:00 < jrandom> (and review http://dev.i2p/~jrandom/snark_diff.txt for changes)</p>
|
|
<p>17:00 <+fox> <Romster> since snarik is back it'll get worked on right :)</p>
|
|
<p>17:00 <+legion> actually when it comes to a tracker, it'd be better to come up with a distributed solution</p>
|
|
<p>17:00 <+fox> <Romster> snark*</p>
|
|
<p>17:00 < jrandom> porting code is easier than building a new distributed tracker legion ;)</p>
|
|
<p>17:00 <+fox> <Romster> legion, your your talking</p>
|
|
<p>17:00 <+legion> true, that</p>
|
|
<p>17:01 < jrandom> but I wouldn't be opposed to integrating a nice clean maintained anonymity-friendly distributed tracker solution :)</p>
|
|
<p>17:01 <+fox> <Romster> could be tacked onto the eepsites?</p>
|
|
<p>17:01 * jrandom spots a flying pony go past the window</p>
|
|
<p>17:01 <+Ragnarok> the official bt client has a kademlia based distributed tracker, but obviously that's only good as a design reference</p>
|
|
<p>17:01 <+legion> a place to start ;)</p>
|
|
<p>17:02 <+fox> <Romster> actually kademlia = emules KAD netowrk? hmm, if that's the case KAD would be ideal for a tracker but bootstraping is an issue</p>
|
|
<p>17:03 <+Ragnarok> they're based on the same algorithm, but they're not in any way compatable</p>
|
|
<p>17:03 <+Ragnarok> compatible, even</p>
|
|
<p>17:04 <+Ragnarok> doing something like emule's KAD for i2phex would be sort of interesting...</p>
|
|
<p>17:04 <+Ragnarok> anyway, flying ponies</p>
|
|
<p>17:04 < jrandom> :)</p>
|
|
<p>17:04 < jrandom> (agreed on both counts)</p>
|
|
<p>17:04 < jrandom> ok, anything else on 4) i2psnark?</p>
|
|
<p>17:05 <+Ragnarok> as long as we have something to make .torrent files, the existing trackers are fine</p>
|
|
<p>17:05 < jrandom> thats a good point - there's some commented out code in Snark's main I believe</p>
|
|
<p>17:05 <+legion> no I think the existing trackers are not fine :(</p>
|
|
<p>17:05 < jrandom> whats wrong with them legion?</p>
|
|
<p>17:05 < cat-a-puss> don't just hand uesrs a torrent file ether</p>
|
|
<p>17:05 <+legion> often have trouble accessing them</p>
|
|
<p>17:06 < jrandom> hmm cat-a-puss? oh, you mean, we need to get a web interface to transparently swarm?</p>
|
|
<p>17:06 <+legion> sites get flooded with traffic</p>
|
|
<p>17:06 < jrandom> ah, thats i2p's issue, hopefully 0.6.1.4 will improve that</p>
|
|
<p>17:06 < jrandom> postman was telling me how he was getting tons of hits @ tracker.postman.i2p</p>
|
|
<p>17:06 < jrandom> i forget the #s offhand</p>
|
|
<p>17:06 < cat-a-puss> If we are handling both the swarming code and the code to get the torrent in the first place, might as well make it transparent for the user</p>
|
|
<p>17:07 < jrandom> orion.i2p/bt/ isn't really used though</p>
|
|
<p>17:07 < jrandom> (and tracker-fr seems lively)</p>
|
|
<p>17:07 <+susi23> with susibt I hope to include trackers rss feed, so you don't need to go on the trackers webpage anymore but get the torrents downloaded automatically :)</p>
|
|
<p>17:07 < cat-a-puss> also prevents confusing an i2p torrent with a non-anonymous one</p>
|
|
<p>17:07 <+fox> <jme___> http tracker for bt doesnt scale due to poorely designed protocol</p>
|
|
<p>17:07 <+fox> <Romster> router watchdog router hung hard restart wtf</p>
|
|
<p>17:07 <+legion> right, which is my point some trackers are flooded while others are idle</p>
|
|
<p>17:07 < jrandom> cat-a-puss: ah, yeah I'd love to integrate hooks from syndie into susibt :)</p>
|
|
<p>17:07 <+fox> <jme___> it can be easily fixed but break the compatibility with official bt protocol</p>
|
|
<p>17:08 <+fox> <jme___> it is the road followed by the dht tracker stuff</p>
|
|
<p>17:08 < jrandom> (and the other way around, so people can easily syndicate .torrent files, etc)</p>
|
|
<p>17:08 <+Complication> Romster: I get those, but the machine I get them on is borderline (300 MHz)</p>
|
|
<p>17:08 <+fox> <Romster> the distributed tracker is the solution to hammered trackers</p>
|
|
<p>17:08 < jrandom> legion: that can easily be remedied by people using different trackers :)</p>
|
|
<p>17:08 <+fox> <Romster> azerius DHT</p>
|
|
<p>17:08 < jrandom> code is expensive, using different URLs is cheap</p>
|
|
<p>17:08 <+legion> yeah, but they don't seem to be doing that do they?</p>
|
|
<p>17:09 < jrandom> but, yes, a distributed tracker would be great. not on my roadmap though, but if someone gets it going, that would Rule.</p>
|
|
<p>17:09 <+Complication> In due time... surely someone can go distributed too.</p>
|
|
<p>17:09 <+legion> Instead of of posting torrents to tracker sites, they could post a bith and whatever details to their eepsite.</p>
|
|
<p>17:10 < jrandom> bith == hash?</p>
|
|
<p>17:10 <+legion> yeah, stands for bittorrent hash, not my term</p>
|
|
<p>17:10 <+Complication> In the beginning, though... a simple and solid client, in Java, bundled with the router... can solve many problems. (Perhaps even pull signed updates without overloading dev.i2p.)</p>
|
|
<p>17:11 <+legion> yeah, that would be great</p>
|
|
<p>17:11 < jrandom> aye Complication </p>
|
|
<p>17:11 <+fox> <Romster> yeah torrent updates</p>
|
|
<p>17:11 <+fox> <Romster> ok next item ont he list :)</p>
|
|
<p>17:12 < jrandom> ok, 5) more on bootstrapping</p>
|
|
<p>17:12 <+legion> yeah lets move on</p>
|
|
<p>17:12 < jrandom> lots of interesting stuff on the list as of late, and no way am i going to summarize it all here :)</p>
|
|
<p>17:12 <+fox> <Romster> bootstraping the i2p router database?</p>
|
|
<p>17:12 < jrandom> anyone have any questions/comments/concerns they want to discuss about the thread?</p>
|
|
<p>17:12 < jrandom> Romster: see the list and/or email</p>
|
|
<p>17:12 <+fox> * Romster needs to read that list</p>
|
|
<p>17:13 < jrandom> aye, there's good stuff on there :)</p>
|
|
<p>17:13 <+fox> <Romster> i've been rather busy laterly</p>
|
|
<p>17:13 <+Complication> 26 messages to read through, can't comment yet</p>
|
|
<p>17:13 < jrandom> still no end result, but we're looking towards a new way of building tunnels for 0.6.2</p>
|
|
<p>17:14 <+fox> <Romster> a new way, is there a flay in the current method?</p>
|
|
<p>17:14 <+fox> <Romster> flaw*</p>
|
|
<p>17:14 < jrandom> Michael's analysis shows the attack is not really a problem now, as there are easier attacks on the alternatives</p>
|
|
<p>17:14 < jrandom> read the list ;)</p>
|
|
<p>17:14 <+fox> <Romster> arg later</p>
|
|
<p>17:14 <+fox> <Romster> this is now :)</p>
|
|
<p>17:15 <+fox> <Romster> i'm noramlly asleep at this time.</p>
|
|
<p>17:15 <+fox> <Romster> so i rearly get to be at a meeting</p>
|
|
<p>17:16 < cat-a-puss> can you post your ideas for a new way / existing / rejected ways in an email to the list so we can compare</p>
|
|
<p>17:16 <+fox> <Romster> so its todo with attack methods and tunnel creation i assume, without reading the list yet</p>
|
|
<p>17:16 < cat-a-puss> (that's for Jrandom)</p>
|
|
<p>17:16 < jrandom> cat-a-puss: i'm not sure if we've really hashed out an end result yet</p>
|
|
<p>17:16 <+fox> <Romster> be an idea cat-a-puss</p>
|
|
<p>17:17 <+Complication> Romster: yes, it was more-or-less about giving the endpoint of an exploratory tunnel less influence as a possible attacker</p>
|
|
<p>17:17 < jrandom> but http://dev.i2p.net/pipermail/i2p/2005-October/001073.html is the latest for what I see coming out of your suggestion</p>
|
|
<p>17:17 < jrandom> well, not influence - i2p is a free route mixnet - but less information</p>
|
|
<p>17:18 <+Complication> Yes, that would likely be a more correct term</p>
|
|
<p>17:18 < jrandom> (the above linked url is full of arm waving, no solid crypto figured out yet)</p>
|
|
<p>17:18 <+fox> <Romster> lesss = better for more robustness agenst attacks, i get what your geting at</p>
|
|
<p>17:18 < jrandom> ((but i think its all doable with existing techniques)</p>
|
|
<p>17:19 < jrandom> Romster: here's a plot of Michael's attack against the existing algorithm, with the X axist saying what % of the network is compromised - http://dev.i2p.net/~jrandom/fraction-of-attackers.png</p>
|
|
<p>17:20 < jrandom> (plain telescopic building would be off the chart before hitting x=200)</p>
|
|
<p>17:20 < jrandom> ((so what we have now is literally orders of magnitude better))</p>
|
|
<p>17:20 < jrandom> but we can improve upon that further</p>
|
|
<p>17:21 < jrandom> though there's also the garlic routing alternative too</p>
|
|
<p>17:21 < jrandom> anyway, yeah, more things to be hashed out, keep an eye on the list :)</p>
|
|
<p>17:21 <+fox> <Romster> ok i'll have a good read of that list later</p>
|
|
<p>17:22 <+fox> <Romster> and see if i can think of anything too add</p>
|
|
<p>17:22 < jrandom> cool</p>
|
|
<p>17:22 < cat-a-puss> would the "new" telescopic method be fast enough to do on demand construction?</p>
|
|
<p>17:22 < jrandom> I'm not sure we want that</p>
|
|
<p>17:22 < jrandom> its the O(1) vs O(N) issue</p>
|
|
<p>17:23 < jrandom> the new technique would allow tunnel creation without using the exploratory tunnels, leavng the exploratory tunnels for netDb operation </p>
|
|
<p>17:23 < jrandom> (and for exploratory tunnel creation :)</p>
|
|
<p>17:24 <+fox> <Romster> hrmm would it be worthwhile screwing with the hackers by givving them heaps of false positives thereby masking the real source</p>
|
|
<p>17:24 <+legion> sounds good :)</p>
|
|
<p>17:24 <+legion> I'd think some screwing like that would be good</p>
|
|
<p>17:24 < cat-a-puss> jrandom: right, I was asking if doing do would speed things up enough, so that sometimes that last hops don't know they are the last hop, as disguesed on list.</p>
|
|
<p>17:25 <+fox> <Romster> exploratory tunnels to collect netDB router refereances?</p>
|
|
<p>17:25 < jrandom> romster: we are the hackers ;) but yeah, if the false positives overwhelmed the true positives, it'd require substantially large number of attacks to get statistically significant data</p>
|
|
<p>17:26 < jrandom> hmm right cat-a-puss, but I'm not sure how that'd speed things up though, it'd move us from an O(1) to O(N) tunnel topology</p>
|
|
<p>17:26 < jrandom> or what do you mean by speed things up?</p>
|
|
<p>17:26 <+fox> <Romster> and if it got to the point of being detected it could then drop off and go silent forawhile?</p>
|
|
<p>17:26 < jrandom> using the new technique would reduce the failed tunnel creations, certainly</p>
|
|
<p>17:26 <+fox> <Romster> or mistearly change it's key and continue or something heh</p>
|
|
<p>17:26 < jrandom> romster: it'd probably be worth digging through the mails to review the attack ;)</p>
|
|
<p>17:27 <+fox> <Romster> yeah after sleep</p>
|
|
<p>17:27 <+Complication> Romster: afaik, it's a passive attack mostly, so the target can't detect it occurring</p>
|
|
<p>17:27 <+fox> <Romster> and fixing a friends pc i got sitting here</p>
|
|
<p>17:27 <+fox> <Romster> ah ic complication.</p>
|
|
<p>17:27 < cat-a-puss> jrandom: I'm not talking about the O(n) thing. I mean just waiting to construct a client tunnel until we need one for some apps, rather than just having them sit there all the time. </p>
|
|
<p>17:28 <+Complication> (but I might be wrong, and those last 26 messages might have active components)</p>
|
|
<p>17:28 <+fox> <Romster> would a long term passive attack evently find the target?</p>
|
|
<p>17:28 <+fox> <Romster> i'll comment after i've read the list</p>
|
|
<p>17:28 < jrandom> ah cat-a-puss, we'll certainly improve the tunnel pooling for 0.6.2. we currently only build the tunnel when we need it (giving ourselves a little time in case the creation fails)</p>
|
|
<p>17:28 <+Complication> Romster: well, persisting the attack beyond tunnel lifetime would require resources and patience</p>
|
|
<p>17:28 <+fox> <Romster> and understand it better</p>
|
|
<p>17:29 <+Complication> But time plays a part in every probability of success. You try long, you get more chances.</p>
|
|
<p>17:29 <+fox> <Romster> ah that's the idea tunnel life tiem be too short to actually have a worthwhile attack work.</p>
|
|
<p>17:29 < jrandom> each pool has a defined number of backup tunnels, and we by default build replacements between 60-120 seconds before an old one expires</p>
|
|
<p>17:29 <+fox> <Romster> time*</p>
|
|
<p>17:30 < jrandom> right Complication - each sample occurs only 'm' times every (c/n) tunnels</p>
|
|
<p>17:30 <+fox> <Romster> there is no interaction between each tunnel to gather stastics?</p>
|
|
<p>17:30 <+fox> <Romster> as one is about to die and another is being built</p>
|
|
<p>17:31 < jrandom> romster: the new tunnels do not talk to each other, no, but thats not the attack Michael has been describing</p>
|
|
<p>17:31 < jrandom> there are countless attacks out there, most of which we have dealt with, but whenever someone comes up with one that may have a bearing on I2P's operation, we want to analyze it further</p>
|
|
<p>17:31 <+fox> <Romster> must read the list, ok i'll leave it at that for now, anyone else got anything to say?</p>
|
|
<p>17:32 < jrandom> ok, if there's nothing else, lets move on to 6) virus investigations</p>
|
|
<p>17:32 <+fox> <Romster> actually one stastic i can see could be gathered is no 0 hop would mean that the next hop is not the end point so it could be ruled otu but with millions of nodes that analying technique would be useless</p>
|
|
<p>17:33 < jrandom> I don't have anything to add beyond whats been discussed on the forum</p>
|
|
<p>17:33 < jrandom> right Romster, there are predecessor attacks on tunnel length, which is one of the main things we're addressing in 0.6.2</p>
|
|
<p>17:33 <+fox> <Romster> virus, what virus, if it's linux it'll be nonexistant, but windows hmmm</p>
|
|
<p>17:34 <+Complication> Well, although I couldn't build a matching binary (hell knows hy) the final difference was small enough... to hopefully be useful to anyone interested in reading assembly code.</p>
|
|
<p>17:34 < jrandom> Romster: please, the weekly status notes should explain these agenda items, and the meeting is to discuss things /beyond/ whats in the notes ;)</p>
|
|
<p>17:35 <+Complication> I sure couldn't find anything obvious in there, but nor could I explain away all the difference.</p>
|
|
<p>17:35 <@cervantes> rtfml and rtff</p>
|
|
<p>17:35 <+fox> <Romster> yeah i haven't been upto speed for quite awhile, sorry about taht jrandom</p>
|
|
<p>17:35 <@cervantes> ;-)</p>
|
|
<p>17:35 < jrandom> aye, the fact that both a known safe bat file and the old one triggered the same detection code is substantial</p>
|
|
<p>17:35 <+Complication> Yes, that sort of eases doubts.</p>
|
|
<p>17:36 <+Complication> I guess the QBFC might have undocumented differences within the same version number (different builds?)</p>
|
|
<p>17:37 * jrandom has no idea, but its possibly just some OS interaction, or whatever. I don't know, you've put up enough analysis for people to make their own informed decision</p>
|
|
<p>17:37 <+Complication> I think it's better that way.</p>
|
|
<p>17:37 <+Complication> Disassembly is really notably outside my usual playground.</p>
|
|
<p>17:37 < jrandom> legion: is there anything you want to mention about this, or should people just go through the forum if they want more info?</p>
|
|
<p>17:38 <@cervantes> can I just re-iterate what others have said on the forum, and thank Complication for the time and maticulous attempts he's put in to checking this issue out</p>
|
|
<p>17:38 < jrandom> aye, its much appreciated</p>
|
|
<p>17:38 <+legion> I've nothing to add, I feel that I've said way too much about it already</p>
|
|
<p>17:39 < jrandom> 'k understood. ok, anyone else have anything to bring up on this, or shall we move on to 7) ???</p>
|
|
<p>17:39 < jrandom> [consider us moved]</p>
|
|
<p>17:40 <+fox> * Romster seconds that :)</p>
|
|
<p>17:40 <+legion> ok for 7)??? how about we take a moment to discuss i2phex</p>
|
|
<p>17:40 < jrandom> cool, good idea</p>
|
|
<p>17:40 <+fox> <Romster> since i'm using it right now even :)</p>
|
|
<p>17:40 <@cervantes> no no group hug first</p>
|
|
<p>17:40 < jrandom> redzara mentioned he was going to be at the meeting, but progress on the merge is going slow</p>
|
|
<p>17:41 <+legion> susi23 inquired about a headless version</p>
|
|
<p>17:41 < jrandom> ah cool, i saw your post on that</p>
|
|
<p>17:41 <+fox> <Romster> might i add the favourites list needs to be wider to cope with the longer i2p keys</p>
|
|
<p>17:42 <+susi23> (that's no must, I was just curious about it)</p>
|
|
<p>17:42 < jrandom> well, no one can remember base64 keys, so I'm not sure if you're missing much Romster ;)</p>
|
|
<p>17:42 < jrandom> (and the first few bytes should be enough to uniquely identify them)</p>
|
|
<p>17:42 <+fox> <Romster> starting i2phex with a server is the major problem i see so far</p>
|
|
<p>17:42 <+legion> Actually I'd like to see only like the first 12 characters of keys to displayed in the client</p>
|
|
<p>17:42 <+fox> <Romster> heh guess</p>
|
|
<p>17:42 * Complication is regrettably majorly busy, and can't do no xml-rpc</p>
|
|
<p>17:43 < jrandom> seems reasonable legion </p>
|
|
<p>17:43 <+fox> <Romster> what about display as many characters to make the key unique</p>
|
|
<p>17:43 < jnymo_> I'm having good results with i2phex</p>
|
|
<p>17:44 < jrandom> cool jnymo_, i've been hearing good things too</p>
|
|
<p>17:44 <+fox> <Romster> so if 2 keys start with abc it'll be abcx</p>
|
|
<p>17:44 < jnymo_> 12 identical characters isn't likely, romster</p>
|
|
<p>17:44 <+fox> <Romster> true</p>
|
|
<p>17:44 <+Complication> Besides, simpler = quicker</p>
|
|
<p>17:44 <+fox> <Romster> but wouldnt need 12 if the keys are that far randomised</p>
|
|
<p>17:45 <+Complication> (not that there is much speed to gain from displaying things)</p>
|
|
<p>17:45 <+legion> Well maybe there could be a new host properties window, stating the full key and certain information like how much it is sharing and whatever</p>
|
|
<p>17:45 <+susi23> (netdb works great with 4 chars only for router ids)</p>
|
|
<p>17:45 <+fox> <Romster> or the database and using the keyname=base64 and only displaying the keyname</p>
|
|
<p>17:45 < jrandom> hmm, i thought there was already a peer info display legion?</p>
|
|
<p>17:46 < jrandom> legion: some things like that would be good to add to the mainline phex, most likely?</p>
|
|
<p>17:46 <+legion> hmm could be right...</p>
|
|
<p>17:46 < jrandom> (that way Gregor can maintain it ;)</p>
|
|
<p>17:46 <+Complication> Well, there's a "Browse host" function, but that may not be the exact same thing. (If it works.)</p>
|
|
<p>17:46 < jrandom> Complication: it does</p>
|
|
<p>17:46 < jrandom> (work, that is)</p>
|
|
<p>17:47 <+Complication> Seems to basically drop the host destkey into the search box</p>
|
|
<p>17:47 <+Complication> ...and runs a search.</p>
|
|
<p>17:48 < jnymo_> this may be an i2phex mainline issue, but I didn't see an ETA on i2phex downloads</p>
|
|
<p>17:48 <+Complication> Hmm... or actually, doesn't run a search.</p>
|
|
<p>17:48 <+Complication> Mine seems to wait until I manually start it.</p>
|
|
<p>17:48 <+fox> <Romster> whats the nearby i2phex running tickbox for?</p>
|
|
<p>17:49 <+legion> I see where there is plenty of room for improvement. ;)</p>
|
|
<p>17:49 < jrandom> yep :)</p>
|
|
<p>17:50 < jrandom> lots to be done, and the forum is a good place to post up ideas/suggestions/questions(/patches :)</p>
|
|
<p>17:50 <+fox> <Romster> despite it's ovous name</p>
|
|
<p>17:50 < jrandom> ok, anyone have anything else for the meeting?</p>
|
|
<p>17:50 <+fox> <Romster> hmm good point</p>
|
|
<p>17:50 <+fox> <Romster> can't think of anything else</p>
|
|
<p>17:51 <+fox> <Romster> but anyone working on a distributed data store?</p>
|
|
<p>17:51 * cervantes checks his watch</p>
|
|
<p>17:51 <+fox> <Romster> like activtely</p>
|
|
<p>17:51 < jrandom> Romster: beyond syndie, no</p>
|
|
<p>17:51 < jrandom> (not to my knowledge, at least)</p>
|
|
<p>17:52 <+legion> well I was wondering about integrating a http download manager into i2p, would make downloading larger content from eepsites easier.</p>
|
|
<p>17:52 <+fox> <Romster> q and iphex and one or 2 others but i've not seen anything mentained for awhile now</p>
|
|
<p>17:52 <@cervantes> what's the status of feedspace...I haven't heard aught of it in a while</p>
|
|
<p>17:52 < jrandom> legion: that would be cool - there's a post about that on the forum too i think</p>
|
|
<p>17:53 <+fox> <Romster> ah feedspace another one</p>
|
|
<p>17:53 < jnymo_> if this was mentioned in the meeting already, nm.. but, is there news on i2p freenet colab?</p>
|
|
<p>17:53 < jrandom> cervantes: last i heard frosk was kind of busy, but if frosk is around, maybe he can tell us more :)</p>
|
|
<p>17:53 <+legion> Personally I'd like to see a i2p entropy colab.</p>
|
|
<p>17:54 <+fox> <Romster> i have ideas for a datastore, but it be a expansion to existing methods that are in use currently</p>
|
|
<p>17:54 <+legion> Given that q, feedspace and such don't seem to be going anywhere fast right now</p>
|
|
<p>17:54 < jrandom> jnymo_: I've bounced the freenet folks some code to run on our SSU transport,toad has been joining in on some of the discussions, but freenet won't be in a position for us to run it as a data store on top of i2p for a while (after their 0.7 release comes out, most likely)</p>
|
|
<p>17:54 <+fox> <Romster> i want to start a project but not go over what others have done already</p>
|
|
<p>17:54 <+legion> wonder if it'd be possible to port entropy to run over i2p...</p>
|
|
<p>17:54 < jrandom> legion: entropy would be good, but integration is kind of hard. of course, people could run things like fproxy.i2p for entropy</p>
|
|
<p>17:55 * jrandom doesnt know entropy's transport code at all</p>
|
|
<p>17:55 <+fox> <Romster> i've put my irc client on hold, there is alot of them in progress already all i2p needs now is a datastore and it'll beat freenet with ease :)</p>
|
|
<p>17:55 < jrandom> (but perhaps that'd be a good way to get someone to hack on the GCJ SDK :)</p>
|
|
<p>17:56 < jrandom> Romster: helping out on other efforts is a lot more rewarding that starting brand new projects, as you get a lot more done with less effort :)</p>
|
|
<p>17:56 < jnymo_> ah.. congrats on the gcj port</p>
|
|
<p>17:56 <+fox> <Romster> entropy's is in c or C++ iirc</p>
|
|
<p>17:57 < jrandom> right Romster, which is why they'd be able to use I2P's SDK and streaming lib, built with GCJ into native libraries</p>
|
|
<p>17:57 <+fox> <Romster> jrandom true, but who :)</p>
|
|
<p>17:57 < jrandom> not I</p>
|
|
<p>17:57 <+legion> oh and on another issue, just like to mention that today I released a new version of my readme.html update for the i2p router console.</p>
|
|
<p>17:57 < jrandom> (the only way to get something you care about done is for *you* to do it :)</p>
|
|
<p>17:57 < jrandom> cool</p>
|
|
<p>17:57 * dust would like to see some kind of 'squid' syndication for offloading eepsites</p>
|
|
<p>17:58 < jrandom> dust: yeah totally, if we can get sucker into that position, that'd be ideal</p>
|
|
<p>17:58 < jrandom> e.g. I'd love to get the latest info from orion in syndie, local</p>
|
|
<p>17:58 <+fox> <Romster> build a proxy for squid to use :)</p>
|
|
<p>17:59 <+legion> I'd been putting it of in the hope that certain improvements to the python eepsitechecker would have been made by now.</p>
|
|
<p>17:59 < dust> ah, syndie</p>
|
|
<p>17:59 < jrandom> (thats actually what syndie is for - syndication to cut down on load)</p>
|
|
<p>17:59 < dust> _the_ answer</p>
|
|
<p>17:59 < jrandom> there's a python eepsite checker?</p>
|
|
<p>17:59 <+fox> <Romster> first i've heard about it</p>
|
|
<p>17:59 <+legion> yeah, it's what I use ;)</p>
|
|
<p>18:00 < jrandom> cool legion </p>
|
|
<p>18:00 <+legion> really? It's been around for awhile</p>
|
|
<p>18:00 <+fox> <Romster> nice i'd like to check that out :)</p>
|
|
<p>18:00 <@cervantes> think someone ported baffled's script... can't remember who/when</p>
|
|
<p>18:00 <+fox> <Romster> i'm learning python</p>
|
|
<p>18:00 < jrandom> ah ok cervantes </p>
|
|
<p>18:00 <+fox> <Romster> the hard way by examples and the manual :)</p>
|
|
<p>18:00 < jrandom> yeah, i'm lazy, i just use polecat.i2p/i2psurvey/ and orion.i2p/ :)</p>
|
|
<p>18:01 < jrandom> (no need for me to spider)</p>
|
|
<p>18:01 <+legion> if someone would care to work with me on it, I'd really like to get the code fixed and working with either python 2.3 or 2.4</p>
|
|
<p>18:01 <+fox> <Romster> i have 2.4 installed here</p>
|
|
<p>18:01 <+Ragnarok> I may have a look at it. Got link?</p>
|
|
<p>18:01 <+fox> <Romster> actually think it's 2.4.1</p>
|
|
<p>18:02 <+legion> right now it has no py2exe compatibility and half of it works with each version, which means anyone running it needs to have both installed.</p>
|
|
<p>18:02 * jnymo_ would love to see an orion.i2p/I2PDirectory hybrid.. info, catagories, stats.. butter</p>
|
|
<p>18:02 <+legion> I'll archive it after the meeting and post a link to the forums</p>
|
|
<p>18:03 <+Ragnarok> ok</p>
|
|
<p>18:03 < jrandom> legion: hmm, do you see lots of people needing to run that though? I mean, only a few people need to spider</p>
|
|
<p>18:03 <+fox> <Romster> both eck, might be a bit much for me to translate to the newer dunno untill i look at the code</p>
|
|
<p>18:03 < jrandom> (not that there's anything wrong with making it easy for those few people, that is :)</p>
|
|
<p>18:04 <+fox> <Romster> cold be disected and used todo other things too?</p>
|
|
<p>18:04 <+legion> Well thing is I can see where there could be some uses for everyone that runs i2p.</p>
|
|
<p>18:04 <+fox> <Romster> could*</p>
|
|
<p>18:04 < jrandom> hmm, I'm not so sure, could you explain how?</p>
|
|
<p>18:04 < jrandom> I mean, I don't want everyone to essentially DDoS every eepsite</p>
|
|
<p>18:05 <+legion> One of which would be a dynamic bookmarks page, that is auto generated every 12-24 hours or so.</p>
|
|
<p>18:05 < jrandom> ah, that is trivial in syndie (actually one of the main features - 'new blogs')</p>
|
|
<p>18:05 < jrandom> ((but of course, syndie doesn't have a great ui for that yet))</p>
|
|
<p>18:06 <+fox> <Romster> actually would only need a few to spider and throw it into a torrent/dht like database and sync that between nodes</p>
|
|
<p>18:06 < jrandom> right Romster (though that torrent/dht-like database to sync, or "syndi"cate, could be syndie ;)</p>
|
|
<p>18:06 <+fox> <Romster> could even be a hidden way to learn more i2p nodes and services</p>
|
|
<p>18:07 <+fox> <Romster> yeah or syndie</p>
|
|
<p>18:07 < jrandom> ok, anyone else have anything for the meeting? the curry is getting cold ;)</p>
|
|
<p>18:08 <+fox> <Romster> if syndie is going tobe that great one could store static pages to cashe and the same with images</p>
|
|
<p>18:08 <+fox> <reliver> bon appetit, jrandom :-)</p>
|
|
<p>18:08 < jrandom> exactly romster, you can do that now </p>
|
|
<p>18:09 < jrandom> ok, if there's nothing else...</p>
|
|
<p>18:09 * jrandom winds up</p>
|
|
<p>18:09 * jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |