on-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4124 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/76543b09/attachment.bin>
ize: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/4d41b8d5/attachment.pgp>
"Scott Young" writes:
> HTL has 2 main problems:
> First hop - Incoming HTL values can be used to determine if a node is likely
> to be the originator of a request
> HTL-1 - Malicious node may find out if a node contains specific data.
>
good description of the problem.
> One suggested solution
next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/d81f5b3b/attachment.pgp>
|- The Red Hot Chili Peppers
http://wooledge.org/~greg/ |
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/98fb137e/attachment.pgp>
"Scott Young" <[EMAIL PROTECTED]> writes:
> HTL has 2 main problems:
> First hop - Incoming HTL values can be used to determine if a node is likely
> to be the originator of a request
> HTL-1 - Malicious node may find out if a node contains specific data.
>
good description of the problem.
> One
HTL has 2 main problems:
First hop - Incoming HTL values can be used to determine if a node is likely
to be the originator of a request
HTL-1 - Malicious node may find out if a node contains specific data.
One suggested solution to both of theese is to abandon HTL for a
probabalistic forwarding ap
I'm still getting quite a lot of RNF's at htl=15. Is this still expected
behaviour, or is it just the node I'm trying to insert from? Just
curious
I've made some changes to my freenet audio streamer that make the
insertion much more robust (specifically, changing the way the threading
works
Hi,
As report previously the outbound stats show that connections to
named sites are always failing. No mater how you look at it its
a bug. I see the following
1. Its a bug in collecting the stats
2. Connections to named sites is really failing
3. Connections to named sites works but we record
I've stopped trying to get the current (read "unstable") cvs of freenet
to build using kaffe on linux due to sheer lack of time. I was kinda
dumbfounded when the current freenet cvs would not buid *and* run on the
latest Sun java release. I posted my sketchy logfiles and java vm
output here,
Ed Tomlinson ([EMAIL PROTECTED]) wrote:
> 1. Its a bug in collecting the stats
> 2. Connections to named sites is really failing
> 3. Connections to named sites works but we record and error maybe
>decrementing the HTL...
I can't believe that #2 is actually true, because non-working node
refe
HTL has 2 main problems:
First hop - Incoming HTL values can be used to determine if a node is likely
to be the originator of a request
HTL-1 - Malicious node may find out if a node contains specific data.
One suggested solution to both of theese is to abandon HTL for a
probabalistic forwarding ap
Hi,
As report previously the outbound stats show that connections to
named sites are always failing. No mater how you look at it its
a bug. I see the following
1. Its a bug in collecting the stats
2. Connections to named sites is really failing
3. Connections to named sites works but we record
This is really unfortunate that there are all of these problems - they
are really Python's fault I guess - but it is difficult to imaging
fishstream getting anywhere when even a Linux geek has this kind of
trouble getting it working.
Ian.
On Sun, Nov 10, 2002 at 09:17:54AM +1100, fish wrote:
>
one can "guarantee" a minimum
> number of visited nodes.
>
> --
> Robbe
--
Matthew Toseland
toad at amphibian.dyndns.org
amphibian at users.sourceforge.net
Freenet/Coldstore open source hacker.
Employed full time by Freenet Project Inc. from 11/9/02 to 11/11/02.
htt
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/729ce5f4/attachment.pgp>
Please don't advocate flooding the network based on anecdotes like this.
If people respond by flooding, then things will get worse, and we will
never know if they could have gotten better.
Can people please show some restraint in regard to drastic action to
make things work better. The network
--
Robbe
-- next part --
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/675590f3/attachment.pgp>
It should be reasonably easy for me to add this functionality. The code
is in kinda a mess right now, since I'm integrating it with HTML UI, but
I'll get to it in the next few days, most likely.
You will actully find that often, if you insert a file at HTL=25 on the
current node, it can be DNF a
Recently I inserted a file at HTL 20 into one of my nodes, and had it
DNF on the other at HTL 25. For two different files. This worked in the
past, with lower HTLs. Now, the interesting part is that I have three
nodes, and it appears that hammering all the nodes other than the one I
inserted the fi
On Sat, 9 Nov 2002 [EMAIL PROTECTED] wrote:
> Lastly, it's nice to read some moderately positive reaction.
> Now if only you had commit privleges... :)
no, i think it's far, far, far better for freenet that I never, ever, ever
am allowed near cvs commit access, considering my scrappy code :-p
J
On Sat, Nov 09, 2002 at 02:51:36PM -0800, [EMAIL PROTECTED] wrote:
>
>
>
> On Fri, 08 Nov 2002 16:21:14 -0800 Matthew Toseland <[EMAIL PROTECTED]>
>wrote:
>
> --- snip ---
>
> >Hmmm. I'm inclined to think that we should insert the metadata properly
> >and have gatewayhint purely for fetching
On Fri, 08 Nov 2002 16:21:14 -0800 Matthew Toseland <[EMAIL PROTECTED]> wrote:
--- snip ---
>Hmmm. I'm inclined to think that we should insert the metadata properly
>and have gatewayhint purely for fetching the CHK...
>>
The metadata (redirects) are actually inserted properly. Thing is,
you
On Fri, 08 Nov 2002 16:21:14 -0800 Matthew Toseland wrote:
--- snip ---
>Hmmm. I'm inclined to think that we should insert the metadata properly
>and have gatewayhint purely for fetching the CHK...
>>
The metadata (redirects) are actually inserted properly. Thing is,
you can't just have th
I believe that the risk of mapping freenet by requesting keys that
map to your own webserver are mitigated by two important factors.
1) There is a relationship between freenet keys and the gateway hint,
specifically, one should hash to the other. This is easy to check.
Checking for this this
I believe that the risk of mapping freenet by requesting keys that
map to your own webserver are mitigated by two important factors.
1) There is a relationship between freenet keys and the gateway hint,
specifically, one should hash to the other. This is easy to check.
Checking for this this
(For those who don't want to re-read what's below, fish is worried
that the gateway isn't anonymous because the initial request for
a proxied resource will show up in web-logs, hence isn't anonymous)
Firstly, the weblogs do not reveal who browsed the url.
What makes this gateway extention anonym
On Sat, 9 Nov 2002, Ian Clarke wrote:
> sh streamServer.py 1
> streamServer.py: line 3: from: command not found
> streamServer.py: line 8: syntax error near unexpected token `('
> streamServer.py: line 8: `class
> fishStreamServer(BaseHTTPServer.BaseHTTPRequestHandler):'
redhat vs. debian issue
(For those who don't want to re-read what's below, fish is worried
that the gateway isn't anonymous because the initial request for
a proxied resource will show up in web-logs, hence isn't anonymous)
Firstly, the weblogs do not reveal who browsed the url.
What makes this gateway extention anonym
ture.ng
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/df3f9abd/attachment.pgp>
art --
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/76ab5b37/attachment.pgp>
oh yeah, one more thing, the routing at higher HTL's will actully get more
reliable after a few days of use of the proxy, since 90% of the CHK's
won't change, only the redirects.
- fish
On Fri, 8 Nov 2002 thirty at hushmail.com wrote:
>
> Hi there,
>
> I've written a a framework for a
Hi! This is actully something that I've thought of quite a few times, so
it's great to see it implented :) (I also have a similar idea about
gnutella queries, but we'll go there another day - i've already got two
freenet related projects right now, that's enough :-p)
I do, however, have some iss
On Sat, Nov 09, 2002 at 11:31:35AM +0100, Robert Bihlmeyer wrote:
> David Allen <[EMAIL PROTECTED]> writes:
>
> > On Wed, Nov 06, 2002 at 11:09:06PM +, Matthew Toseland wrote:
> > > Possible solution to the problem that you can see that a request has
> > > been initiated on a given node:
> > >
Wayne Scott <[EMAIL PROTECTED]> writes:
> That explains why my traffic shaping was only marginally successful.
> I nicely limited incoming traffic, but only some of the outgoing
> traffic was being capped.
If this is on Linux 2.4+, iptables allow you to match packages by uid
of the sending proces
sh streamServer.py 1
streamServer.py: line 3: from: command not found
streamServer.py: line 8: syntax error near unexpected token `('
streamServer.py: line 8: `class
fishStreamServer(BaseHTTPServer.BaseHTTPRequestHandler):'
On Sat, Nov 09, 2002 at 09:15:09PM +1100, fish wrote:
>
> I'm still gett
sh streamServer.py 1
streamServer.py: line 3: from: command not found
streamServer.py: line 8: syntax error near unexpected token `('
streamServer.py: line 8: `class
fishStreamServer(BaseHTTPServer.BaseHTTPRequestHandler):'
On Sat, Nov 09, 2002 at 09:15:09PM +1100, fish wrote:
>
> I'm still gett
David Allen <[EMAIL PROTECTED]> writes:
> On Wed, Nov 06, 2002 at 11:09:06PM +, Matthew Toseland wrote:
> > Possible solution to the problem that you can see that a request has
> > been initiated on a given node:
> > Requests can have either HTL, or HTL|P, where P is a number between 0
> > and
[EMAIL PROTECTED] writes:
> ETag is just a string, so the base64-encoded key of the current file
> would do nicely (for key responses)
If fproxy can get at the CHKs of content it is showing that's a
possibility.
> > My current caching target are the web interface images (and static
> > pages), a
I'm still getting quite a lot of RNF's at htl=15. Is this still expected
behaviour, or is it just the node I'm trying to insert from? Just
curious
I've made some changes to my freenet audio streamer that make the
insertion much more robust (specifically, changing the way the threading
works
This idea was first brought up about three years ago or so. It is not a
viable because it allows for easy mapping of freenet - just request data
for different (nonexistant) keys with a "gatewayhint" pointing at an
http server you control, and freenet spills the beans on where it routes
for those k
om
> your freenet node, the same will not be true of other nodes.
>
>
>
>
> Get your free encrypted email at https://www.hushmail.com
>
> ___
> devl mailing list
> devl at freenetproject.org
> http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
--
Matthew Toseland
toad at amphibian.dyndns.org
amphibian at users.sourceforge.net
Freenet/Coldstore open source hacker.
Employed full time by Freenet Project Inc. from 11/9/02 to 11/11/02.
http://freenetproject.org/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/d5efc342/attachment.pgp>
--- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021109/a774a0bb/attachment.pgp>
43 matches
Mail list logo
