From bo-le at web.de  Tue Jan  2 14:54:49 2007
From: bo-le at web.de (bo-le at web.de)
Date: Tue, 2 Jan 2007 15:54:49 +0100
Subject: [freenet-dev] EvilDude, Round 2
Message-ID: <200701021554.50318.bo-le@web.de>

hi, 

just in the frost-board 'frost'
----- EvilDude ----- 2007.01.02 - 07:22:29GMT -----

If I wanted to download a key but it was rare, could I increase my chances of 
getting it if I inserted a KSK redirecting to it, forcing every frost user to 
download that file?

Similarly, could I create a denial of service attack by inserting a bunch of 
redirects to all the large files I can find? I'm not going to attempt it this 
time around, I'm just wondering.

-----

The fcp client should be able to detect the redirects if wanted.

My suggestion: a new progress, that show the redirects.

   static final int showRedirects = 128;

   verbose=verbose | showRedirects


Now the ClientGet returns a new progress message 

   FollowingRedirect 
   Identifier=hello
   RequestedURI=freenet:KSK at something-1-2
   RedirectTargetURI=freenet:CHK at jdncdj,hdcbd,a8
   EndMessage

Now the client app can decide how to handle it.

thanks.

-- 
Mfg
saces


From m.rogers at cs.ucl.ac.uk  Wed Jan  3 15:54:04 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Wed, 03 Jan 2007 15:54:04 +0000
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <20061219194141.GA29211@amphibian.dyndns.org>
References: <20061219194141.GA29211@amphibian.dyndns.org>
Message-ID: <459BD19C.7050202@cs.ucl.ac.uk>

Matthew Toseland wrote:
> - Locations of nodes are strongly clustered around 0.0.

Could this be due to some kind of bias in the collected data? For 
example if the network is less of a small world than expected, is it 
possible that you're only sampling swap requests within one area of the 
network?

Or a more paranoid explanation: if I regularly reset my location to 
(Math.random() * 0.02 - 0.01), swapping would spread these locations 
around the network and the nodes would end up clustered around 0.0.

How hard would it be to carry out this attack? Every node that joins the 
network creates a properly-distributed location, and every node that 
leaves the network destroys either a properly-distributed or a 
badly-distributed location. Depending on the churn rate, a single node 
resetting its location every few hours might be enough.

Is there any way to prevent this? Oskar's suggestion of occasionally 
switching to a random location would mitigate the problem, but not 
prevent it entirely.

Cheers,
Michael


From alejandro at mosteo.com  Wed Jan  3 23:14:37 2007
From: alejandro at mosteo.com (Jano)
Date: Thu, 04 Jan 2007 00:14:37 +0100
Subject: [freenet-dev] Wierd clustering behaviour again
References: <20061219194141.GA29211@amphibian.dyndns.org>
Message-ID: <enhdca$npg$1@sea.gmane.org>

Matthew Toseland wrote:

> PROBEALL: requests (telnet to 2323 and type PROBEALL: then tail -f
> wrapper.log), and implementation of spying on other nodes' swaps, seem
> to confirm the prior observations that:
> - Locations of nodes are strongly clustered around 0.0.

If I'm not mistaken, 0.0 is not a special location (besides being the warp
point from 1.0). So this clustering towards zero doesn't seem a natural
process. Even if there were reasons for the nodes getting naturally
concentrated around some location, then it could be anything and not
precisely 0.0?



From ian at thoof.com  Wed Jan  3 23:38:01 2007
From: ian at thoof.com (Ian Clarke)
Date: Wed, 3 Jan 2007 15:38:01 -0800
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <enhdca$npg$1@sea.gmane.org>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<enhdca$npg$1@sea.gmane.org>
Message-ID: <823242bd0701031538r688b4080le94e1a9c75d53af5@mail.gmail.com>

On 1/3/07, Jano <alejandro at mosteo.com> wrote:
> Matthew Toseland wrote:
> > PROBEALL: requests (telnet to 2323 and type PROBEALL: then tail -f
> > wrapper.log), and implementation of spying on other nodes' swaps, seem
> > to confirm the prior observations that:
> > - Locations of nodes are strongly clustered around 0.0.
>
> If I'm not mistaken, 0.0 is not a special location (besides being the warp
> point from 1.0). So this clustering towards zero doesn't seem a natural
> process. Even if there were reasons for the nodes getting naturally
> concentrated around some location, then it could be anything and not
> precisely 0.0?

You are not mistaken, even if there is a "natural" reason for
clustering, there is no reason other than pure chance that it would be
0.0.  This is definitely suspicious, and suggests a bug in how
distances between locations is calculated, however the pieces of code
responsible for that look fine.

Curiouser and curiouser.

Ian.


From bbackde at googlemail.com  Thu Jan  4 13:35:43 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Thu, 4 Jan 2007 14:35:43 +0100
Subject: [freenet-dev] Frost latest release
Message-ID: <d6149a790701040535p26b8d9cfhf2cec10eac791cf0@mail.gmail.com>

Hello,

when will the latest official Frost release be bundled in the freenet
installer, and when will it be available in
http://downloads.freenetproject.org/alpha/frost/ ?


From nextgens at freenetproject.org  Thu Jan  4 13:56:57 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 4 Jan 2007 14:56:57 +0100
Subject: [freenet-dev] Frost latest release
In-Reply-To: <d6149a790701040535p26b8d9cfhf2cec10eac791cf0@mail.gmail.com>
References: <d6149a790701040535p26b8d9cfhf2cec10eac791cf0@mail.gmail.com>
Message-ID: <20070104135657.GA4525@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-04 14:35:43]:

> Hello,
> 
> when will the latest official Frost release be bundled in the freenet
> installer, and when will it be available in
> http://downloads.freenetproject.org/alpha/frost/ ?

Soon...

I'm awaiting for the "go" from toad ... and would like to debate with
him whether we do bundle the official version or not.

I'm not happy with the default board set... as said on
http://archives.freenetproject.org//message/20061119.174718.057621ab.en.html

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070104/65052665/attachment.pgp 

From bbackde at googlemail.com  Thu Jan  4 14:02:25 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Thu, 4 Jan 2007 15:02:25 +0100
Subject: [freenet-dev] Frost latest release
In-Reply-To: <20070104135657.GA4525@freenetproject.org>
References: <d6149a790701040535p26b8d9cfhf2cec10eac791cf0@mail.gmail.com>
	<20070104135657.GA4525@freenetproject.org>
Message-ID: <d6149a790701040602x3bf9118eud3a9f1589c729076@mail.gmail.com>

So you are not happy because your proposed boards were not added? Was
there ever an answer from toad to this?

On 1/4/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-04 14:35:43]:
>
> > Hello,
> >
> > when will the latest official Frost release be bundled in the freenet
> > installer, and when will it be available in
> > http://downloads.freenetproject.org/alpha/frost/ ?
>
> Soon...
>
> I'm awaiting for the "go" from toad ... and would like to debate with
> him whether we do bundle the official version or not.
>
> I'm not happy with the default board set... as said on
> http://archives.freenetproject.org//message/20061119.174718.057621ab.en.html
>
> NextGen$
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFnQepU/Z/dHFfxtcRAkOuAKDwg8V4gcD+k1UwMeVGDR4vgVncjwCdFUcH
> m6MBfAsI7HPN7pcO9IldNHA=
> =MWmW
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>


From nextgens at freenetproject.org  Thu Jan  4 14:15:28 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 4 Jan 2007 15:15:28 +0100
Subject: [freenet-dev] Frost latest release
In-Reply-To: <d6149a790701040602x3bf9118eud3a9f1589c729076@mail.gmail.com>
References: <d6149a790701040535p26b8d9cfhf2cec10eac791cf0@mail.gmail.com>
	<20070104135657.GA4525@freenetproject.org>
	<d6149a790701040602x3bf9118eud3a9f1589c729076@mail.gmail.com>
Message-ID: <20070104141528.GB4525@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-04 15:02:25]:

> So you are not happy because your proposed boards were not added?

I'm not happy because it wasn't even debated. ATM we do have at least 4
freenet boards I'm aware of... and I do think that it's a waste of time
to scan every of them to raise bug reports from anonymous users.

> Was there ever an answer from toad to this?

No. Both of you were in the To: field and both of you seem to have
ignored the message.

> 
> On 1/4/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> >* bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-04 14:35:43]:
> >
> >> Hello,
> >>
> >> when will the latest official Frost release be bundled in the freenet
> >> installer, and when will it be available in
> >> http://downloads.freenetproject.org/alpha/frost/ ?
> >
> >Soon...
> >
> >I'm awaiting for the "go" from toad ... and would like to debate with
> >him whether we do bundle the official version or not.
> >
> >I'm not happy with the default board set... as said on
> >http://archives.freenetproject.org//message/20061119.174718.057621ab.en.html
> >
> >NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070104/e8a645cc/attachment.pgp 

From freenet at aga-pi.com  Wed Jan  3 18:04:22 2007
From: freenet at aga-pi.com (freenet at aga-pi.com)
Date: Wed, 3 Jan 2007 18:04:22 GMT
Subject: [freenet-dev] [PATCH] 1run.sh INSTALL_PATH autodefining
Message-ID: <200701031804.l03I4GuK013531@s130.aga-pi.com>

Hello,

This variant does not depend on external definition of INSTALL_PATH or
whatever, but derives it from the location of the 1run.sh binary itself.
The INSTALL_PATH variable and its current uses should never lead to extraneous
slashes in filepaths or URLs.

This exact quoting works nicely even for directories having several consecutive
spaces so beware touching that unless really needed [read: havn't tested with
anything but bash]. Together with earlier patches this variant should work well
for URLs too (and yes, URL encoding should be inside downloader code, as that
encoding introduced solely for HTTP transport/protocol not for process
parameters or anything).

The method of finding out the script own directory teoretically might fail if
the calling process makes certain dirty non-standard things with execve syscall
parameters; but then it's the calling process who would be at fault. Not sure
about the particular 'gui' installer [read: havn't tested], but for example
Java Runtime Library does not provide means to munch with parameter #0 thus
enforcing it to be valid, as well as many other environments do things robustly
(shells themselves for example).

===
--- 1run.sh-old 2007-01-03 16:48:22.000000000 +0000
+++ 1run.sh     2007-01-03 17:06:12.000000000 +0000
@@ -1,8 +1,13 @@
 #!/bin/sh

-INSTALL_PATH=${INSTALL_PATH:-$PWD}
+cd "$(echo '$0' | sed -e 's|[^/]*$|..|')" || exit 1
+INSTALL_PATH="$PWD"
+if [ "$INSTALL_PATH" = "/" ] ; then
+       # INSTALL_PATH=""
+       echo "Intalling freenet at fs root is definitelly a bug"
+       exit 1
+fi

-cd $INSTALL_PATH
 if test -s freenet-ext.jar
 then
        echo "This script isn't meant to be used more than once."
===

Aga.


From freenetwork at web.de  Sun Jan  7 09:38:39 2007
From: freenetwork at web.de (freenetwork at web.de)
Date: Sun, 07 Jan 2007 10:38:39 +0100
Subject: [freenet-dev] [PATCH] 1run.sh INSTALL_PATH autodefining
In-Reply-To: <200701031804.l03I4GuK013531@s130.aga-pi.com>
Message-ID: <E1H3UUB-00022x-00@smtp06.web.de>

why not

INSTALL_PATH=`dirname $0`





>Hello,

>This variant does not depend on external definition of INSTALL_PATH or
>whatever, but derives it from the location of the 1run.sh binary itself.
>The INSTALL_PATH variable and its current uses should never lead to extraneous
>slashes in filepaths or URLs.

>This exact quoting works nicely even for directories having several consecutive
>spaces so beware touching that unless really needed [read: havn't tested with
>anything but bash]. Together with earlier patches this variant should work well
>for URLs too (and yes, URL encoding should be inside downloader code, as that
>encoding introduced solely for HTTP transport/protocol not for process
>parameters or anything).

>The method of finding out the script own directory teoretically might fail if
>the calling process makes certain dirty non-standard things with execve syscall
>parameters; but then it's the calling process who would be at fault. Not sure
>about the particular 'gui' installer [read: havn't tested], but for example
>Java Runtime Library does not provide means to munch with parameter #0 thus
>enforcing it to be valid, as well as many other environments do things robustly
>(shells themselves for example).

>===
>--- 1run.sh-old 2007-01-03 16:48:22.000000000 +0000
>+++ 1run.sh     2007-01-03 17:06:12.000000000 +0000
>@@ -1,8 +1,13 @@
> #!/bin/sh

>-INSTALL_PATH=${INSTALL_PATH:-$PWD}
>+cd "$(echo '$0' | sed -e 's|[^/]*$|..|')" || exit 1
>+INSTALL_PATH="$PWD"
>+if [ "$INSTALL_PATH" = "/" ] ; then
>+       # INSTALL_PATH=""
>+       echo "Intalling freenet at fs root is definitelly a bug"
>+       exit 1
>+fi

>-cd $INSTALL_PATH
> if test -s freenet-ext.jar
> then
>        echo "This script isn't meant to be used more than once."
>===

>Aga.
>_______________________________________________
>Devl mailing list
>Devl at freenetproject.org
>http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl





From nextgens at freenetproject.org  Sun Jan  7 11:14:01 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sun, 7 Jan 2007 12:14:01 +0100
Subject: [freenet-dev] [PATCH] 1run.sh INSTALL_PATH autodefining
In-Reply-To: <200701031804.l03I4GuK013531@s130.aga-pi.com>
References: <200701031804.l03I4GuK013531@s130.aga-pi.com>
Message-ID: <20070107111401.GD4015@freenetproject.org>

* freenet at aga-pi.com <freenet at aga-pi.com> [2007-01-03 18:04:22]:

> Hello,
> 
> This variant does not depend on external definition of INSTALL_PATH or
> whatever, but derives it from the location of the 1run.sh binary itself.
> The INSTALL_PATH variable and its current uses should never lead to extraneous
> slashes in filepaths or URLs.
> 
> This exact quoting works nicely even for directories having several consecutive
> spaces so beware touching that unless really needed [read: havn't tested with
> anything but bash]. Together with earlier patches this variant should work well
> for URLs too (and yes, URL encoding should be inside downloader code, as that
> encoding introduced solely for HTTP transport/protocol not for process
> parameters or anything).
> 
> The method of finding out the script own directory teoretically might fail if
> the calling process makes certain dirty non-standard things with execve syscall
> parameters; but then it's the calling process who would be at fault. Not sure
> about the particular 'gui' installer [read: havn't tested], but for example
> Java Runtime Library does not provide means to munch with parameter #0 thus
> enforcing it to be valid, as well as many other environments do things robustly
> (shells themselves for example).
> 
> ===
> --- 1run.sh-old 2007-01-03 16:48:22.000000000 +0000
> +++ 1run.sh     2007-01-03 17:06:12.000000000 +0000
> @@ -1,8 +1,13 @@
>  #!/bin/sh
> 
> -INSTALL_PATH=${INSTALL_PATH:-$PWD}
> +cd "$(echo '$0' | sed -e 's|[^/]*$|..|')" || exit 1
> +INSTALL_PATH="$PWD"
> +if [ "$INSTALL_PATH" = "/" ] ; then
> +       # INSTALL_PATH=""
> +       echo "Intalling freenet at fs root is definitelly a bug"
> +       exit 1
> +fi
> 
> -cd $INSTALL_PATH
>  if test -s freenet-ext.jar
>  then
>         echo "This script isn't meant to be used more than once."
> ===
> 
> Aga.

Hi,

	I've tested your patch and it doesn't work with the gui : now I
	do remember why : 

	The GUI replaces $INSTALL_PATH within the file before execing it. It
execs the script from $BASE_PATH wich is different from $INSTALL_PATH...
so the "cd" is needed.

	I've commited something else before reading your mail : is the current
	version (r11563) fine for you ?

Regards,
	NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070107/f88c2d4c/attachment.pgp 

From nextgens at freenetproject.org  Sun Jan  7 11:21:27 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sun, 7 Jan 2007 12:21:27 +0100
Subject: [freenet-dev] I have an idea to control spam on freenet.
In-Reply-To: <662746420612250250m6a5c47cfp126b4f7a8fb3f20a@mail.gmail.com>
References: <662746420612250250m6a5c47cfp126b4f7a8fb3f20a@mail.gmail.com>
Message-ID: <20070107112126.GE4015@freenetproject.org>

* highfly joe <highfly22 at gmail.com> [2006-12-25 18:50:40]:

> Hi,
> To control spam, there must be some operationes to control file inserted. So
> some trusted servers are configured to sign off every sane files. And only
> the trusted servers hold a certain private key and release the public key to
> normal user. There are different kinds of trusted servers, which can
> constitute different domains, which contain different topics. Every file
> wanted to be inserted into a domain need request the trusted server to be
> signed by the private key. Every node can be configure to be interesting in
> several domains by user. So what you stored in your machine is what your
> wanted. This mechanism like SSK. But there are one major difference between
> them:
> to allow other people insert a SSK file, the private key must be given to
> them,. but if use the trusted servers, the only information exchanged is the
> signature.
> 
> The trusted servers can permit such essay to publish or not. And it's not
> going to be another censor. Cause you can build your own domain to fight
> back. The user can choose which is most important thing on their own will.
> 
> Regards,
> Haiwei

Hi,

	Your idea has been discussed on the public frost board "hereticnet"...
I suggest you join the debate there :) So far the conclusion is : "manual
moderation would introduce insane latencies".

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070107/5132b47c/attachment.pgp 

From bbackde at googlemail.com  Sun Jan  7 17:44:44 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Sun, 7 Jan 2007 18:44:44 +0100
Subject: [freenet-dev] New Frost version 07-Jan-2007
Message-ID: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>

New Frost version available at http://jtcfrost.sourceforge.net/ , and
in Freenet 0.5 and 0.7 soon.

Please add this version to the freenet installer. I added the freenet
boards as recommended.


From joelcsalomon at gmail.com  Sun Jan  7 23:16:14 2007
From: joelcsalomon at gmail.com (Joel Salomon)
Date: Sun, 7 Jan 2007 18:16:14 -0500
Subject: [freenet-dev] New Frost version 07-Jan-2007
In-Reply-To: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
References: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
Message-ID: <7871fcf50701071516n62aad41bp1dc03d0d2e76d65a@mail.gmail.com>

On 1/7/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
> I added the freenet boards as recommended.

Which boards were those? (Were they "freenet", "announce" and
"freenet.0.7.bugs"?)  I'm asking because no boards were added when I
updated.

--Joel


From nextgens at freenetproject.org  Sun Jan  7 23:54:23 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Mon, 8 Jan 2007 00:54:23 +0100
Subject: [freenet-dev] New Frost version 07-Jan-2007
In-Reply-To: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
References: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
Message-ID: <20070107235422.GJ4015@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-07 18:44:44]:

> New Frost version available at http://jtcfrost.sourceforge.net/ , and
> in Freenet 0.5 and 0.7 soon.
> 
> Please add this version to the freenet installer. I added the freenet
> boards as recommended.

Done... May I ask why you have switched to 1.5 only code ?

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070108/02f05fe3/attachment.pgp 

From bbackde at googlemail.com  Mon Jan  8 05:36:16 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Mon, 8 Jan 2007 06:36:16 +0100
Subject: [freenet-dev] New Frost version 07-Jan-2007
In-Reply-To: <7871fcf50701071516n62aad41bp1dc03d0d2e76d65a@mail.gmail.com>
References: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
	<7871fcf50701071516n62aad41bp1dc03d0d2e76d65a@mail.gmail.com>
Message-ID: <d6149a790701072136j7a90233fybfbabb4d4c5e3ef0@mail.gmail.com>

They are not auto-added during an update, I added the boards to the
default boardlist that is used if you start a fresh frost
installation.

On 1/8/07, Joel Salomon <joelcsalomon at gmail.com> wrote:
> On 1/7/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
> > I added the freenet boards as recommended.
>
> Which boards were those? (Were they "freenet", "announce" and
> "freenet.0.7.bugs"?)  I'm asking because no boards were added when I
> updated.
>
> --Joel
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From bbackde at googlemail.com  Mon Jan  8 05:37:46 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Mon, 8 Jan 2007 06:37:46 +0100
Subject: [freenet-dev] New Frost version 07-Jan-2007
In-Reply-To: <20070107235422.GJ4015@freenetproject.org>
References: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
	<20070107235422.GJ4015@freenetproject.org>
Message-ID: <d6149a790701072137h4af159b6u6d3761eb7a21db27@mail.gmail.com>

Because I now use some of the new 1.5 sync classes
(ReentrantReadWriteLock, Semaphore) to sync the database access and
fcp access. And 1.5 is available now for all supported platforms.

On 1/8/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-07 18:44:44]:
>
> > New Frost version available at http://jtcfrost.sourceforge.net/ , and
> > in Freenet 0.5 and 0.7 soon.
> >
> > Please add this version to the freenet installer. I added the freenet
> > boards as recommended.
>
> Done... May I ask why you have switched to 1.5 only code ?
>
> NextGen$
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFoYguU/Z/dHFfxtcRAlh/AJ0QJF1T7SVhczeCaYa3x8QLS+4n6ACgszfT
> 6MMJuVqlku7HuJnsKZZ6AIs=
> =yPBI
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>


From freenet-devl at osndok.com  Mon Jan  8 18:42:06 2007
From: freenet-devl at osndok.com (Robert Hailey)
Date: Mon, 8 Jan 2007 12:42:06 -0600
Subject: [freenet-dev] Rijndael cipher broken
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
Message-ID: <579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>


Please excuse me if this has already been addressed, I'm just now  
starting to dig into the freenet source.

The encryption aspect interests me, but after writing a test program  
and testing various key/block sizes for Rijndael, I found that only  
the 128 bit block size appears to work as it stands in the SVN  
repository, yet everywhere that it is used in the rest of the source  
it is requested with a 256 blocksize.

Apparently only due to not passing the blocksize into the key/encrypt/ 
decrypt functions, it appears easy enough to fix (example patch  
included). My question is, why aren't these other classes which rely  
on Rijndael-256-block encryption broken? or are they, silently?

If I'm missing something obvious, please do tell.

--
Robert Hailey

[ 4 intended attachments]

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output_no_patch.txt
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20070108/08162b1e/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output_with_patch.txt
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20070108/08162b1e/attachment-0001.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rijndael.patch
Type: application/octet-stream
Size: 1245 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070108/08162b1e/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestEncrypt.java
Type: application/octet-stream
Size: 2671 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070108/08162b1e/attachment-0001.obj 
-------------- next part --------------


From dbkr at freenetproject.org  Mon Jan  8 23:31:14 2007
From: dbkr at freenetproject.org (Dave Baker)
Date: Mon, 8 Jan 2007 23:31:14 +0000
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
Message-ID: <200701082331.15051.dbkr@freenetproject.org>

On Monday 08 January 2007 18:42, Robert Hailey wrote:
> 
> Please excuse me if this has already been addressed, I'm just now  
> starting to dig into the freenet source.
> 
> The encryption aspect interests me, but after writing a test program  
> and testing various key/block sizes for Rijndael, I found that only  
> the 128 bit block size appears to work as it stands in the SVN  
> repository, yet everywhere that it is used in the rest of the source  
> it is requested with a 256 blocksize.
> 
> Apparently only due to not passing the blocksize into the key/encrypt/ 
> decrypt functions, it appears easy enough to fix (example patch  
> included). My question is, why aren't these other classes which rely  
> on Rijndael-256-block encryption broken? or are they, silently?
> 
> If I'm missing something obvious, please do tell.

Eep.

I've looked at it and I think you're absolutely correct. It seems every use of 
Rijndael in Freenet in through the PCFBMode class, which complicates things a 
little. I've managed to get as far as establishing that indeed in all the 256 
bit AES encryptions that freenet does, only the first 128 bits ever get 
encrypted. Because of the Periodic Cipher Feedback, this means that only the 
first part of the feedback register gets encrypted. Presumably, the reverse 
happens on decryption, which means that the correct plaintext is obtained 
correctly at the end. In fact, if you use the same array for the input and 
output in your test program, it passes.

I've attatched a patch which shows the debugging I added to come to this 
result (basically just uses your binary-to-hex converter to print the input 
and output of Rijandael.encipher).

The reason why your test fails is because your result array starts as zeroes, 
whereas PCFB mode uses the feedback register for both the input and output, 
meaning that the bytes in the result array that aren't written to remain as 
the input.

I don't know enough about periodic cipher feedback theory mode to comment on 
the implications of only encrypting half the feedback register, but it surely 
must decrease the security massively.

So whilst your patch makes the node encrypt correctly, it means it can't read 
the store or talk to any of its peers, since they're all using the old 
encryption 'algorithm'.

Unless I'm also barking up the wrong tree, I have a horrible feeling of 
impending content reset.


Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aes-debug.patch
Type: text/x-diff
Size: 1195 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070108/d6137769/attachment.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070108/d6137769/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Jan  9 00:40:46 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 9 Jan 2007 00:40:46 +0000
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <200701082331.15051.dbkr@freenetproject.org>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
Message-ID: <20070109004046.GA19390@amphibian.dyndns.org>

On Mon, Jan 08, 2007 at 11:31:14PM +0000, Dave Baker wrote:
> On Monday 08 January 2007 18:42, Robert Hailey wrote:
> > 
> > Please excuse me if this has already been addressed, I'm just now  
> > starting to dig into the freenet source.
> > 
> > The encryption aspect interests me, but after writing a test program  
> > and testing various key/block sizes for Rijndael, I found that only  
> > the 128 bit block size appears to work as it stands in the SVN  
> > repository, yet everywhere that it is used in the rest of the source  
> > it is requested with a 256 blocksize.
> > 
> > Apparently only due to not passing the blocksize into the key/encrypt/ 
> > decrypt functions, it appears easy enough to fix (example patch  
> > included). My question is, why aren't these other classes which rely  
> > on Rijndael-256-block encryption broken? or are they, silently?
> > 
> > If I'm missing something obvious, please do tell.
> 
> Eep.
> 
> I've looked at it and I think you're absolutely correct. It seems every use of 
> Rijndael in Freenet in through the PCFBMode class, which complicates things a 
> little. I've managed to get as far as establishing that indeed in all the 256 
> bit AES encryptions that freenet does, only the first 128 bits ever get 
> encrypted. Because of the Periodic Cipher Feedback, this means that only the 
> first part of the feedback register gets encrypted. Presumably, the reverse 
> happens on decryption, which means that the correct plaintext is obtained 
> correctly at the end. In fact, if you use the same array for the input and 
> output in your test program, it passes.

I'm not convinced.

We *DO* use ECB mode in one place in the code. That place happens to be
critical to the node's function:

Packet hash encryption!

The first 32 bytes of every packet are an ECB-encrypted hash of the
encrypted rest of the packet.

We decrypt this and check it; if it does not match, the packet is
rejected and an error is logged.

Thus if this is true, no packet would ever be accepted.
> 
> I've attatched a patch which shows the debugging I added to come to this 
> result (basically just uses your binary-to-hex converter to print the input 
> and output of Rijandael.encipher).
> 
> The reason why your test fails is because your result array starts as zeroes, 
> whereas PCFB mode uses the feedback register for both the input and output, 
> meaning that the bytes in the result array that aren't written to remain as 
> the input.
> 
> I don't know enough about periodic cipher feedback theory mode to comment on 
> the implications of only encrypting half the feedback register, but it surely 
> must decrease the security massively.
> 
> So whilst your patch makes the node encrypt correctly, it means it can't read 
> the store or talk to any of its peers, since they're all using the old 
> encryption 'algorithm'.
> 
> Unless I'm also barking up the wrong tree, I have a horrible feeling of 
> impending content reset.
> 
> Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070109/ecfac4f8/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Jan  9 02:12:11 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 9 Jan 2007 02:12:11 +0000
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <20070109004046.GA19390@amphibian.dyndns.org>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
	<20070109004046.GA19390@amphibian.dyndns.org>
Message-ID: <20070109021211.GB19390@amphibian.dyndns.org>

This does appear to be real, I am working on a (backwards compatible)
fix.

On Tue, Jan 09, 2007 at 12:40:46AM +0000, Matthew Toseland wrote:
> On Mon, Jan 08, 2007 at 11:31:14PM +0000, Dave Baker wrote:
> > On Monday 08 January 2007 18:42, Robert Hailey wrote:
> > > 
> > > Please excuse me if this has already been addressed, I'm just now  
> > > starting to dig into the freenet source.
> > > 
> > > The encryption aspect interests me, but after writing a test program  
> > > and testing various key/block sizes for Rijndael, I found that only  
> > > the 128 bit block size appears to work as it stands in the SVN  
> > > repository, yet everywhere that it is used in the rest of the source  
> > > it is requested with a 256 blocksize.
> > > 
> > > Apparently only due to not passing the blocksize into the key/encrypt/ 
> > > decrypt functions, it appears easy enough to fix (example patch  
> > > included). My question is, why aren't these other classes which rely  
> > > on Rijndael-256-block encryption broken? or are they, silently?
> > > 
> > > If I'm missing something obvious, please do tell.
> > 
> > Eep.
> > 
> > I've looked at it and I think you're absolutely correct. It seems every use of 
> > Rijndael in Freenet in through the PCFBMode class, which complicates things a 
> > little. I've managed to get as far as establishing that indeed in all the 256 
> > bit AES encryptions that freenet does, only the first 128 bits ever get 
> > encrypted. Because of the Periodic Cipher Feedback, this means that only the 
> > first part of the feedback register gets encrypted. Presumably, the reverse 
> > happens on decryption, which means that the correct plaintext is obtained 
> > correctly at the end. In fact, if you use the same array for the input and 
> > output in your test program, it passes.
> 
> I'm not convinced.
> 
> We *DO* use ECB mode in one place in the code. That place happens to be
> critical to the node's function:
> 
> Packet hash encryption!
> 
> The first 32 bytes of every packet are an ECB-encrypted hash of the
> encrypted rest of the packet.
> 
> We decrypt this and check it; if it does not match, the packet is
> rejected and an error is logged.
> 
> Thus if this is true, no packet would ever be accepted.
> > 
> > I've attatched a patch which shows the debugging I added to come to this 
> > result (basically just uses your binary-to-hex converter to print the input 
> > and output of Rijandael.encipher).
> > 
> > The reason why your test fails is because your result array starts as zeroes, 
> > whereas PCFB mode uses the feedback register for both the input and output, 
> > meaning that the bytes in the result array that aren't written to remain as 
> > the input.
> > 
> > I don't know enough about periodic cipher feedback theory mode to comment on 
> > the implications of only encrypting half the feedback register, but it surely 
> > must decrease the security massively.
> > 
> > So whilst your patch makes the node encrypt correctly, it means it can't read 
> > the store or talk to any of its peers, since they're all using the old 
> > encryption 'algorithm'.
> > 
> > Unless I'm also barking up the wrong tree, I have a horrible feeling of 
> > impending content reset.
> > 
> > Dave



> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070109/7f49c5d0/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Jan  9 04:44:06 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 9 Jan 2007 04:44:06 +0000
Subject: [freenet-dev] Build 1010 - MANDATORY SECURITY FIX
Message-ID: <20070109044406.GA28018@amphibian.dyndns.org>

Freenet 0.7 build 1010 is now available. This build fixes a serious
security bug in our encryption code, affecting both link encryption and
encryption of keys. Please upgrade immediately; it is a mandatory build
as of now (meaning it will not connect to older builds). You will
probably have to use the update script manually to do this; sorry for
that, we *will* build an update-over-mandatory mechanism...
Caveats:
- All old KSKs are no longer retrievable.
- You will need to generate a new SSK for your inserts to be encrypted
  properly.
Otherwise the new build is backwards compatible with existing content.
So there is no need for a content reset. PLEASE UPGRADE!
If you are inclined to forward this to slashdot, please wait 24 hours or
so in case I missed any catastrophic bugs. And please listen out for new
builds.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070109/dad6ddde/attachment.pgp 

From freenet-devl at david.sowder.com  Tue Jan  9 05:02:00 2007
From: freenet-devl at david.sowder.com (David Sowder (Zothar))
Date: Mon, 08 Jan 2007 23:02:00 -0600
Subject: [freenet-dev] Build 1010 - MANDATORY SECURITY FIX
In-Reply-To: <20070109044406.GA28018@amphibian.dyndns.org>
References: <20070109044406.GA28018@amphibian.dyndns.org>
Message-ID: <45A321C8.6020306@david.sowder.com>

Matthew Toseland wrote:
> Freenet 0.7 build 1010 is now available. This build fixes a serious
> security bug in our encryption code, affecting both link encryption and
> encryption of keys. Please upgrade immediately; it is a mandatory build
> as of now (meaning it will not connect to older builds). You will
> probably have to use the update script manually to do this; sorry for
> that, we *will* build an update-over-mandatory mechanism...
> Caveats:
> - All old KSKs are no longer retrievable.
> - You will need to generate a new SSK for your inserts to be encrypted
>   properly.
> Otherwise the new build is backwards compatible with existing content.
> So there is no need for a content reset. PLEASE UPGRADE!
> If you are inclined to forward this to slashdot, please wait 24 hours or
> so in case I missed any catastrophic bugs. And please listen out for new
> builds.

Special provision would have had to have been made if we had 
update-over-mandatory implemented since this appears to break 
connections even such that we won't have TOO OLD and TOO NEW with N2NTM 
support.


From juiceman69 at gmail.com  Tue Jan  9 05:28:49 2007
From: juiceman69 at gmail.com (Juiceman)
Date: Tue, 9 Jan 2007 00:28:49 -0500
Subject: [freenet-dev] Build 1010 - MANDATORY SECURITY FIX
In-Reply-To: <20070109044406.GA28018@amphibian.dyndns.org>
References: <20070109044406.GA28018@amphibian.dyndns.org>
Message-ID: <8b525dee0701082128x220eb97aydeceae8957af7d49@mail.gmail.com>

On 1/8/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> Freenet 0.7 build 1010 is now available. This build fixes a serious
> security bug in our encryption code, affecting both link encryption and
> encryption of keys. Please upgrade immediately; it is a mandatory build
> as of now (meaning it will not connect to older builds). You will
> probably have to use the update script manually to do this; sorry for
> that, we *will* build an update-over-mandatory mechanism...

I'm just curious if giving it 12hrs before mandatory would have
distributed the new node build or not because of the change in link
crypto?

I understand this is a serious security bug and I'm not complaining,
just curious.

-- 
I may disagree with what you have to say, but I shall defend, to the
death, your right to say it. - Voltaire
Those who would give up Liberty, to purchase temporary Safety, deserve
neither Liberty nor Safety. - Ben Franklin


From bbackde at googlemail.com  Tue Jan  9 16:41:23 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Tue, 9 Jan 2007 17:41:23 +0100
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <20070109021211.GB19390@amphibian.dyndns.org>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
	<20070109004046.GA19390@amphibian.dyndns.org>
	<20070109021211.GB19390@amphibian.dyndns.org>
Message-ID: <d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>

I want to hazard a word because no else does it: how many of such
problems could be still in the code? I think there is no answer to
this question. Maybe toad or someone else (maybe paid from the
donations) should do a careful code review, at least of the critical
security parts.

And this problem shows that it is unjustifiable to bring users to 0.7
because they expect a secure network (as advertised in the media).
Even if it is alpha, everyone thinks it is secure and anonymous. And
until this is sure, new users should be advised to use 0.5, the stable
version. We all know that 0.5 is attackable, but the attacks are
mostly statistical attacks, and is'nt this _more_ secure than the
current (unreviewed) 0.7?

Sorry if I cried somebody down, but this is my opinion. I like 0.7,
its speed and functionality, but don't mislead the customers that
expect something different.

If you think I'm wrong then please provide a comparison sheet on the
wiki that compares freenet 0.5 and 0.7 and clearly states why 0.7 is
more secure, even in the current version.

best regards, bback.

PS: this mail contains no personal offense, its a constructive business mail.


On 1/9/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> This does appear to be real, I am working on a (backwards compatible)
> fix.
>
> On Tue, Jan 09, 2007 at 12:40:46AM +0000, Matthew Toseland wrote:
> > On Mon, Jan 08, 2007 at 11:31:14PM +0000, Dave Baker wrote:
> > > On Monday 08 January 2007 18:42, Robert Hailey wrote:
> > > >
> > > > Please excuse me if this has already been addressed, I'm just now
> > > > starting to dig into the freenet source.
> > > >
> > > > The encryption aspect interests me, but after writing a test program
> > > > and testing various key/block sizes for Rijndael, I found that only
> > > > the 128 bit block size appears to work as it stands in the SVN
> > > > repository, yet everywhere that it is used in the rest of the source
> > > > it is requested with a 256 blocksize.
> > > >
> > > > Apparently only due to not passing the blocksize into the key/encrypt/
> > > > decrypt functions, it appears easy enough to fix (example patch
> > > > included). My question is, why aren't these other classes which rely
> > > > on Rijndael-256-block encryption broken? or are they, silently?
> > > >
> > > > If I'm missing something obvious, please do tell.
> > >
> > > Eep.
> > >
> > > I've looked at it and I think you're absolutely correct. It seems every use of
> > > Rijndael in Freenet in through the PCFBMode class, which complicates things a
> > > little. I've managed to get as far as establishing that indeed in all the 256
> > > bit AES encryptions that freenet does, only the first 128 bits ever get
> > > encrypted. Because of the Periodic Cipher Feedback, this means that only the
> > > first part of the feedback register gets encrypted. Presumably, the reverse
> > > happens on decryption, which means that the correct plaintext is obtained
> > > correctly at the end. In fact, if you use the same array for the input and
> > > output in your test program, it passes.
> >
> > I'm not convinced.
> >
> > We *DO* use ECB mode in one place in the code. That place happens to be
> > critical to the node's function:
> >
> > Packet hash encryption!
> >
> > The first 32 bytes of every packet are an ECB-encrypted hash of the
> > encrypted rest of the packet.
> >
> > We decrypt this and check it; if it does not match, the packet is
> > rejected and an error is logged.
> >
> > Thus if this is true, no packet would ever be accepted.
> > >
> > > I've attatched a patch which shows the debugging I added to come to this
> > > result (basically just uses your binary-to-hex converter to print the input
> > > and output of Rijandael.encipher).
> > >
> > > The reason why your test fails is because your result array starts as zeroes,
> > > whereas PCFB mode uses the feedback register for both the input and output,
> > > meaning that the bytes in the result array that aren't written to remain as
> > > the input.
> > >
> > > I don't know enough about periodic cipher feedback theory mode to comment on
> > > the implications of only encrypting half the feedback register, but it surely
> > > must decrease the security massively.
> > >
> > > So whilst your patch makes the node encrypt correctly, it means it can't read
> > > the store or talk to any of its peers, since they're all using the old
> > > encryption 'algorithm'.
> > >
> > > Unless I'm also barking up the wrong tree, I have a horrible feeling of
> > > impending content reset.
> > >
> > > Dave
>
>
>
> > _______________________________________________
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFovn7A9rUluQ9pFARAjkEAJ95//QHmYIX/NfBZJqe/enCcBryEgCgm7Mq
> uJqiyf1deG5jGwscjVTsuN0=
> =+EVC
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>


From nextgens at freenetproject.org  Tue Jan  9 17:06:53 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Tue, 9 Jan 2007 18:06:53 +0100
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
	<20070109004046.GA19390@amphibian.dyndns.org>
	<20070109021211.GB19390@amphibian.dyndns.org>
	<d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>
Message-ID: <20070109170648.GC3992@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-09 17:41:23]:

> I want to hazard a word because no else does it: how many of such
> problems could be still in the code?

plenty

> I think there is no answer to this question.

You asked how many could be, right ? My answer seems to be appropriate.

> Maybe toad or someone else (maybe paid from the donations) should do a
> careful code review, at least of the critical security parts.

We ought to introduce unit tests on the new code we are writing that's
for sure... and it would be great if we were writing one test for every
bug we fix.

> And this problem shows that it is unjustifiable to bring users to 0.7
> because they expect a secure network (as advertised in the media).

Read below.

> Even if it is alpha, everyone thinks it is secure and anonymous. And
> until this is sure, new users should be advised to use 0.5, the stable
> version.

ROFL. Are you aware that 0.5 is using the same code ? :)
We have hit the bug on 0.7 because the keysize is different, that's all.

> We all know that 0.5 is attackable, but the attacks are
> mostly statistical attacks, and is'nt this _more_ secure than the
> current (unreviewed) 0.7?

0.5 is harvestable, we do have evidence that its routing *doesn't* work
as well as it ought to.
0.5 has been reviewed ? by whom ? Have I already mentionned that this
precise part of the code is mostly borrowed from 0.5 ?

> Sorry if I cried somebody down, but this is my opinion. I like 0.7,
> its speed and functionality, but don't mislead the customers that
> expect something different.
> 
> If you think I'm wrong then please provide a comparison sheet on the
> wiki that compares freenet 0.5 and 0.7 and clearly states why 0.7 is
> more secure, even in the current version.

No, I am not going to write down a "howto bring 0.5 down" tutorial for
you :) and I wouldn't encourage anyone to do so.

It's not a direct comparison but it's probably instructive for most
people who will take part to that thread.
http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity
It has been out of here since a while... Of course it doesn't tell
anything about bugs like that one.

On 0.5 we were using 128bits AES, on 0.7 we were supposed to be using
256bits (in reality we were using a "custom" algorithm because of the
bug... and noone knows how weak it is). On 0.5 we were using SHA1 on
0.7 we are using SHA256.

> 
> best regards, bback.
> 
> PS: this mail contains no personal offense, its a constructive business mail.
> 
> 
> On 1/9/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> > This does appear to be real, I am working on a (backwards compatible)
> > fix.
> >
> > On Tue, Jan 09, 2007 at 12:40:46AM +0000, Matthew Toseland wrote:
> > > On Mon, Jan 08, 2007 at 11:31:14PM +0000, Dave Baker wrote:
> > > > On Monday 08 January 2007 18:42, Robert Hailey wrote:
> > > > >
> > > > > Please excuse me if this has already been addressed, I'm just now
> > > > > starting to dig into the freenet source.
> > > > >
> > > > > The encryption aspect interests me, but after writing a test program
> > > > > and testing various key/block sizes for Rijndael, I found that only
> > > > > the 128 bit block size appears to work as it stands in the SVN
> > > > > repository, yet everywhere that it is used in the rest of the source
> > > > > it is requested with a 256 blocksize.
> > > > >
> > > > > Apparently only due to not passing the blocksize into the key/encrypt/
> > > > > decrypt functions, it appears easy enough to fix (example patch
> > > > > included). My question is, why aren't these other classes which rely
> > > > > on Rijndael-256-block encryption broken? or are they, silently?
> > > > >
> > > > > If I'm missing something obvious, please do tell.
> > > >
> > > > Eep.
> > > >
> > > > I've looked at it and I think you're absolutely correct. It seems every use of
> > > > Rijndael in Freenet in through the PCFBMode class, which complicates things a
> > > > little. I've managed to get as far as establishing that indeed in all the 256
> > > > bit AES encryptions that freenet does, only the first 128 bits ever get
> > > > encrypted. Because of the Periodic Cipher Feedback, this means that only the
> > > > first part of the feedback register gets encrypted. Presumably, the reverse
> > > > happens on decryption, which means that the correct plaintext is obtained
> > > > correctly at the end. In fact, if you use the same array for the input and
> > > > output in your test program, it passes.
> > >
> > > I'm not convinced.
> > >
> > > We *DO* use ECB mode in one place in the code. That place happens to be
> > > critical to the node's function:
> > >
> > > Packet hash encryption!
> > >
> > > The first 32 bytes of every packet are an ECB-encrypted hash of the
> > > encrypted rest of the packet.
> > >
> > > We decrypt this and check it; if it does not match, the packet is
> > > rejected and an error is logged.
> > >
> > > Thus if this is true, no packet would ever be accepted.
> > > >
> > > > I've attatched a patch which shows the debugging I added to come to this
> > > > result (basically just uses your binary-to-hex converter to print the input
> > > > and output of Rijandael.encipher).
> > > >
> > > > The reason why your test fails is because your result array starts as zeroes,
> > > > whereas PCFB mode uses the feedback register for both the input and output,
> > > > meaning that the bytes in the result array that aren't written to remain as
> > > > the input.
> > > >
> > > > I don't know enough about periodic cipher feedback theory mode to comment on
> > > > the implications of only encrypting half the feedback register, but it surely
> > > > must decrease the security massively.
> > > >
> > > > So whilst your patch makes the node encrypt correctly, it means it can't read
> > > > the store or talk to any of its peers, since they're all using the old
> > > > encryption 'algorithm'.
> > > >
> > > > Unless I'm also barking up the wrong tree, I have a horrible feeling of
> > > > impending content reset.
> > > >
> > > > Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070109/7b0914d0/attachment.pgp 

From bbackde at googlemail.com  Tue Jan  9 17:23:24 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Tue, 9 Jan 2007 18:23:24 +0100
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <20070109170648.GC3992@freenetproject.org>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
	<20070109004046.GA19390@amphibian.dyndns.org>
	<20070109021211.GB19390@amphibian.dyndns.org>
	<d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>
	<20070109170648.GC3992@freenetproject.org>
Message-ID: <d6149a790701090923l4f10b889j7b450ddfc9aaf1c7@mail.gmail.com>

Ok, this explains some of the details. I always thought 0.7 is a
complete rewrite. And unit tests are great!

0.5 was reviewed, because many different people worked with the code
(vanessa, I, and more) and they checked the parts of the code they
worked with.

On 1/9/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-09 17:41:23]:
>
> > I want to hazard a word because no else does it: how many of such
> > problems could be still in the code?
>
> plenty
>
> > I think there is no answer to this question.
>
> You asked how many could be, right ? My answer seems to be appropriate.
>
> > Maybe toad or someone else (maybe paid from the donations) should do a
> > careful code review, at least of the critical security parts.
>
> We ought to introduce unit tests on the new code we are writing that's
> for sure... and it would be great if we were writing one test for every
> bug we fix.
>
> > And this problem shows that it is unjustifiable to bring users to 0.7
> > because they expect a secure network (as advertised in the media).
>
> Read below.
>
> > Even if it is alpha, everyone thinks it is secure and anonymous. And
> > until this is sure, new users should be advised to use 0.5, the stable
> > version.
>
> ROFL. Are you aware that 0.5 is using the same code ? :)
> We have hit the bug on 0.7 because the keysize is different, that's all.
>
> > We all know that 0.5 is attackable, but the attacks are
> > mostly statistical attacks, and is'nt this _more_ secure than the
> > current (unreviewed) 0.7?
>
> 0.5 is harvestable, we do have evidence that its routing *doesn't* work
> as well as it ought to.
> 0.5 has been reviewed ? by whom ? Have I already mentionned that this
> precise part of the code is mostly borrowed from 0.5 ?
>
> > Sorry if I cried somebody down, but this is my opinion. I like 0.7,
> > its speed and functionality, but don't mislead the customers that
> > expect something different.
> >
> > If you think I'm wrong then please provide a comparison sheet on the
> > wiki that compares freenet 0.5 and 0.7 and clearly states why 0.7 is
> > more secure, even in the current version.
>
> No, I am not going to write down a "howto bring 0.5 down" tutorial for
> you :) and I wouldn't encourage anyone to do so.
>
> It's not a direct comparison but it's probably instructive for most
> people who will take part to that thread.
> http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity
> It has been out of here since a while... Of course it doesn't tell
> anything about bugs like that one.
>
> On 0.5 we were using 128bits AES, on 0.7 we were supposed to be using
> 256bits (in reality we were using a "custom" algorithm because of the
> bug... and noone knows how weak it is). On 0.5 we were using SHA1 on
> 0.7 we are using SHA256.
>
> >
> > best regards, bback.
> >
> > PS: this mail contains no personal offense, its a constructive business mail.
> >
> >
> > On 1/9/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> > > This does appear to be real, I am working on a (backwards compatible)
> > > fix.
> > >
> > > On Tue, Jan 09, 2007 at 12:40:46AM +0000, Matthew Toseland wrote:
> > > > On Mon, Jan 08, 2007 at 11:31:14PM +0000, Dave Baker wrote:
> > > > > On Monday 08 January 2007 18:42, Robert Hailey wrote:
> > > > > >
> > > > > > Please excuse me if this has already been addressed, I'm just now
> > > > > > starting to dig into the freenet source.
> > > > > >
> > > > > > The encryption aspect interests me, but after writing a test program
> > > > > > and testing various key/block sizes for Rijndael, I found that only
> > > > > > the 128 bit block size appears to work as it stands in the SVN
> > > > > > repository, yet everywhere that it is used in the rest of the source
> > > > > > it is requested with a 256 blocksize.
> > > > > >
> > > > > > Apparently only due to not passing the blocksize into the key/encrypt/
> > > > > > decrypt functions, it appears easy enough to fix (example patch
> > > > > > included). My question is, why aren't these other classes which rely
> > > > > > on Rijndael-256-block encryption broken? or are they, silently?
> > > > > >
> > > > > > If I'm missing something obvious, please do tell.
> > > > >
> > > > > Eep.
> > > > >
> > > > > I've looked at it and I think you're absolutely correct. It seems every use of
> > > > > Rijndael in Freenet in through the PCFBMode class, which complicates things a
> > > > > little. I've managed to get as far as establishing that indeed in all the 256
> > > > > bit AES encryptions that freenet does, only the first 128 bits ever get
> > > > > encrypted. Because of the Periodic Cipher Feedback, this means that only the
> > > > > first part of the feedback register gets encrypted. Presumably, the reverse
> > > > > happens on decryption, which means that the correct plaintext is obtained
> > > > > correctly at the end. In fact, if you use the same array for the input and
> > > > > output in your test program, it passes.
> > > >
> > > > I'm not convinced.
> > > >
> > > > We *DO* use ECB mode in one place in the code. That place happens to be
> > > > critical to the node's function:
> > > >
> > > > Packet hash encryption!
> > > >
> > > > The first 32 bytes of every packet are an ECB-encrypted hash of the
> > > > encrypted rest of the packet.
> > > >
> > > > We decrypt this and check it; if it does not match, the packet is
> > > > rejected and an error is logged.
> > > >
> > > > Thus if this is true, no packet would ever be accepted.
> > > > >
> > > > > I've attatched a patch which shows the debugging I added to come to this
> > > > > result (basically just uses your binary-to-hex converter to print the input
> > > > > and output of Rijandael.encipher).
> > > > >
> > > > > The reason why your test fails is because your result array starts as zeroes,
> > > > > whereas PCFB mode uses the feedback register for both the input and output,
> > > > > meaning that the bytes in the result array that aren't written to remain as
> > > > > the input.
> > > > >
> > > > > I don't know enough about periodic cipher feedback theory mode to comment on
> > > > > the implications of only encrypting half the feedback register, but it surely
> > > > > must decrease the security massively.
> > > > >
> > > > > So whilst your patch makes the node encrypt correctly, it means it can't read
> > > > > the store or talk to any of its peers, since they're all using the old
> > > > > encryption 'algorithm'.
> > > > >
> > > > > Unless I'm also barking up the wrong tree, I have a horrible feeling of
> > > > > impending content reset.
> > > > >
> > > > > Dave
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFo8uoU/Z/dHFfxtcRApx5AJ9awQkVpX74vlaRT3LI+4BfgVB5FgCfRsYe
> VafobYZ2ZCCmVNS7Ka+4esY=
> =3MKG
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>


From nextgens at freenetproject.org  Tue Jan  9 17:24:51 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Tue, 9 Jan 2007 18:24:51 +0100
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
Message-ID: <20070109172450.GD3992@freenetproject.org>

* Robert Hailey <freenet-devl at osndok.com> [2007-01-08 12:42:06]:

Hi!

> Please excuse me if this has already been addressed, I'm just now  
> starting to dig into the freenet source.
> 
> The encryption aspect interests me, but after writing a test program  
> and testing various key/block sizes for Rijndael, I found that only  
> the 128 bit block size appears to work as it stands in the SVN  
> repository, yet everywhere that it is used in the rest of the source  
> it is requested with a 256 blocksize.
> 
> Apparently only due to not passing the blocksize into the key/encrypt/ 
> decrypt functions, it appears easy enough to fix (example patch  
> included). My question is, why aren't these other classes which rely  
> on Rijndael-256-block encryption broken? or are they, silently?

They were broken silently :S

Congratulation for catching that bug.

> 
> If I'm missing something obvious, please do tell.

You are not ; we have been.

NextGen$

> --
> Robert Hailey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070109/20c880ef/attachment.pgp 

From bbackde at googlemail.com  Tue Jan  9 18:25:59 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Tue, 9 Jan 2007 19:25:59 +0100
Subject: [freenet-dev] SSK generation and existing keys
Message-ID: <d6149a790701091025t413b1d1emb2e583b5878db6d8@mail.gmail.com>

I'm curious: do the existing SSK key pairs still run with 1010? Frost
uses them for boards, and I got no message on the Announce board for
1010?!


From freenet-devl at osndok.com  Tue Jan  9 19:31:33 2007
From: freenet-devl at osndok.com (Robert Hailey)
Date: Tue, 9 Jan 2007 13:31:33 -0600
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <20070109172450.GD3992@freenetproject.org>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<20070109172450.GD3992@freenetproject.org>
Message-ID: <64057FFB-178A-4967-A3C1-A6A6ACE8F07D@osndok.com>


On Jan 9, 2007, at 11:24 AM, Florent Daigni?re (NextGen$) wrote:

>> My question is, why aren't these other classes which rely
>> on Rijndael-256-block encryption broken? or are they, silently?
>
> They were broken silently :S
>
> Congratulation for catching that bug.
>
>> If I'm missing something obvious, please do tell.
>
> You are not ; we have been.
>
> NextGen$

Thanks, NextGen$

I feel kinda special now that I've more or less caused a network-wide  
manual update :)

--
Robert Hailey



From highfly22 at gmail.com  Tue Jan  9 05:23:39 2007
From: highfly22 at gmail.com (highfly joe)
Date: Tue, 9 Jan 2007 13:23:39 +0800
Subject: [freenet-dev] I have an idea to control spam on freenet.
In-Reply-To: <20070107112126.GE4015@freenetproject.org>
References: <662746420612250250m6a5c47cfp126b4f7a8fb3f20a@mail.gmail.com>
	<20070107112126.GE4015@freenetproject.org>
Message-ID: <662746420701082123u3019eb4cw14ec0e4ef910e376@mail.gmail.com>

That's great.
Please tell me where is the public frost board "hereticnet". How to access
it?
Thanks

On 1/7/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
>
> * highfly joe <highfly22 at gmail.com> [2006-12-25 18:50:40]:
>
> > Hi,
> > To control spam, there must be some operationes to control file
> inserted. So
> > some trusted servers are configured to sign off every sane files. And
> only
> > the trusted servers hold a certain private key and release the public
> key to
> > normal user. There are different kinds of trusted servers, which can
> > constitute different domains, which contain different topics. Every file
> > wanted to be inserted into a domain need request the trusted server to
> be
> > signed by the private key. Every node can be configure to be interesting
> in
> > several domains by user. So what you stored in your machine is what your
> > wanted. This mechanism like SSK. But there are one major difference
> between
> > them:
> > to allow other people insert a SSK file, the private key must be given
> to
> > them,. but if use the trusted servers, the only information exchanged is
> the
> > signature.
> >
> > The trusted servers can permit such essay to publish or not. And it's
> not
> > going to be another censor. Cause you can build your own domain to fight
> > back. The user can choose which is most important thing on their own
> will.
> >
> > Regards,
> > Haiwei
>
> Hi,
>
>         Your idea has been discussed on the public frost board
> "hereticnet"...
> I suggest you join the debate there :) So far the conclusion is : "manual
> moderation would introduce insane latencies".
>
> NextGen$
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFoNe2U/Z/dHFfxtcRArSxAJ0YmJhhiUvOnEUS1KnzScKA6NBl2QCgzWZs
> 2knm2+E2bC9veoVKQdrItTw=
> =HTd1
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://emu.freenetproject.org/pipermail/devl/attachments/20070109/b5a0f5e9/attachment.htm 

From bruthoma at student.ethz.ch  Tue Jan  9 23:54:41 2007
From: bruthoma at student.ethz.ch (Thomas Bruderer)
Date: Tue, 9 Jan 2007 23:54:41 +0000 (UTC)
Subject: [freenet-dev] Build 1010 - MANDATORY SECURITY FIX
References: <20070109044406.GA28018@amphibian.dyndns.org>
Message-ID: <loom.20070110T004815-506@post.gmane.org>

Matthew Toseland <toad at ...> writes:

> 
> Freenet 0.7 build 1010 is now available. This build fixes a serious
> security bug in our encryption code, affecting both link encryption and
> encryption of keys. Please upgrade immediately; it is a mandatory build
> as of now (meaning it will not connect to older builds). You will
> probably have to use the update script manually to do this; sorry for
> that, we *will* build an update-over-mandatory mechanism...
> Caveats:
> - All old KSKs are no longer retrievable.
> - You will need to generate a new SSK for your inserts to be encrypted
>   properly.
> Otherwise the new build is backwards compatible with existing content.
> So there is no need for a content reset. PLEASE UPGRADE!
> If you are inclined to forward this to slashdot, please wait 24 hours or
> so in case I missed any catastrophic bugs. And please listen out for new
> builds.

This bug was probably in there since month, this overreaction is not very
promising in handling bigger Problems.

You could really give us at least 24 hours... what should I do know? already 6
nodes are "Too Old" since over a week, and After I upgread, I have not a single
connection... since everything is too old.

This will take days till the network recovers.

Well at least you have some more reason to not implement Open Net since there
are still sooo many sooo bad bugs.

BTW if we would have an opennet, at least the fast movers would get some
connections. NOW I'll have to wait.

Good Night!











From juiceman69 at gmail.com  Thu Jan 11 05:36:23 2007
From: juiceman69 at gmail.com (Juiceman)
Date: Thu, 11 Jan 2007 00:36:23 -0500
Subject: [freenet-dev] Build 1010 - MANDATORY SECURITY FIX
In-Reply-To: <20070109044406.GA28018@amphibian.dyndns.org>
References: <20070109044406.GA28018@amphibian.dyndns.org>
Message-ID: <8b525dee0701102136s2f9df47dsc23da0aea71df160@mail.gmail.com>

On 1/8/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> Freenet 0.7 build 1010 is now available. This build fixes a serious
> security bug in our encryption code, affecting both link encryption and
> encryption of keys. Please upgrade immediately; it is a mandatory build
> as of now (meaning it will not connect to older builds). You will
> probably have to use the update script manually to do this; sorry for
> that, we *will* build an update-over-mandatory mechanism...
> Caveats:
> - All old KSKs are no longer retrievable.
> - You will need to generate a new SSK for your inserts to be encrypted
>   properly.

I assume a new SSK/USK will be created for the "update over Freenet" mechanism??

-- 
I may disagree with what you have to say, but I shall defend, to the
death, your right to say it. - Voltaire
Those who would give up Liberty, to purchase temporary Safety, deserve
neither Liberty nor Safety. - Ben Franklin


From toad at amphibian.dyndns.org  Mon Jan 15 15:40:45 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:40:45 +0000
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
	<20070109004046.GA19390@amphibian.dyndns.org>
	<20070109021211.GB19390@amphibian.dyndns.org>
	<d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>
Message-ID: <20070115154044.GA29706@amphibian.dyndns.org>

On Tue, Jan 09, 2007 at 05:41:23PM +0100, bbackde at googlemail.com wrote:
> I want to hazard a word because no else does it: how many of such
> problems could be still in the code? I think there is no answer to
> this question. Maybe toad or someone else (maybe paid from the
> donations) should do a careful code review, at least of the critical
> security parts.

This particular bug is no longer present in the code, full stop. The
reason why is that it was a bug in our wrapper of the Rijndael code.
Both the wrapper and the Rijndael code itself were identical in 0.5. 0.5
used 128-bit keys and block sizes, and there was a bug in the wrapper
code which assumed that the block size would always be 128 bits (16
bytes), so it used the 128-bit-block version of the functions, even when
the block size had been set to a different number than 128.
> 
> And this problem shows that it is unjustifiable to bring users to 0.7
> because they expect a secure network (as advertised in the media).

Where did we say Freenet was secure? The best we can say is Freenet is
more secure than some other options. There is a brutally honest page on
the wiki discussing Freenet's various security issues, for example:
http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity

> Even if it is alpha, everyone thinks it is secure and anonymous. 

That is their loss. Alpha software by definition is not fully tested; it
has not had as much testing, code review, debugging as beta software,
all other things being equal.

> And
> until this is sure, new users should be advised to use 0.5, the stable
> version. We all know that 0.5 is attackable, but the attacks are
> mostly statistical attacks, and is'nt this _more_ secure than the
> current (unreviewed) 0.7?

The attacks on 0.7 are mostly statistical attacks too. This particular
bug was a bug in the crypto, which affected link level encryption, and
also stored data. In both cases, the attacker can see 16 bytes out of
every 32 as plaintext. For link encryption, this is pretty bad; it means
a passive snooper can probably get a good idea of what is going on
between the two nodes. For stored data, it means it is much easier to
identify the original decrypted content. This makes correlation etc
attacks easier and makes it easier to identify content in your
datastore.
> 
> Sorry if I cried somebody down, but this is my opinion. I like 0.7,
> its speed and functionality, but don't mislead the customers that
> expect something different.
> 
> If you think I'm wrong then please provide a comparison sheet on the
> wiki that compares freenet 0.5 and 0.7 and clearly states why 0.7 is
> more secure, even in the current version.
> 
> best regards, bback.
> 
> PS: this mail contains no personal offense, its a constructive business mail.
> 
> 
> On 1/9/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> > This does appear to be real, I am working on a (backwards compatible)
> > fix.
> >
> > On Tue, Jan 09, 2007 at 12:40:46AM +0000, Matthew Toseland wrote:
> > > On Mon, Jan 08, 2007 at 11:31:14PM +0000, Dave Baker wrote:
> > > > On Monday 08 January 2007 18:42, Robert Hailey wrote:
> > > > >
> > > > > Please excuse me if this has already been addressed, I'm just now
> > > > > starting to dig into the freenet source.
> > > > >
> > > > > The encryption aspect interests me, but after writing a test program
> > > > > and testing various key/block sizes for Rijndael, I found that only
> > > > > the 128 bit block size appears to work as it stands in the SVN
> > > > > repository, yet everywhere that it is used in the rest of the source
> > > > > it is requested with a 256 blocksize.
> > > > >
> > > > > Apparently only due to not passing the blocksize into the key/encrypt/
> > > > > decrypt functions, it appears easy enough to fix (example patch
> > > > > included). My question is, why aren't these other classes which rely
> > > > > on Rijndael-256-block encryption broken? or are they, silently?
> > > > >
> > > > > If I'm missing something obvious, please do tell.
> > > >
> > > > Eep.
> > > >
> > > > I've looked at it and I think you're absolutely correct. It seems every use of
> > > > Rijndael in Freenet in through the PCFBMode class, which complicates things a
> > > > little. I've managed to get as far as establishing that indeed in all the 256
> > > > bit AES encryptions that freenet does, only the first 128 bits ever get
> > > > encrypted. Because of the Periodic Cipher Feedback, this means that only the
> > > > first part of the feedback register gets encrypted. Presumably, the reverse
> > > > happens on decryption, which means that the correct plaintext is obtained
> > > > correctly at the end. In fact, if you use the same array for the input and
> > > > output in your test program, it passes.
> > >
> > > I'm not convinced.
> > >
> > > We *DO* use ECB mode in one place in the code. That place happens to be
> > > critical to the node's function:
> > >
> > > Packet hash encryption!
> > >
> > > The first 32 bytes of every packet are an ECB-encrypted hash of the
> > > encrypted rest of the packet.
> > >
> > > We decrypt this and check it; if it does not match, the packet is
> > > rejected and an error is logged.
> > >
> > > Thus if this is true, no packet would ever be accepted.
> > > >
> > > > I've attatched a patch which shows the debugging I added to come to this
> > > > result (basically just uses your binary-to-hex converter to print the input
> > > > and output of Rijandael.encipher).
> > > >
> > > > The reason why your test fails is because your result array starts as zeroes,
> > > > whereas PCFB mode uses the feedback register for both the input and output,
> > > > meaning that the bytes in the result array that aren't written to remain as
> > > > the input.
> > > >
> > > > I don't know enough about periodic cipher feedback theory mode to comment on
> > > > the implications of only encrypting half the feedback register, but it surely
> > > > must decrease the security massively.
> > > >
> > > > So whilst your patch makes the node encrypt correctly, it means it can't read
> > > > the store or talk to any of its peers, since they're all using the old
> > > > encryption 'algorithm'.
> > > >
> > > > Unless I'm also barking up the wrong tree, I have a horrible feeling of
> > > > impending content reset.
> > > >
> > > > Dave
> >
> >
> >
> > > _______________________________________________
> > > Devl mailing list
> > > Devl at freenetproject.org
> > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFFovn7A9rUluQ9pFARAjkEAJ95//QHmYIX/NfBZJqe/enCcBryEgCgm7Mq
> > uJqiyf1deG5jGwscjVTsuN0=
> > =+EVC
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> >
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/8fa4997a/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:43:47 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:43:47 +0000
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <20070109170648.GC3992@freenetproject.org>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
	<20070109004046.GA19390@amphibian.dyndns.org>
	<20070109021211.GB19390@amphibian.dyndns.org>
	<d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>
	<20070109170648.GC3992@freenetproject.org>
Message-ID: <20070115154347.GB29706@amphibian.dyndns.org>

On Tue, Jan 09, 2007 at 06:06:53PM +0100, Florent Daigni?re (NextGen$) wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-09 17:41:23]:
> 
> > I want to hazard a word because no else does it: how many of such
> > problems could be still in the code?
> 
> plenty
> 
> > I think there is no answer to this question.
> 
> You asked how many could be, right ? My answer seems to be appropriate.
> 
> > Maybe toad or someone else (maybe paid from the donations) should do a
> > careful code review, at least of the critical security parts.
> 
> We ought to introduce unit tests on the new code we are writing that's
> for sure... and it would be great if we were writing one test for every
> bug we fix.

There were test vectors run by the original person who found this bug.
I personally have checked that outgoing encrypted data is in fact
encrypted, or at least, that the second 16 bytes of the ciphertext
are not the same as the second 16 bytes of the plaintext (at least for
hashes); this is what the bug produced.
> 
> 0.5 is harvestable, we do have evidence that its routing *doesn't* work
> as well as it ought to.
> 0.5 has been reviewed ? by whom ? Have I already mentionned that this
> precise part of the code is mostly borrowed from 0.5 ?
> 
> > Sorry if I cried somebody down, but this is my opinion. I like 0.7,
> > its speed and functionality, but don't mislead the customers that
> > expect something different.
> > 
> > If you think I'm wrong then please provide a comparison sheet on the
> > wiki that compares freenet 0.5 and 0.7 and clearly states why 0.7 is
> > more secure, even in the current version.
> 
> No, I am not going to write down a "howto bring 0.5 down" tutorial for
> you :) and I wouldn't encourage anyone to do so.
> 
> It's not a direct comparison but it's probably instructive for most
> people who will take part to that thread.
> http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity
> It has been out of here since a while... Of course it doesn't tell
> anything about bugs like that one.

There are always more bugs. :(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/6ba8ac77/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:45:00 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:45:00 +0000
Subject: [freenet-dev] Rijndael cipher broken
In-Reply-To: <d6149a790701090923l4f10b889j7b450ddfc9aaf1c7@mail.gmail.com>
References: <51F3ECB6-21B4-40D1-B326-8E0CB6DC690B@osndok.com>
	<579692F8-426C-4A54-AC6F-5E9BD498E3D5@osndok.com>
	<200701082331.15051.dbkr@freenetproject.org>
	<20070109004046.GA19390@amphibian.dyndns.org>
	<20070109021211.GB19390@amphibian.dyndns.org>
	<d6149a790701090841u3d9d1055xbc27bd80fc67326a@mail.gmail.com>
	<20070109170648.GC3992@freenetproject.org>
	<d6149a790701090923l4f10b889j7b450ddfc9aaf1c7@mail.gmail.com>
Message-ID: <20070115154500.GC29706@amphibian.dyndns.org>

On Tue, Jan 09, 2007 at 06:23:24PM +0100, bbackde at googlemail.com wrote:
> Ok, this explains some of the details. I always thought 0.7 is a
> complete rewrite. And unit tests are great!
> 
> 0.5 was reviewed, because many different people worked with the code
> (vanessa, I, and more) and they checked the parts of the code they
> worked with.

No, *complete* rewrites are a waste of time; 0.7 was rewritten
architectually speaking but we imported old code wherever it was useful.
Including the crypto code, which worked in 0.5 because it had a 128-bit
block size.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/84befa74/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:47:01 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:47:01 +0000
Subject: [freenet-dev] Build 1010 - MANDATORY SECURITY FIX
In-Reply-To: <loom.20070110T004815-506@post.gmane.org>
References: <20070109044406.GA28018@amphibian.dyndns.org>
	<loom.20070110T004815-506@post.gmane.org>
Message-ID: <20070115154701.GD29706@amphibian.dyndns.org>

On Tue, Jan 09, 2007 at 11:54:41PM +0000, Thomas Bruderer wrote:
> Matthew Toseland <toad at ...> writes:
> 
> > Freenet 0.7 build 1010 is now available. This build fixes a serious
> > security bug in our encryption code, affecting both link encryption and
> > encryption of keys. Please upgrade immediately; it is a mandatory build
> > as of now (meaning it will not connect to older builds). You will
> > probably have to use the update script manually to do this; sorry for
> > that, we *will* build an update-over-mandatory mechanism...
> > Caveats:
> > - All old KSKs are no longer retrievable.
> > - You will need to generate a new SSK for your inserts to be encrypted
> >   properly.
> > Otherwise the new build is backwards compatible with existing content.
> > So there is no need for a content reset. PLEASE UPGRADE!
> > If you are inclined to forward this to slashdot, please wait 24 hours or
> > so in case I missed any catastrophic bugs. And please listen out for new
> > builds.
> 
> This bug was probably in there since month, this overreaction is not very
> promising in handling bigger Problems.

No, the bug was there since 0.7 began.
> 
> You could really give us at least 24 hours... what should I do know? already 6
> nodes are "Too Old" since over a week, and After I upgread, I have not a single
> connection... since everything is too old.

Perhaps it is an overreaction. But people expect us to overreact to such
things. Better safe than sorry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/943cb9a8/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:48:46 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:48:46 +0000
Subject: [freenet-dev] SSK generation and existing keys
In-Reply-To: <d6149a790701091025t413b1d1emb2e583b5878db6d8@mail.gmail.com>
References: <d6149a790701091025t413b1d1emb2e583b5878db6d8@mail.gmail.com>
Message-ID: <20070115154846.GE29706@amphibian.dyndns.org>

On Tue, Jan 09, 2007 at 07:25:59PM +0100, bbackde at googlemail.com wrote:
> I'm curious: do the existing SSK key pairs still run with 1010? Frost
> uses them for boards, and I got no message on the Announce board for
> 1010?!

They do work. It's backward compatible; this will be removed eventually
however, so new SSKs should be created.

The reason you didn't get a message on the announce board was probably
that I didn't post one... I couldn't get the node to work with both
networks at once, and didn't bother to start up an old node to do the
announce... :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/f8ea36e7/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:51:30 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:51:30 +0000
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <459BD19C.7050202@cs.ucl.ac.uk>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<459BD19C.7050202@cs.ucl.ac.uk>
Message-ID: <20070115155130.GF29706@amphibian.dyndns.org>

On Wed, Jan 03, 2007 at 03:54:04PM +0000, Michael Rogers wrote:
> Matthew Toseland wrote:
> > - Locations of nodes are strongly clustered around 0.0.
> 
> Could this be due to some kind of bias in the collected data? For 
> example if the network is less of a small world than expected, is it 
> possible that you're only sampling swap requests within one area of the 
> network?
> 
> Or a more paranoid explanation: if I regularly reset my location to 
> (Math.random() * 0.02 - 0.01), swapping would spread these locations 
> around the network and the nodes would end up clustered around 0.0.
> 
> How hard would it be to carry out this attack? Every node that joins the 
> network creates a properly-distributed location, and every node that 
> leaves the network destroys either a properly-distributed or a 
> badly-distributed location. Depending on the churn rate, a single node 
> resetting its location every few hours might be enough.

The other possibility is that this is happening naturally somehow. My
theory was that the node moves peripheral locations to peripheral nodes,
and then the peripheral nodes drop off the network. There is some
theoretical basis for this but as usual Oskar is in a coma.
> 
> Is there any way to prevent this? Oskar's suggestion of occasionally 
> switching to a random location would mitigate the problem, but not 
> prevent it entirely.
> 
> Cheers,
> Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/7e9308b0/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:52:42 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:52:42 +0000
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <823242bd0701031538r688b4080le94e1a9c75d53af5@mail.gmail.com>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<enhdca$npg$1@sea.gmane.org>
	<823242bd0701031538r688b4080le94e1a9c75d53af5@mail.gmail.com>
Message-ID: <20070115155242.GG29706@amphibian.dyndns.org>

On Wed, Jan 03, 2007 at 03:38:01PM -0800, Ian Clarke wrote:
> On 1/3/07, Jano <alejandro at mosteo.com> wrote:
> > Matthew Toseland wrote:
> > > PROBEALL: requests (telnet to 2323 and type PROBEALL: then tail -f
> > > wrapper.log), and implementation of spying on other nodes' swaps, seem
> > > to confirm the prior observations that:
> > > - Locations of nodes are strongly clustered around 0.0.
> >
> > If I'm not mistaken, 0.0 is not a special location (besides being the warp
> > point from 1.0). So this clustering towards zero doesn't seem a natural
> > process. Even if there were reasons for the nodes getting naturally
> > concentrated around some location, then it could be anything and not
> > precisely 0.0?
> 
> You are not mistaken, even if there is a "natural" reason for
> clustering, there is no reason other than pure chance that it would be
> 0.0.  This is definitely suspicious, and suggests a bug in how
> distances between locations is calculated, however the pieces of code
> responsible for that look fine.

Did you get my email explaining how this might happen, just before
christmas?
> 
> Curiouser and curiouser.
> 
> Ian.
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/1aeea107/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:53:55 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:53:55 +0000
Subject: [freenet-dev] I have an idea to control spam on freenet.
In-Reply-To: <20070107112126.GE4015@freenetproject.org>
References: <662746420612250250m6a5c47cfp126b4f7a8fb3f20a@mail.gmail.com>
	<20070107112126.GE4015@freenetproject.org>
Message-ID: <20070115155355.GH29706@amphibian.dyndns.org>

On Sun, Jan 07, 2007 at 12:21:27PM +0100, Florent Daigni?re (NextGen$) wrote:
> * highfly joe <highfly22 at gmail.com> [2006-12-25 18:50:40]:
> 
> > Hi,
> > To control spam, there must be some operationes to control file inserted. So
> > some trusted servers are configured to sign off every sane files. And only
> > the trusted servers hold a certain private key and release the public key to
> > normal user. There are different kinds of trusted servers, which can
> > constitute different domains, which contain different topics. Every file
> > wanted to be inserted into a domain need request the trusted server to be
> > signed by the private key. Every node can be configure to be interesting in
> > several domains by user. So what you stored in your machine is what your
> > wanted. This mechanism like SSK. But there are one major difference between
> > them:
> > to allow other people insert a SSK file, the private key must be given to
> > them,. but if use the trusted servers, the only information exchanged is the
> > signature.
> > 
> > The trusted servers can permit such essay to publish or not. And it's not
> > going to be another censor. Cause you can build your own domain to fight
> > back. The user can choose which is most important thing on their own will.
> > 
> > Regards,
> > Haiwei
> 
> Hi,
> 
> 	Your idea has been discussed on the public frost board "hereticnet"...
> I suggest you join the debate there :) So far the conclusion is : "manual
> moderation would introduce insane latencies".

It has? That's not what Hereticnet is about...
> 
> NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/00a31e08/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 15:54:44 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 15:54:44 +0000
Subject: [freenet-dev] EvilDude, Round 2
In-Reply-To: <200701021554.50318.bo-le@web.de>
References: <200701021554.50318.bo-le@web.de>
Message-ID: <20070115155444.GI29706@amphibian.dyndns.org>

There is a default max-redirects. There is also a max-size setting which
defaults to unlimited in FCP but can be (and probably is) set by Frost.

On Tue, Jan 02, 2007 at 03:54:49PM +0100, bo-le at web.de wrote:
> hi, 
> 
> just in the frost-board 'frost'
> ----- EvilDude ----- 2007.01.02 - 07:22:29GMT -----
> 
> If I wanted to download a key but it was rare, could I increase my chances of 
> getting it if I inserted a KSK redirecting to it, forcing every frost user to 
> download that file?
> 
> Similarly, could I create a denial of service attack by inserting a bunch of 
> redirects to all the large files I can find? I'm not going to attempt it this 
> time around, I'm just wondering.
> 
> -----
> 
> The fcp client should be able to detect the redirects if wanted.
> 
> My suggestion: a new progress, that show the redirects.
> 
>    static final int showRedirects = 128;
> 
>    verbose=verbose | showRedirects
> 
> 
> Now the ClientGet returns a new progress message 
> 
>    FollowingRedirect 
>    Identifier=hello
>    RequestedURI=freenet:KSK at something-1-2
>    RedirectTargetURI=freenet:CHK at jdncdj,hdcbd,a8
>    EndMessage
> 
> Now the client app can decide how to handle it.
> 
> thanks.
> 
> -- 
> Mfg
> saces
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/3e7ce2e4/attachment.pgp 

From nextgens at freenetproject.org  Mon Jan 15 16:11:41 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Mon, 15 Jan 2007 17:11:41 +0100
Subject: [freenet-dev] I have an idea to control spam on freenet.
In-Reply-To: <20070115155355.GH29706@amphibian.dyndns.org>
References: <662746420612250250m6a5c47cfp126b4f7a8fb3f20a@mail.gmail.com>
	<20070107112126.GE4015@freenetproject.org>
	<20070115155355.GH29706@amphibian.dyndns.org>
Message-ID: <20070115161141.GA4263@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-01-15 15:53:55]:

> On Sun, Jan 07, 2007 at 12:21:27PM +0100, Florent Daigni?re (NextGen$) wrote:
> > * highfly joe <highfly22 at gmail.com> [2006-12-25 18:50:40]:
> > 
> > > Hi,
> > > To control spam, there must be some operationes to control file inserted. So
> > > some trusted servers are configured to sign off every sane files. And only
> > > the trusted servers hold a certain private key and release the public key to
> > > normal user. There are different kinds of trusted servers, which can
> > > constitute different domains, which contain different topics. Every file
> > > wanted to be inserted into a domain need request the trusted server to be
> > > signed by the private key. Every node can be configure to be interesting in
> > > several domains by user. So what you stored in your machine is what your
> > > wanted. This mechanism like SSK. But there are one major difference between
> > > them:
> > > to allow other people insert a SSK file, the private key must be given to
> > > them,. but if use the trusted servers, the only information exchanged is the
> > > signature.
> > > 
> > > The trusted servers can permit such essay to publish or not. And it's not
> > > going to be another censor. Cause you can build your own domain to fight
> > > back. The user can choose which is most important thing on their own will.
> > > 
> > > Regards,
> > > Haiwei
> > 
> > Hi,
> > 
> > 	Your idea has been discussed on the public frost board "hereticnet"...
> > I suggest you join the debate there :) So far the conclusion is : "manual
> > moderation would introduce insane latencies".
> 
> It has? That's not what Hereticnet is about...

I know ... and yes, I've seen the same proposal on that board a while ago.

NextGen$


From m.rogers at cs.ucl.ac.uk  Mon Jan 15 17:25:58 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Mon, 15 Jan 2007 17:25:58 +0000
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <20070115155130.GF29706@amphibian.dyndns.org>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<459BD19C.7050202@cs.ucl.ac.uk>
	<20070115155130.GF29706@amphibian.dyndns.org>
Message-ID: <45ABB926.5020107@cs.ucl.ac.uk>

Matthew Toseland wrote:
> The other possibility is that this is happening naturally somehow. My
> theory was that the node moves peripheral locations to peripheral nodes,
> and then the peripheral nodes drop off the network.

That would explain how there could be more than one cluster. If that's 
the cause, periodically resetting to a random location should help, right?

Cheers,
Michael


From toad at amphibian.dyndns.org  Mon Jan 15 17:54:01 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 17:54:01 +0000
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <45ABB926.5020107@cs.ucl.ac.uk>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<459BD19C.7050202@cs.ucl.ac.uk>
	<20070115155130.GF29706@amphibian.dyndns.org>
	<45ABB926.5020107@cs.ucl.ac.uk>
Message-ID: <20070115175401.GJ29706@amphibian.dyndns.org>

On Mon, Jan 15, 2007 at 05:25:58PM +0000, Michael Rogers wrote:
> Matthew Toseland wrote:
> > The other possibility is that this is happening naturally somehow. My
> > theory was that the node moves peripheral locations to peripheral nodes,
> > and then the peripheral nodes drop off the network.
> 
> That would explain how there could be more than one cluster. If that's 
> the cause, periodically resetting to a random location should help, right?

Would it? Or would it drive the system to be more and more absurdly
specialized? Currently, a node is introduced; its location is well
within the core area of keyspace; we swap locations with a core node,
and the peripheral node gets a peripheral location. Then the peripheral
node disconnects, and the peripheral location is destroyed. So the
keyspace gets more and more clustered towards a single point (or
multiple points). This doesn't however explain why the cluster we see is
around 0.0/1.0. Anyway, would periodic resetting help? I dunno. A new
location if it was peripheral would still be moved to a peripheral node;
a new location which was close to the core would be moved to a core node.
However, these are no longer tied to the addition or removal of nodes,
so they have more time to hang around on the network before they are
removed... So I suppose it would help. Anyone feel like running some
simulations to confirm the theory and the fix?
> 
> Cheers,
> Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/33d82233/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 17:55:20 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 17:55:20 +0000
Subject: [freenet-dev] New Frost version 07-Jan-2007
In-Reply-To: <d6149a790701072137h4af159b6u6d3761eb7a21db27@mail.gmail.com>
References: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
	<20070107235422.GJ4015@freenetproject.org>
	<d6149a790701072137h4af159b6u6d3761eb7a21db27@mail.gmail.com>
Message-ID: <20070115175520.GK29706@amphibian.dyndns.org>

On Mon, Jan 08, 2007 at 06:37:46AM +0100, bbackde at googlemail.com wrote:
> Because I now use some of the new 1.5 sync classes
> (ReentrantReadWriteLock, Semaphore) to sync the database access and
> fcp access. And 1.5 is available now for all supported platforms.

These are very small classes; it might be better to bundle a free
implementation of them and stick with 1.4 for now. Having said that, 1.5
is _very_ nice.
> 
> On 1/8/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-07 18:44:44]:
> >
> > > New Frost version available at http://jtcfrost.sourceforge.net/ , and
> > > in Freenet 0.5 and 0.7 soon.
> > >
> > > Please add this version to the freenet installer. I added the freenet
> > > boards as recommended.
> >
> > Done... May I ask why you have switched to 1.5 only code ?
> >
> > NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/23caabcd/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Jan 15 19:43:46 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 15 Jan 2007 19:43:46 +0000
Subject: [freenet-dev] [freenet-support] Freenet tests
In-Reply-To: <ff050d550612282318r5f382750o1e3d35cc8172086c@mail.gmail.com>
References: <ff050d550612282318r5f382750o1e3d35cc8172086c@mail.gmail.com>
Message-ID: <20070115194346.GB23345@amphibian.dyndns.org>

On Fri, Dec 29, 2006 at 12:18:03AM -0700, mrwigglet wrote:
> I'm trying to run some tests on a fake freenet network.  Basically, I've set
> up a bunch of nodes that start out with random locations (normal startup).
> Then I let them crank away and test how long it takes for each node to
> search for each other node.  The nodes are connected in small world fashion
> (2d grid plus random long connections).  I've used network sizes from 5 to
> 80.  The problem is that they seem to keep swapping locations with each
> other forever, without ever settling down to a stable topography.  Is this
> by design?  Do nodes always switch with each other, even if they have
> already swapped?  Am I using too few nodes to see any results?  I figured it
> should work on a net of any size, so I'm confused.

It won't work on a network that isn't small-world. That might be the
problem. How are you setting up your network?
> 
> Thanks
> mrwigglet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070115/53dee3ff/attachment.pgp 

From bbackde at googlemail.com  Mon Jan 15 22:04:59 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Mon, 15 Jan 2007 23:04:59 +0100
Subject: [freenet-dev] New Frost version 07-Jan-2007
In-Reply-To: <20070115175520.GK29706@amphibian.dyndns.org>
References: <d6149a790701070944v78bf7414t701b1a57381eeaa2@mail.gmail.com>
	<20070107235422.GJ4015@freenetproject.org>
	<d6149a790701072137h4af159b6u6d3761eb7a21db27@mail.gmail.com>
	<20070115175520.GK29706@amphibian.dyndns.org>
Message-ID: <d6149a790701151404o46a1f1fcj4a8148f0f538fb04@mail.gmail.com>

No user complained about 1.5, so this is ok for frost.

On 1/15/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> On Mon, Jan 08, 2007 at 06:37:46AM +0100, bbackde at googlemail.com wrote:
> > Because I now use some of the new 1.5 sync classes
> > (ReentrantReadWriteLock, Semaphore) to sync the database access and
> > fcp access. And 1.5 is available now for all supported platforms.
>
> These are very small classes; it might be better to bundle a free
> implementation of them and stick with 1.4 for now. Having said that, 1.5
> is _very_ nice.
> >
> > On 1/8/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-07 18:44:44]:
> > >
> > > > New Frost version available at http://jtcfrost.sourceforge.net/ , and
> > > > in Freenet 0.5 and 0.7 soon.
> > > >
> > > > Please add this version to the freenet installer. I added the freenet
> > > > boards as recommended.
> > >
> > > Done... May I ask why you have switched to 1.5 only code ?
> > >
> > > NextGen$
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFq8AIA9rUluQ9pFARArY9AJ9+TYLWgVzbKvnLN79CAk5sXIOWGQCgvCNJ
> j5U7JuHNw9iGjHRndIibeL8=
> =hJ9B
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>


From juiceman69 at gmail.com  Mon Jan 15 23:25:11 2007
From: juiceman69 at gmail.com (Juiceman)
Date: Mon, 15 Jan 2007 18:25:11 -0500
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <20070115175401.GJ29706@amphibian.dyndns.org>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<459BD19C.7050202@cs.ucl.ac.uk>
	<20070115155130.GF29706@amphibian.dyndns.org>
	<45ABB926.5020107@cs.ucl.ac.uk>
	<20070115175401.GJ29706@amphibian.dyndns.org>
Message-ID: <8b525dee0701151525u6d74d11dn260792d9b12d8380@mail.gmail.com>

On 1/15/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> On Mon, Jan 15, 2007 at 05:25:58PM +0000, Michael Rogers wrote:
> > Matthew Toseland wrote:
> > > The other possibility is that this is happening naturally somehow. My
> > > theory was that the node moves peripheral locations to peripheral nodes,
> > > and then the peripheral nodes drop off the network.
> >
> > That would explain how there could be more than one cluster. If that's
> > the cause, periodically resetting to a random location should help, right?
>
> Would it? Or would it drive the system to be more and more absurdly
> specialized? Currently, a node is introduced; its location is well
> within the core area of keyspace; we swap locations with a core node,
> and the peripheral node gets a peripheral location. Then the peripheral
> node disconnects, and the peripheral location is destroyed. So the
> keyspace gets more and more clustered towards a single point (or
> multiple points). This doesn't however explain why the cluster we see is
> around 0.0/1.0. Anyway, would periodic resetting help? I dunno. A new
> location if it was peripheral would still be moved to a peripheral node;
> a new location which was close to the core would be moved to a core node.
> However, these are no longer tied to the addition or removal of nodes,
> so they have more time to hang around on the network before they are
> removed... So I suppose it would help. Anyone feel like running some
> simulations to confirm the theory and the fix?
> >
> > Cheers,
> > Michael

Won't we be able to test this theory from the forced network reset?
My node has a different location now (not 0/1 anymore).  However, it
seems my peers while distributed better than before are moving to 0/1.
 Four already have.

-- 
I may disagree with what you have to say, but I shall defend, to the
death, your right to say it. - Voltaire
Those who would give up Liberty, to purchase temporary Safety, deserve
neither Liberty nor Safety. - Ben Franklin


From bbackde at googlemail.com  Wed Jan 17 07:28:41 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Wed, 17 Jan 2007 08:28:41 +0100
Subject: [freenet-dev] DDA autocheck
Message-ID: <d6149a790701162328x4bd40ca4i86de7d647725faa9@mail.gmail.com>

Could the node provide a functionality to check DDA access to a given
file? Currently Frost writes a file and tells the node to create the
URI of this file. If the node can access the file then DDA is
possible. But to check if the node can write to the file a GET would
be needed, and this could take some time.
I want a FCP2 command to let check the node read/write access to a
given file to check if DDA is really possible.

Thanks!


From nextgens at freenetproject.org  Wed Jan 17 07:36:18 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Wed, 17 Jan 2007 08:36:18 +0100
Subject: [freenet-dev] DDA autocheck
In-Reply-To: <d6149a790701162328x4bd40ca4i86de7d647725faa9@mail.gmail.com>
References: <d6149a790701162328x4bd40ca4i86de7d647725faa9@mail.gmail.com>
Message-ID: <20070117073617.GA4061@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-17 08:28:41]:

> Could the node provide a functionality to check DDA access to a given
> file? Currently Frost writes a file and tells the node to create the
> URI of this file. If the node can access the file then DDA is
> possible. But to check if the node can write to the file a GET would
> be needed, and this could take some time.
> I want a FCP2 command to let check the node read/write access to a
> given file to check if DDA is really possible.
> 
> Thanks!

Well, beeing able to access the file doesn't mean you are on the same
computer!

It could be a mounted network filesystem or even worst ; a copy of the
files you are testing located in the same path.

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070117/1a273b90/attachment.pgp 

From bbackde at googlemail.com  Wed Jan 17 08:16:56 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Wed, 17 Jan 2007 09:16:56 +0100
Subject: [freenet-dev] DDA autocheck
In-Reply-To: <20070117073617.GA4061@freenetproject.org>
References: <d6149a790701162328x4bd40ca4i86de7d647725faa9@mail.gmail.com>
	<20070117073617.GA4061@freenetproject.org>
Message-ID: <d6149a790701170016g4ad2f586ke8936c8c396b5736@mail.gmail.com>

I know there are many reasons why this could fail, but it would help
for the most users.

On 1/17/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-17 08:28:41]:
>
> > Could the node provide a functionality to check DDA access to a given
> > file? Currently Frost writes a file and tells the node to create the
> > URI of this file. If the node can access the file then DDA is
> > possible. But to check if the node can write to the file a GET would
> > be needed, and this could take some time.
> > I want a FCP2 command to let check the node read/write access to a
> > given file to check if DDA is really possible.
> >
> > Thanks!
>
> Well, beeing able to access the file doesn't mean you are on the same
> computer!
>
> It could be a mounted network filesystem or even worst ; a copy of the
> files you are testing located in the same path.
>
> NextGen$
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFrdHxU/Z/dHFfxtcRAkvwAJ9E4pXrlHNXLk+ts3B15cdo/qhDpACfdbQs
> o7tTz+m4dzIf9dXqNlOEDFQ=
> =Bt2J
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>


From m.rogers at cs.ucl.ac.uk  Wed Jan 17 11:36:55 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Wed, 17 Jan 2007 11:36:55 +0000
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <20070115175401.GJ29706@amphibian.dyndns.org>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<459BD19C.7050202@cs.ucl.ac.uk>
	<20070115155130.GF29706@amphibian.dyndns.org>
	<45ABB926.5020107@cs.ucl.ac.uk>
	<20070115175401.GJ29706@amphibian.dyndns.org>
Message-ID: <45AE0A57.9090908@cs.ucl.ac.uk>

Matthew Toseland wrote:
> Anyone feel like running some
> simulations to confirm the theory and the fix?

OK, but we need to come up with a precise model of what's happening 
before we can simulate it. There seem to be two possible causes: 
non-uniform clustering and non-uniform lifetime (maybe both).

Lifetime is relatively easy: assign each new node a lifetime drawn from 
some distribution (fixed, exponential, power law seem like plausible 
candidates).

Clustering is harder: here's an initial suggestion adapted from [1]. 
Each new node connects to m neighbours. The first neighbour is chosen at 
random. Then for each of the m-1 remaining neighbours, with probability 
p you choose a random neighbour of your existing neighbours (this 
creates clustering); with probability 1-p you choose a random node.

The value of p can be different for each node, so we can test what 
happens when clustering is correlated with lifetime (ie long-lived nodes 
form clusters and short-lived nodes are peripheral).

Cheers,
Michael

[1] http://nlsc.ustc.edu.cn/BJKim/PAPER/PRE_CLUS.PDF (the paper uses 
preferential attachment and therefore creates scale-free networks, but 
my suggestion above doesn't use preferential attachment)


From m.rogers at cs.ucl.ac.uk  Wed Jan 17 12:04:40 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Wed, 17 Jan 2007 12:04:40 +0000
Subject: [freenet-dev] [freenet-support] Freenet tests
In-Reply-To: <20070115194346.GB23345@amphibian.dyndns.org>
References: <ff050d550612282318r5f382750o1e3d35cc8172086c@mail.gmail.com>
	<20070115194346.GB23345@amphibian.dyndns.org>
Message-ID: <45AE10D8.1090403@cs.ucl.ac.uk>

>> The nodes are connected in small world fashion
>> (2d grid plus random long connections).  I've used network sizes from 5 to
>> 80.  The problem is that they seem to keep swapping locations with each
>> other forever, without ever settling down to a stable topography.

As far as I know, the probability of swapping never reaches zero unless 
the network reaches a perfect Kleinberg distribution (which in Oskar's 
experiments sometimes didn't happen even for networks that were created 
with a Kleinberg distribution and then scrambled - and it sounds like 
you're starting from a Watts-Strogatz small world rather than a 
Kleinberg small world).

But even though it never reaches zero, the probability of swapping 
should decrease with time as long as the network is stable.

Cheers,
Michael


From toad at amphibian.dyndns.org  Wed Jan 17 12:28:38 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 17 Jan 2007 12:28:38 +0000
Subject: [freenet-dev] Wierd clustering behaviour again
In-Reply-To: <45AE0A57.9090908@cs.ucl.ac.uk>
References: <20061219194141.GA29211@amphibian.dyndns.org>
	<459BD19C.7050202@cs.ucl.ac.uk>
	<20070115155130.GF29706@amphibian.dyndns.org>
	<45ABB926.5020107@cs.ucl.ac.uk>
	<20070115175401.GJ29706@amphibian.dyndns.org>
	<45AE0A57.9090908@cs.ucl.ac.uk>
Message-ID: <20070117122838.GA20657@amphibian.dyndns.org>

On Wed, Jan 17, 2007 at 11:36:55AM +0000, Michael Rogers wrote:
> Matthew Toseland wrote:
> > Anyone feel like running some
> > simulations to confirm the theory and the fix?
> 
> OK, but we need to come up with a precise model of what's happening 
> before we can simulate it. There seem to be two possible causes: 
> non-uniform clustering and non-uniform lifetime (maybe both).
> 
> Lifetime is relatively easy: assign each new node a lifetime drawn from 
> some distribution (fixed, exponential, power law seem like plausible 
> candidates).
> 
> Clustering is harder: here's an initial suggestion adapted from [1]. 
> Each new node connects to m neighbours. The first neighbour is chosen at 
> random. Then for each of the m-1 remaining neighbours, with probability 
> p you choose a random neighbour of your existing neighbours (this 
> creates clustering); with probability 1-p you choose a random node.
> 
> The value of p can be different for each node, so we can test what 
> happens when clustering is correlated with lifetime (ie long-lived nodes 
> form clusters and short-lived nodes are peripheral).
> 
> Cheers,
> Michael
> 
> [1] http://nlsc.ustc.edu.cn/BJKim/PAPER/PRE_CLUS.PDF (the paper uses 
> preferential attachment and therefore creates scale-free networks, but 
> my suggestion above doesn't use preferential attachment)

Well, if we are actually getting a scale-free network that could be a
problem too; small world != scale free, and scale free would actually
work remarkably poorly for freenet. (I wonder if that is in fact what is
happening? Hrrrm...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070117/7e870478/attachment.pgp 

From bbackde at googlemail.com  Sun Jan 21 20:48:27 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Sun, 21 Jan 2007 21:48:27 +0100
Subject: [freenet-dev] FCP2 protocol incomplete for persistent requests
	handling
Message-ID: <d6149a790701211248l1b905a72w353c5dbdcdc5c005@mail.gmail.com>

Is it a known issue that the FCP2 protocol is very incomplete
regarding the handling of global queue items? Currently FCP2 clients
are forced to periodically call ListPersistentRequests to keep up to
date with the global queue items. This is very annoying and shows that
the nodes implementation was only half done.

Please provide full informations about the changes in the global
queue, ideally no client have to use ListPersistentRequests after it
sent a WatchGlobal message. Currently all the work is put onto the
clients.


From rah at bash.sh  Mon Jan 22 19:08:37 2007
From: rah at bash.sh (Bob Ham)
Date: Mon, 22 Jan 2007 19:08:37 +0000
Subject: [freenet-dev] emu
Message-ID: <1169492917.2232.6.camel@orchid.arb.net>

What's up with emu?  It seems to have its port 443 closed; no svn
access.

-- 
Bob Ham <rah at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070122/3d8afe29/attachment.pgp 

From bbackde at googlemail.com  Mon Jan 22 19:53:07 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Mon, 22 Jan 2007 20:53:07 +0100
Subject: [freenet-dev] emu
In-Reply-To: <1169492917.2232.6.camel@orchid.arb.net>
References: <1169492917.2232.6.camel@orchid.arb.net>
Message-ID: <d6149a790701221153j69de839ay69fedb495a2fad8c@mail.gmail.com>

Emu is completely down, and none is there to fix it. I don't know
whats going on...

On 1/22/07, Bob Ham <rah at bash.sh> wrote:
> What's up with emu?  It seems to have its port 443 closed; no svn
> access.
>
> --
> Bob Ham <rah at bash.sh>
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
>


From ian at locut.us  Mon Jan 22 20:36:05 2007
From: ian at locut.us (Ian Clarke)
Date: Mon, 22 Jan 2007 14:36:05 -0600
Subject: [freenet-dev] emu
In-Reply-To: <d6149a790701221153j69de839ay69fedb495a2fad8c@mail.gmail.com>
References: <1169492917.2232.6.camel@orchid.arb.net>
	<d6149a790701221153j69de839ay69fedb495a2fad8c@mail.gmail.com>
Message-ID: <823242bd0701221236k145a2cdfxc80cd8fc42828596@mail.gmail.com>

Works for me.

On 1/22/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
>
> Emu is completely down, and none is there to fix it. I don't know
> whats going on...
>
> On 1/22/07, Bob Ham <rah at bash.sh> wrote:
> > What's up with emu?  It seems to have its port 443 closed; no svn
> > access.
> >
> > --
> > Bob Ham <rah at bash.sh>
> >
> >
> > _______________________________________________
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> >
> >
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>


-- 
Founder and CEO, Thoof Inc
Email: ian at thoof.com
Phone: 310 295 0164
Cell: 310 593 3724
AIM: ian.clarke at mac.com
Skype: sanity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://emu.freenetproject.org/pipermail/devl/attachments/20070122/c1b63ed0/attachment.htm 

From dbkr at freenetproject.org  Mon Jan 22 22:21:15 2007
From: dbkr at freenetproject.org (Dave Baker)
Date: Mon, 22 Jan 2007 22:21:15 +0000
Subject: [freenet-dev] emu
In-Reply-To: <823242bd0701221236k145a2cdfxc80cd8fc42828596@mail.gmail.com>
References: <1169492917.2232.6.camel@orchid.arb.net>
	<d6149a790701221153j69de839ay69fedb495a2fad8c@mail.gmail.com>
	<823242bd0701221236k145a2cdfxc80cd8fc42828596@mail.gmail.com>
Message-ID: <200701222221.16397.dbkr@freenetproject.org>

On Monday 22 January 2007 20:36, Ian Clarke wrote:
> Works for me.

Really? From here, port 443 is closed. There's a web server up on port 80 
which serves http://freenetproject.org/ fine, but if I ask it for 
http://emu.freenetproject.org/, it redirects me to SSL, which of course 
doesn't work. Hence, I can't get to subversion / ViewSVN / mailing lists and 
so forth.

I'd been assuming this was a known issue.


Dave

> 
> On 1/22/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
> >
> > Emu is completely down, and none is there to fix it. I don't know
> > whats going on...
> >
> > On 1/22/07, Bob Ham <rah at bash.sh> wrote:
> > > What's up with emu?  It seems to have its port 443 closed; no svn
> > > access.
> > >
> > > --
> > > Bob Ham <rah at bash.sh>
> > >
> > >
> > > _______________________________________________
> > > Devl mailing list
> > > Devl at freenetproject.org
> > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> > >
> > >
> > >
> > _______________________________________________
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> >
> 
> 
> -- 
> Founder and CEO, Thoof Inc
> Email: ian at thoof.com
> Phone: 310 295 0164
> Cell: 310 593 3724
> AIM: ian.clarke at mac.com
> Skype: sanity
>


From freenet-devl at david.sowder.com  Mon Jan 22 23:18:07 2007
From: freenet-devl at david.sowder.com (David Sowder (Zothar))
Date: Mon, 22 Jan 2007 17:18:07 -0600
Subject: [freenet-dev] emu
In-Reply-To: <200701222221.16397.dbkr@freenetproject.org>
References: <1169492917.2232.6.camel@orchid.arb.net>	<d6149a790701221153j69de839ay69fedb495a2fad8c@mail.gmail.com>	<823242bd0701221236k145a2cdfxc80cd8fc42828596@mail.gmail.com>
	<200701222221.16397.dbkr@freenetproject.org>
Message-ID: <45B5462F.7010502@david.sowder.com>

Dave Baker wrote:
> On Monday 22 January 2007 20:36, Ian Clarke wrote:
>   
>> Works for me.
>>     
>
> Really? From here, port 443 is closed. There's a web server up on port 80 
> which serves http://freenetproject.org/ fine, but if I ask it for 
> http://emu.freenetproject.org/, it redirects me to SSL, which of course 
> doesn't work. Hence, I can't get to subversion / ViewSVN / mailing lists and 
> so forth.
>
> I'd been assuming this was a known issue.
>   
It's been mentioned a few times on #freenet so I also thought it was a
known issue.  I've got a commit waiting for it to come back.

A quick reproduction of part of the problem for me is trying to bring up
Mantis:

https://bugs.freenetproject.org/

gives me a

Unable to connect: Firefox can't establish a connection to the server at
bugs.freenetproject.org.
>> On 1/22/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
>>     
>>> Emu is completely down, and none is there to fix it. I don't know
>>> whats going on...
>>>
>>> On 1/22/07, Bob Ham <rah at bash.sh> wrote:
>>>       
>>>> What's up with emu?  It seems to have its port 443 closed; no svn
>>>> access.
>>>>         


From rah at bash.sh  Tue Jan 23 09:09:11 2007
From: rah at bash.sh (Bob Ham)
Date: Tue, 23 Jan 2007 09:09:11 +0000
Subject: [freenet-dev] emu
In-Reply-To: <45B5462F.7010502@david.sowder.com>
References: <1169492917.2232.6.camel@orchid.arb.net>
	<d6149a790701221153j69de839ay69fedb495a2fad8c@mail.gmail.com>
	<823242bd0701221236k145a2cdfxc80cd8fc42828596@mail.gmail.com>
	<200701222221.16397.dbkr@freenetproject.org>
	<45B5462F.7010502@david.sowder.com>
Message-ID: <1169543351.2232.9.camel@orchid.arb.net>

On Mon, 2007-01-22 at 17:18 -0600, David Sowder (Zothar) wrote:
>  I've got a commit waiting for it to come back.

I'd note it's still not up this morning, which is about three days it's
been down.  Who's responsible for emu?  Are they on this list?

Cheers,

Bob

-- 
Bob Ham <rah at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070123/e67f4701/attachment.pgp 

From dbkr at freenetproject.org  Tue Jan 23 10:40:03 2007
From: dbkr at freenetproject.org (Dave Baker)
Date: Tue, 23 Jan 2007 10:40:03 +0000
Subject: [freenet-dev] Fwd: Re:  emu
Message-ID: <200701231040.04034.dbkr@freenetproject.org>

Hi,

I don't know whether all of you are subscribed to devl at freenetproject.org, or 
have been reading it, but emu's secure web server has been down for a few 
days now, so subversion, trac, lurker and the like are all unavailable, and 
there is at least one commit waiting to go in.

You're the only people I can think of that might have access to fix it.

Thanks,


Dave
-------------- next part --------------
An embedded message was scrubbed...
From: Bob Ham <rah at bash.sh>
Subject: Re: [freenet-dev] emu
Date: Tue, 23 Jan 2007 09:09:11 +0000
Size: 5203
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20070123/85671d1f/attachment.eml 

From edt at aei.ca  Tue Jan 23 12:39:22 2007
From: edt at aei.ca (Ed Tomlinson)
Date: Tue, 23 Jan 2007 07:39:22 -0500
Subject: [freenet-dev] ip v6 when no ip v6 is present
In-Reply-To: <45B5462F.7010502@david.sowder.com>
References: <1169492917.2232.6.camel@orchid.arb.net>
	<200701222221.16397.dbkr@freenetproject.org>
	<45B5462F.7010502@david.sowder.com>
Message-ID: <200701230739.22329.edt@aei.ca>

Hi,

For some reason my node thinks it should be attempting connections using ip v6.  There is not v6 built into my kernel.
What happens is:

an 23, 2007 12:37:19:587 (freenet.io.comm.UdpSocketManager, PacketSender thread for 0, NORMAL): Error while sending packet to IP
v6 address: 2002:ffff:61d2:0:0:0:0:1%2:9999: java.net.SocketException: Protocol family unavailable
java.net.SocketException: Protocol family unavailable
        at java.net.PlainDatagramSocketImpl.send(Native Method)
        at java.net.PlainDatagramSocketImpl.send(PlainDatagramSocketImpl.java:134)
        at java.net.DatagramSocket.send(DatagramSocket.java:624)
        at freenet.io.comm.UdpSocketManager.sendPacket(UdpSocketManager.java:613)
        at freenet.node.FNPPacketMangler.sendPacket(FNPPacketMangler.java:508)
        at freenet.node.FNPPacketMangler.sendAuthPacket(FNPPacketMangler.java:496)
        at freenet.node.FNPPacketMangler.sendAuthPacket(FNPPacketMangler.java:461)
        at freenet.node.FNPPacketMangler.sendFirstHalfDHPacket(FNPPacketMangler.java:439)
        at freenet.node.FNPPacketMangler.sendHandshake(FNPPacketMangler.java:1506)
        at freenet.node.PacketSender.realRun(PacketSender.java:293)
        at freenet.node.PacketSender.run(PacketSender.java:123)
        at java.lang.Thread.run(Thread.java:797)

is repeated every couple of seconds.  This is the first node in my peers file.

This makes my node rather useless...

How does freenet decide to try v6?  How does not tell it not to use v6 ever?  In any case it should not loop.

Thanks
Ed


From edt at aei.ca  Tue Jan 23 13:47:15 2007
From: edt at aei.ca (Ed Tomlinson)
Date: Tue, 23 Jan 2007 08:47:15 -0500
Subject: [freenet-dev] ip v6 when no ip v6 is present
In-Reply-To: <200701230739.22329.edt@aei.ca>
References: <1169492917.2232.6.camel@orchid.arb.net>
	<45B5462F.7010502@david.sowder.com> <200701230739.22329.edt@aei.ca>
Message-ID: <200701230847.16200.edt@aei.ca>

On Tuesday 23 January 2007 07:39, Ed Tomlinson wrote:

If I compile in IPv6 the error changes to:

Jan 23, 2007 13:44:36:838 (freenet.node.Node, PacketSender thread for 0, NORMAL): Connected: 0  Routing Backed Off: 0  Too New: 0
  Too Old: 0  Disconnected: 10  Never Connected: 0  Disabled: 0  Bursting: 0  Listening: 0  Listen Only: 0
Jan 23, 2007 13:44:39:458 (freenet.io.comm.UdpSocketManager, PacketSender thread for 0, NORMAL): Error while sending packet to IP
v6 address: 2002:53e9:61d2:0:0:0:0:1%2:3478: java.io.IOException: Network is unreachable
java.io.IOException: Network is unreachable
        at java.net.PlainDatagramSocketImpl.send(Native Method)
        at java.net.PlainDatagramSocketImpl.send(PlainDatagramSocketImpl.java:134)
        at java.net.DatagramSocket.send(DatagramSocket.java:624)
        at freenet.io.comm.UdpSocketManager.sendPacket(UdpSocketManager.java:613)
        at freenet.node.FNPPacketMangler.sendPacket(FNPPacketMangler.java:508)
        at freenet.node.FNPPacketMangler.sendAuthPacket(FNPPacketMangler.java:496)
        at freenet.node.FNPPacketMangler.sendAuthPacket(FNPPacketMangler.java:461)
        at freenet.node.FNPPacketMangler.sendFirstHalfDHPacket(FNPPacketMangler.java:439)
        at freenet.node.FNPPacketMangler.sendHandshake(FNPPacketMangler.java:1506)
        at freenet.node.PacketSender.realRun(PacketSender.java:293)
        at freenet.node.PacketSender.run(Packe