From NEOatNHNG at users.sourceforge.net  Fri Oct  5 18:20:50 2007
From: NEOatNHNG at users.sourceforge.net (=?ISO-8859-15?Q?Michael_T=E4nzer?=)
Date: Fri, 05 Oct 2007 20:20:50 +0200
Subject: [freenet-dev] German Translation (freenet.l10n.de.v1065)
Message-ID: <47068082.20709@users.sourceforge.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

here's the new override for the German language.

regards
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBoCBPUBAMhFf+J4RAlw/AJ9eUv3Q7JwR4//VctE9qAqthiu3CgCfRIRa
Fa9QnBNCoDUj8kSJ0lQQLAI=
=RzAs
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20071005/b2f8f736/attachment.txt 

From batosai at batosai.net  Fri Oct  5 18:46:20 2007
From: batosai at batosai.net (julien)
Date: Fri, 05 Oct 2007 20:46:20 +0200
Subject: [freenet-dev] French translation (1065)
Message-ID: <4706867C.7070301@batosai.net>

Hi, here is the new file.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.fr.override.properties
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20071005/c0ba57d5/attachment.txt 

From nextgens at freenetproject.org  Sat Oct  6 17:54:37 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Sat, 6 Oct 2007 19:54:37 +0200
Subject: [freenet-dev] German Translation (freenet.l10n.de.v1065)
In-Reply-To: <47068082.20709@users.sourceforge.net>
References: <47068082.20709@users.sourceforge.net>
Message-ID: <20071006175436.GA5503@freenetproject.org>

* Michael T?nzer <NEOatNHNG at users.sourceforge.net> [2007-10-05 20:20:50]:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi everyone,
> 
> here's the new override for the German language.
> 
> regards
> Michael

Merged in r15433, thanks :)

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/20071006/f0d89288/attachment.pgp 

From nextgens at freenetproject.org  Sat Oct  6 17:56:34 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Sat, 6 Oct 2007 19:56:34 +0200
Subject: [freenet-dev] French translation (1065)
In-Reply-To: <4706867C.7070301@batosai.net>
References: <4706867C.7070301@batosai.net>
Message-ID: <20071006175632.GB5503@freenetproject.org>

* julien <batosai at batosai.net> [2007-10-05 20:46:20]:

> Hi, here is the new file.
> 

Merged on r15434, thanks :)

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/20071006/3aaaf867/attachment.pgp 

From bbackde at googlemail.com  Sat Oct 13 22:02:53 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Sun, 14 Oct 2007 00:02:53 +0200
Subject: [freenet-dev] unacceptable store shrink time
Message-ID: <d6149a790710131502l475b35a6y6aaee2cd14e61a52@mail.gmail.com>

I don't know if it works as designed, but I discovered the following
today: I wanted to shrink my full store from 81GiB cache size to
75GiB. I stopped the node, changed the store size and restarted the
node. In wrapper.log I followed the progress. The node started to scan
for holes in the store prior to shrinking it. I went away, and after
nearly 2 hours I came back and hey: the scan was at block 300.000 of
1.800.000 blocks! This is far to slow and means if I want to shrink my
store it takes around 12 hours!? Can this be faster, please?


From toad at amphibian.dyndns.org  Tue Oct 16 23:16:32 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 17 Oct 2007 00:16:32 +0100
Subject: [freenet-dev] [freenet-cvs] r15390 -
	branches/freenet-jfk/src/freenet/node
In-Reply-To: <20070929213725.GI11723@freenetproject.org>
References: <20070929181344.B6A4B479622@freenetproject.org>
	<200709292126.54294.toad@amphibian.dyndns.org>
	<20070929213725.GI11723@freenetproject.org>
Message-ID: <200710170016.34097.toad@amphibian.dyndns.org>

On Saturday 29 September 2007 22:37, you wrote:
> * Matthew Toseland <toad at amphibian.dyndns.org> [2007-09-29 21:26:53]:
> 
> > Arguably this should occur on a separate thread.
> 
> The signature might take some time, yes... but that code should be
> triggered only once every 30 mins.

We should still run it on a separate thread. If we run it on the same thread 
then we have to deal with locking i.e. we don't want to do the expensive 
operation more than once in parallel, as well as it increasing latency 
significantly during that period.
> > 
> > On Saturday 29 September 2007 19:13, you wrote:
> > > Author: nextgens
> > > Date: 2007-09-29 18:13:44 +0000 (Sat, 29 Sep 2007)
> > > New Revision: 15390
> > > 
> > > Modified:
> > >    branches/freenet-jfk/src/freenet/node/FNPPacketMangler.java
> > > Log:
> > > Renew DH parameters every 30mins
> > > 
> > > Modified: branches/freenet-jfk/src/freenet/node/FNPPacketMangler.java
> > > ===================================================================
-------------- 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/20071017/d209482e/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Oct 16 23:19:51 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 17 Oct 2007 00:19:51 +0100
Subject: [freenet-dev] unacceptable store shrink time
In-Reply-To: <d6149a790710131502l475b35a6y6aaee2cd14e61a52@mail.gmail.com>
References: <d6149a790710131502l475b35a6y6aaee2cd14e61a52@mail.gmail.com>
Message-ID: <200710170019.52399.toad@amphibian.dyndns.org>

On Saturday 13 October 2007 23:02, bbackde at googlemail.com wrote:
> I don't know if it works as designed, but I discovered the following
> today: I wanted to shrink my full store from 81GiB cache size to
> 75GiB. I stopped the node, changed the store size and restarted the
> node. In wrapper.log I followed the progress. The node started to scan
> for holes in the store prior to shrinking it. I went away, and after
> nearly 2 hours I came back and hey: the scan was at block 300.000 of
> 1.800.000 blocks! This is far to slow and means if I want to shrink my
> store it takes around 12 hours!? Can this be faster, please?

:(

We ought to do it online.

File a bug.
-------------- 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/20071017/1f405ebf/attachment.pgp 

From alejandro at mosteo.com  Wed Oct 17 21:58:42 2007
From: alejandro at mosteo.com (Jano)
Date: Wed, 17 Oct 2007 23:58:42 +0200
Subject: [freenet-dev] Spanish translation
Message-ID: <ff60il$n2q$1@ger.gmane.org>

>From frost:

----- SpanishGuy at 4PIdBIc_gLn6aTHD+T3i_f617sg ----- 2007.10.15 -
14:52:31GMT -----

International Spanish translation file is attached.

It may need some polishing since I couldn't always figure the context for
some phrases, but should serve as a starting point. It's complete for build
1065.

Could someone send it to the devel's mailing list?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freenet.l10n.es.override.properties.gz
Type: application/x-gzip
Size: 28318 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071017/388fee52/attachment.bin 

From nextgens at freenetproject.org  Wed Oct 17 22:15:18 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Thu, 18 Oct 2007 00:15:18 +0200
Subject: [freenet-dev] Spanish translation
In-Reply-To: <ff60il$n2q$1@ger.gmane.org>
References: <ff60il$n2q$1@ger.gmane.org>
Message-ID: <20071017221518.GG4219@freenetproject.org>

* Jano <alejandro at mosteo.com> [2007-10-17 23:58:42]:

> From frost:
> 
> ----- SpanishGuy at 4PIdBIc_gLn6aTHD+T3i_f617sg ----- 2007.10.15 -
> 14:52:31GMT -----
> 
> International Spanish translation file is attached.
> 
> It may need some polishing since I couldn't always figure the context for
> some phrases, but should serve as a starting point. It's complete for build
> 1065.
> 
> Could someone send it to the devel's mailing list?

Commited in r15448, thanks.

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/20071018/8d6c47eb/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 20 22:57:32 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 20 Oct 2007 23:57:32 +0100
Subject: [freenet-dev] [freenet-cvs] r15419 -
	trunk/apps/jSite/src/de/todesbaum/jsite/i18n
In-Reply-To: <20070930110018.619ED47A32B@freenetproject.org>
References: <20070930110018.619ED47A32B@freenetproject.org>
Message-ID: <200710202357.47641.toad@amphibian.dyndns.org>

You really shouldn't use java.lang.Properties for this sort of stuff.

I suggest you steal our localisation code.

On Sunday 30 September 2007 12:00, you wrote:
> Author: bombe
> Date: 2007-09-30 11:00:18 +0000 (Sun, 30 Sep 2007)
> New Revision: 15419
> 
> Modified:
>    trunk/apps/jSite/src/de/todesbaum/jsite/i18n/jSite_fr.properties
> Log:
> add correct French translations
> 
> Modified: trunk/apps/jSite/src/de/todesbaum/jsite/i18n/jSite_fr.properties
> ===================================================================
> --- trunk/apps/jSite/src/de/todesbaum/jsite/i18n/jSite_fr.properties	
2007-09-30 09:28:55 UTC (rev 15418)
> +++ trunk/apps/jSite/src/de/todesbaum/jsite/i18n/jSite_fr.properties	
2007-09-30 11:00:18 UTC (rev 15419)
> @@ -77,8 +77,8 @@
>  jsite.project.action.clone-project=Cloner le projet
>  jsite.project.action.clone-project.copy=Copie de {0}
>  jsite.project.action.clone-project.tooltip=Cloner le projet s?lectionn?
> -jsite.project.action.generate-new-key=
> -jsite.project.action.generate-new-key.tooltip=
> +jsite.project.action.generate-new-key=G?n?rer une nouvelle cl?
> +jsite.project.action.generate-new-key.tooltip=Cr?e une nouvelle cl? pour 
ce projet
>  jsite.project.project.information=Informations concernant le projet
>  jsite.project.project.name=Nom
>  jsite.project.project.description=Description
> @@ -91,7 +91,7 @@
>  jsite.project.keygen.io-error=<html><b>Erreur de communication avec le 
noeud</b><br><br>La communication avec le noeud ? ?chou?
e<br>Erreur:<br><br><code>{0}</code><br><br>Assurez vous que les informations 
saisies dans la page de configuration sont correctes.</html>
>  jsite.project.warning.no-local-path=<html><b>Pas de chemin local sp?cifi?
</b><br><br>Vous avez omis de sp?cifier le chemin local ? ins?rer.</html>
>  jsite.project.warning.no-path=<html><b>Vous n'avez pas sp?cifi? de chemin 
dans le freesite</b><br><br>Vous n'avez pas sp?cifi? de chemin dans le 
freesite.<br>Ce champ est n?cessaire.</html>
> -jsite.project.warning.generate-new-key=
> +jsite.project.warning.generate-new-key=<html><b>G?n?rer une nouvelle cl???
??? ?</b><br><br>Si vous g?n?rez une nouvelle cl?, votre site sera publi?
<br>avec cette nouvelle cl?. La confiance que les autres<br>utilisateurs 
pla?aient dans l'ancienne cl? sera perdue !</html>
>  
>  jsite.project-files.heading=Fichiers du projet
>  jsite.project-files.description=<html>Dans cette page vous pouvez sp?
cifier les informations concernant la configuration des noeuds telles 
que:<br>Le type de contenu mime si l'auto d?tection ? ?chou?e.</html> 
> 
> 
-------------- 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/20071020/ed68c2df/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 20 23:22:42 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sun, 21 Oct 2007 00:22:42 +0100
Subject: [freenet-dev] [freenet-cvs] r15431 - in
	trunk/apps/jSite/src/de/todesbaum: jsite/gui jsite/i18n
	jsite/main util/swing
In-Reply-To: <20071005170800.9CC4F47AA5D@freenetproject.org>
References: <20071005170800.9CC4F47AA5D@freenetproject.org>
Message-ID: <200710210022.53240.toad@amphibian.dyndns.org>

I review all commits sent to cvs@ (well most commits), for security and to 
find bugs. Is this a logical unit? Smaller commits would have been nice, even 
if they temporarily break the build.

On Friday 05 October 2007 18:08, you wrote:
> Author: bombe
> Date: 2007-10-05 17:08:00 +0000 (Fri, 05 Oct 2007)
> New Revision: 15431
> 
> Added:
>    trunk/apps/jSite/src/de/todesbaum/jsite/i18n/I18nContainer.java
> Modified:
>    trunk/apps/jSite/src/de/todesbaum/jsite/gui/NodeManagerPage.java
>    trunk/apps/jSite/src/de/todesbaum/jsite/gui/ProjectFilesPage.java
>    trunk/apps/jSite/src/de/todesbaum/jsite/gui/ProjectInsertPage.java
>    trunk/apps/jSite/src/de/todesbaum/jsite/gui/ProjectPage.java
>    trunk/apps/jSite/src/de/todesbaum/jsite/i18n/I18n.java
>    trunk/apps/jSite/src/de/todesbaum/jsite/i18n/jSite_fr.properties
>    trunk/apps/jSite/src/de/todesbaum/jsite/main/Main.java
>    trunk/apps/jSite/src/de/todesbaum/jsite/main/Version.java
>    trunk/apps/jSite/src/de/todesbaum/util/swing/TWizardPage.java
> Log:
> version 0.4.9.3:
> change language on-the-fly
> add missing french translations
> 
> Modified: trunk/apps/jSite/src/de/todesbaum/jsite/gui/NodeManagerPage.java
> ===================================================================
> --- trunk/apps/jSite/src/de/todesbaum/jsite/gui/NodeManagerPage.java	
2007-10-04 23:54:31 UTC (rev 15430)
> +++ trunk/apps/jSite/src/de/todesbaum/jsite/gui/NodeManagerPage.java	
2007-10-05 17:08:00 UTC (rev 15431)
> @@ -55,6 +55,7 @@
....
-------------- 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/20071021/075bb561/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 20 23:27:06 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sun, 21 Oct 2007 00:27:06 +0100
Subject: [freenet-dev] [freenet-cvs] r15442 -
	trunk/freenet/src/freenet/support
In-Reply-To: <20071010170617.C9D2247B35B@freenetproject.org>
References: <20071010170617.C9D2247B35B@freenetproject.org>
Message-ID: <200710210027.08132.toad@amphibian.dyndns.org>

On Wednesday 10 October 2007 18:06, bombe at freenetproject.org wrote:
> Author: bombe
> Date: 2007-10-10 17:06:17 +0000 (Wed, 10 Oct 2007)
> New Revision: 15442
> 
> Modified:
>    trunk/freenet/src/freenet/support/HTMLNode.java
> Log:
> fix wrong assertion: a) don't assert in public methods, b) allow all 
possible node names, including "#" and "%"

Why don't assert in public methods?

A name is an HTML tag name - why is the below check not useful?
> 
> Modified: trunk/freenet/src/freenet/support/HTMLNode.java
> ===================================================================
> --- trunk/freenet/src/freenet/support/HTMLNode.java	2007-10-09 04:41:49 UTC 
(rev 15441)
> +++ trunk/freenet/src/freenet/support/HTMLNode.java	2007-10-10 17:06:17 UTC 
(rev 15442)
> @@ -42,9 +42,9 @@
>  	public HTMLNode(String name, String[] attributeNames, String[] 
attributeValues, String content) {
>  		
>  		Matcher nameMatcher = namePattern.matcher(name);
> -		
> -		assert nameMatcher.matches();
> -		
> +		if (!nameMatcher.matches() && !"#".equals(name) && !"%".equals(name)) {
> +			throw new IllegalArgumentException("name must start with letter and may 
only contain letters, digits, and underscore");
> +		}
>  		this.name = name.toLowerCase(Locale.ENGLISH);
>  		if ((attributeNames != null) && (attributeValues != null)) {
>  			if (attributeNames.length != attributeValues.length) {
> 
> _______________________________________________
> cvs mailing list
> cvs at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
> 
> 
-------------- 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/20071021/edcf21b2/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Oct 22 23:31:10 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 00:31:10 +0100
Subject: [freenet-dev] [freenet-cvs] r15459 -
	trunk/freenet/src/freenet/node/useralerts
In-Reply-To: <20071020194539.DBC2F47A119@freenetproject.org>
References: <20071020194539.DBC2F47A119@freenetproject.org>
Message-ID: <200710230031.16867.toad@amphibian.dyndns.org>

Do we still need MeaningfulNodeNameUserAlert ? Isn't it simpler/better to just 
ask the user once in the first-time wizard?

On Saturday 20 October 2007 20:45, bombe at freenetproject.org wrote:
> Author: bombe
> Date: 2007-10-20 19:45:39 +0000 (Sat, 20 Oct 2007)
> New Revision: 15459
> 
> Modified:
>    
trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java
> Log:
> fix HTMLNode usage
> 
> Modified: 
trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java
> ===================================================================
> --- 
trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java	
2007-10-20 19:41:34 UTC (rev 15458)
> +++ 
trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java	
2007-10-20 19:45:39 UTC (rev 15459)
> @@ -39,7 +39,7 @@
>  
>  		HTMLNode alertNode = new HTMLNode("div");
>  		HTMLNode textNode = alertNode.addChild("div");
> -		textNode.addChild(l10n("noNodeNick"));
> +		textNode.addChild("#", l10n("noNodeNick"));
>  		HTMLNode formNode = alertNode.addChild("form", new String[] 
{ "action", "method" }, new String[] { "/config/", "post" });
>  		formNode.addChild("input", new String[] { "type", "name", "value" }, new 
String[] { "hidden", "formPassword", node.clientCore.formPassword });
>  		HTMLNode listNode = formNode.addChild("ul", "class", "config");
> 
> _______________________________________________
> cvs mailing list
> cvs at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
> 
> 
-------------- 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/20071023/1bb35788/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Oct 22 23:45:28 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 00:45:28 +0100
Subject: [freenet-dev] [freenet-cvs] r15469 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071021152724.977DA479884@freenetproject.org>
References: <20071021152724.977DA479884@freenetproject.org>
Message-ID: <200710230045.29024.toad@amphibian.dyndns.org>

On Sunday 21 October 2007 16:27, you wrote:
> Author: nextgens
> Date: 2007-10-21 15:27:24 +0000 (Sun, 21 Oct 2007)
> New Revision: 15469
> 
> Modified:
>    trunk/freenet/src/freenet/node/FNPPacketMangler.java
>    trunk/freenet/src/freenet/node/PeerNode.java
> Log:
> JFK:
> 	* Keep 10 signed exponents in a FIFO queue
> 	* Serve a new one whenever possible
> 	* Refill the queue every 30 sec if needed
> 
> That's probably better this way. What about the NewArbitraryValue I've 
introduced? well you tell me :p

Increasing it uses more memory, and an attacker could exhaust a larger queue 
almost as quickly. However it would allow slightly more forward secrecy under 
heavy load. But the difference is marginal: our *real* forward secrecy 
depends on how long the connections retain the negotiated keys, not on their 
being completely unrelated to one another.

In fact you could argue that it's unnecesary complexity to have a queue at 
all, but since the JFK paper suggests it, it's probably a good idea.

Is 1 *new* DH exponent every 30sec a reasonable rate ?

Yes. It's a trivial amount of CPU and memory, unlike the cost of creating a 
new DH exponent per packet, which is what we'd be doing with STS (one of the 
reasons for using JFK).

Oh and you should synchronize on pn when accessing pn.jfkContext. The below 
suggests NPEs.
> 
> I wonder when we should clear the DH exponent on the responder's side...
> 
> Modified: trunk/freenet/src/freenet/node/FNPPacketMangler.java
> ===================================================================
> --- trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-21 14:19:15 
UTC (rev 15468)
> +++ trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-21 15:27:24 
UTC (rev 15469)
> @@ -8,6 +8,8 @@
>  
>  import java.security.MessageDigest;
>  import java.util.Arrays;
> +import java.util.LinkedList;
> +
>  import net.i2p.util.NativeBigInteger;
>  import freenet.crypt.BlockCipher;
>  import freenet.crypt.DSA;
> @@ -81,8 +83,8 @@
>  		JFK_PREFIX_RESPONDER = R;
>  	}
>  	
> -	/** We renew it every 30sec (the spec. says "once a while") - access is 
synchronized! */
> -	private DiffieHellmanLightContext currentDHContext = null;
> +	public final static int DH_CONTEXT_BUFFER_SIZE = 10;
> +	private final LinkedList dhContextBuffer = new LinkedList();
>  	private long currentDHContextLifetime = 0;
>  	
>  	protected static final int NONCE_SIZE = 8;
> @@ -506,9 +508,10 @@
>  	 */
>  	private void sendJFKMessage1(PeerNode pn, Peer replyTo) {
>  		if(logMINOR) Logger.minor(this, "Sending a JFK(1) message to "+pn);
> -		DiffieHellmanLightContext dhContext = getLightDiffieHellmanContext();
> +		if(pn.jfkContext == null) // get a new DH exponents only if needed
> +			pn.jfkContext = getLightDiffieHellmanContext();
>  		int offset = 0;
> -		byte[] myExponential = 
stripBigIntegerToNetworkFormat(dhContext.myExponential);
> +		byte[] myExponential = 
stripBigIntegerToNetworkFormat(pn.jfkContext.myExponential);
>  		byte[] nonce = new byte[NONCE_SIZE];
>  		node.random.nextBytes(nonce);
>  		
> @@ -535,14 +538,14 @@
>  	 */
>  	private void sendJFKMessage2(byte[] nonceInitator, byte[] hisExponential, 
PeerNode pn, Peer replyTo) {
>  		if(logMINOR) Logger.minor(this, "Sending a JFK(2) message to "+pn);
> -		DiffieHellmanLightContext dhContext = getLightDiffieHellmanContext();
> +		pn.jfkContext = getLightDiffieHellmanContext();
>  		// g^r
> -		byte[] myExponential = 
stripBigIntegerToNetworkFormat(dhContext.myExponential);
> +		byte[] myExponential = 
stripBigIntegerToNetworkFormat(pn.jfkContext.myExponential);
>  		// Nr
>  		byte[] myNonce = new byte[NONCE_SIZE];
>  		node.random.nextBytes(myNonce);
> -		byte[] r = 
dhContext.signature.getRBytes(Node.SIGNATURE_PARAMETER_LENGTH);
> -		byte[] s = 
dhContext.signature.getSBytes(Node.SIGNATURE_PARAMETER_LENGTH);
> +		byte[] r = 
pn.jfkContext.signature.getRBytes(Node.SIGNATURE_PARAMETER_LENGTH);
> +		byte[] s = 
pn.jfkContext.signature.getSBytes(Node.SIGNATURE_PARAMETER_LENGTH);
>  		HMAC hash = new HMAC(SHA256.getInstance());
>  		byte[] authenticator = 
hash.mac(getTransientKey(),assembleJFKAuthenticator(myExponential, 
hisExponential, myNonce, nonceInitator, replyTo.getAddress().getAddress()), 
HASH_LENGTH);
>  		if(logMINOR) Logger.minor(this, "We are using the following HMAC : " + 
HexUtil.bytesToHex(authenticator));
> @@ -775,8 +778,7 @@
>  		System.arraycopy(payload, inputOffset, hmac, 0, HASH_LENGTH);
>  		inputOffset += HASH_LENGTH;
>  		
> -		DiffieHellmanLightContext dhContext = getLightDiffieHellmanContext();
> -		BigInteger computedExponential = dhContext.getHMACKey(_hisExponential, 
Global.DHgroupA);
> +		BigInteger computedExponential = 
pn.jfkContext.getHMACKey(_hisExponential, Global.DHgroupA);
>  		byte[] Ks = computeJFKSharedKey(computedExponential, nonceInitiator, 
nonceResponder, "0");
>  		byte[] Ke = computeJFKSharedKey(computedExponential, nonceInitiator, 
nonceResponder, "1");
>  		byte[] Ka = computeJFKSharedKey(computedExponential, nonceInitiator, 
nonceResponder, "2");
> @@ -979,6 +981,9 @@
>  		pn.jfkKa = null;
>  		pn.jfkKe = null;
>  		pn.jfkKs = null;
> +		// We want to clear it here so that new handshake requests
> +		// will be sent with a different DH pair
> +		pn.jfkContext = null;
>  		synchronized (pn) {
>  			// FIXME TRUE MULTI-HOMING: winner-takes-all, kill all other connection 
attempts since we can't deal with multiple active connections
>  			// Also avoids leaking
> @@ -1004,8 +1009,7 @@
>  		if(logMINOR) Logger.minor(this, "Sending a JFK(3) message to "+pn);
>  		BlockCipher c = null;
>  		try { c = new Rijndael(256, 256); } catch (UnsupportedCipherException e) 
{}
> -		DiffieHellmanLightContext dhContext = getLightDiffieHellmanContext();
> -		byte[] ourExponential = 
stripBigIntegerToNetworkFormat(dhContext.myExponential);
> +		byte[] ourExponential = 
stripBigIntegerToNetworkFormat(pn.jfkContext.myExponential);
>  		pn.jfkMyRef = crypto.myCompressedSetupRef();
>  		byte[] data = new byte[8 + pn.jfkMyRef.length];
>  		System.arraycopy(Fields.longToBytes(node.bootID), 0, data, 0, 8);
> @@ -1047,7 +1051,7 @@
>  		byte[] r = localSignature.getRBytes(Node.SIGNATURE_PARAMETER_LENGTH);
>  		byte[] s = localSignature.getSBytes(Node.SIGNATURE_PARAMETER_LENGTH);
>  		
> -		BigInteger computedExponential = dhContext.getHMACKey(_hisExponential, 
Global.DHgroupA);
> +		BigInteger computedExponential = 
pn.jfkContext.getHMACKey(_hisExponential, Global.DHgroupA);
>  		pn.jfkKs = computeJFKSharedKey(computedExponential, nonceInitiator, 
nonceResponder, "0");
>  		pn.jfkKe = computeJFKSharedKey(computedExponential, nonceInitiator, 
nonceResponder, "1");
>  		pn.jfkKa = computeJFKSharedKey(computedExponential, nonceInitiator, 
nonceResponder, "2");
> @@ -1174,6 +1178,7 @@
>  			else
>  				authenticatorCache.put(authenticator, message4);
>  		}
> +		
>  		sendAuthPacket(1, 2, 3, message4, pn, replyTo);
>  	}
>  
> @@ -2470,33 +2475,46 @@
>  		final long now = System.currentTimeMillis();
>  		
>  		boolean changeDHExponents = false;
> +		boolean generateOnThread = false;
> +		int dhContextBufferSize = 0;
>  		
> -		synchronized (this) {
> -			if((currentDHContext == null) || (currentDHContextLifetime + 
30000 /*30sec*/) < now) {
> +		synchronized (dhContextBuffer) {
> +			dhContextBufferSize = dhContextBuffer.size();
> +			
> +			if(dhContextBufferSize < 1) {
> +				// We need one exponent, generate it at all cost! (startup)
>  				changeDHExponents = true;
> +				generateOnThread = true;
> +			} else if((dhContextBufferSize < DH_CONTEXT_BUFFER_SIZE) && 
(currentDHContextLifetime + 30000 /*30sec*/) < now) {
> +				changeDHExponents = true;
>  				currentDHContextLifetime = now;
>  			}
>  		}
>  		
>  		if(changeDHExponents) {
> -			if(currentDHContext == null) {
> +			if(generateOnThread) {
>  				Logger.minor(this, "No DH exponent have been created; generate the 
context on-thread!");
>  				// No need to synchronize here as we are on-thread
> -				currentDHContext = _genLightDiffieHellmanContext();
> +				dhContextBuffer.add(_genLightDiffieHellmanContext());
>  			} else {
>  				// Use the ticket to do it off-thread
>  				node.getTicker().queueTimedJob(new Runnable() {
>  					public void run() {
> -						synchronized (this) {
> -							currentDHContext = _genLightDiffieHellmanContext();
> +						synchronized (dhContextBuffer) {
> +							dhContextBuffer.addLast(_genLightDiffieHellmanContext());
>  						}
>  					}
>  				}, 0);
>  				Logger.minor(this, "The DH exponents will been renewed soonish");
>  			}
>  		}
> -		
> -		return currentDHContext;
> +
> +		DiffieHellmanLightContext result;
> +		synchronized (dhContextBuffer) {
> +			// Don't remove the exponent from the list if it's the only remaining 
one.
> +			result = (DiffieHellmanLightContext) (dhContextBufferSize < 2 ? 
dhContextBuffer.getFirst() : dhContextBuffer.removeFirst());
> +		}
> +		return result;
>  	}
>  
>  	/*
> 
> Modified: trunk/freenet/src/freenet/node/PeerNode.java
> ===================================================================
> --- trunk/freenet/src/freenet/node/PeerNode.java	2007-10-21 14:19:15 UTC 
(rev 15468)
> +++ trunk/freenet/src/freenet/node/PeerNode.java	2007-10-21 15:27:24 UTC 
(rev 15469)
> @@ -28,6 +28,7 @@
>  import freenet.crypt.DSAGroup;
>  import freenet.crypt.DSAPublicKey;
>  import freenet.crypt.DSASignature;
> +import freenet.crypt.DiffieHellmanLightContext;
>  import freenet.crypt.KeyAgreementSchemeContext;
>  import freenet.crypt.SHA256;
>  import freenet.crypt.UnsupportedCipherException;
> @@ -96,6 +97,7 @@
>      protected byte[] jfkKe;
>      protected byte[] jfkKs;
>      protected byte[] jfkMyRef;
> +    protected DiffieHellmanLightContext jfkContext = null;
>  	
>      /** My low-level address for SocketManager purposes */
>      private Peer detectedPeer;
> 
> _______________________________________________
> cvs mailing list
> cvs at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
> 
> 
-------------- 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/20071023/fb61bf30/attachment.pgp 

From toad at amphibian.dyndns.org  Mon Oct 22 23:57:56 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 00:57:56 +0100
Subject: [freenet-dev] [freenet-cvs] r15471 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071022112248.2CC8A47B2F3@freenetproject.org>
References: <20071022112248.2CC8A47B2F3@freenetproject.org>
Message-ID: <200710230058.02354.toad@amphibian.dyndns.org>

On Monday 22 October 2007 12:22, nextgens at freenetproject.org wrote:
> Author: nextgens
> Date: 2007-10-22 11:22:47 +0000 (Mon, 22 Oct 2007)
> New Revision: 15471
> 
> Modified:
>    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> Log:
> JFK:
> 	Re-queue DH exponents so that we don't end up serving always the same even 
if we are under attack.

I'm not convinced that this is necessary... the only case where it helps is if 
the attacker doesn't see the responses to his packets, so it's a matter of IP 
spoofing. It shouldn't hurt if it's well-implemented. In any case, as I said 
on the previous mail, the only reasons to change DH exponents are:
1) If there's an undiscovered weak DH key, it would be best if we didn't use 
it for all our connections!
2) Limiting exposure (decryptability of old traffic) if the node is 
compromised i.e. forward secrecy (see Perfect Forward Secrecy). The thing is, 
all open connections can be decrypted from the period they last connected or 
rekeyed *anyway*.
3) Possibly leaking information about the exponents on each new connection 
with some new undiscovered attack. Hopefully this will be very slow.

JFK is built around the principle that you don't have to change the exponents 
on every new connection: the nonces will ensure that each connection gets a 
different key.

You might want to make it more deterministic though: have a vector, rotate 
through it, and every 30 seconds remove the beginning and add a new context 
at the end. Then contexts have a limited lifespan.
> 
> Modified: trunk/freenet/src/freenet/node/FNPPacketMangler.java
> ===================================================================
> --- trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-22 10:48:27 
UTC (rev 15470)
> +++ trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-22 11:22:47 
UTC (rev 15471)
> @@ -2460,60 +2460,64 @@
>  	}
>  
>  	private DiffieHellmanLightContext _genLightDiffieHellmanContext() {
> -		DiffieHellmanLightContext ctx = DiffieHellman.generateLightContext();
> +		final DiffieHellmanLightContext ctx = 
DiffieHellman.generateLightContext();
>  		
ctx.setSignature(crypto.sign(SHA256.digest(assembleDHParams(ctx.myExponential, 
crypto.getCryptoGroup()))));
>  		
>  		return ctx;
>  	}
>  	
> +	private final void _fillJFKDHFIFO() {
> +		// Use the ticket to do it off-thread
> +		node.getTicker().queueTimedJob(new Runnable() {
> +			public void run() {
> +				synchronized (dhContextFIFO) {
> +					dhContextFIFO.addLast(_genLightDiffieHellmanContext());
> +				}
> +			}
> +		}, 0);
> +	}
> +	
>  	/**
>  	 * Change the DH Exponents on a regular basis but at most once every 30sec
>  	 * 
>  	 * @return {@link DiffieHellmanLightContext}
> +	 * 
> +	 * FIXME: is it acceptable that some elements will stay around for a 
*long* time ?
> +	 * They will eventually be replaced but noone know when.
>  	 */
>  	private DiffieHellmanLightContext getLightDiffieHellmanContext() {
>  		final long now = System.currentTimeMillis();
>  		
> -		boolean changeDHExponents = false;
> -		boolean generateOnThread = false;
> -		int dhContextBufferSize = 0;
> +		int dhContextFIFOSize = 0;
> +		boolean requeueElement = true;
>  		
> +		DiffieHellmanLightContext result = null;
> +		
>  		synchronized (dhContextFIFO) {
> -			dhContextBufferSize = dhContextFIFO.size();
> +			dhContextFIFOSize = dhContextFIFO.size();
>  			
> -			if(dhContextBufferSize < 1) {
> +			if(dhContextFIFOSize < 1) {
>  				// We need one exponent, generate it at all cost! (startup)
> -				changeDHExponents = true;
> -				generateOnThread = true;
> -			} else if((dhContextBufferSize < DH_CONTEXT_BUFFER_SIZE) && 
(jfkDHLastGenerationTimestamp + 30000 /*30sec*/) < now) {
> -				changeDHExponents = true;
> -				jfkDHLastGenerationTimestamp = now;
> -			}
> -		}
> -		
> -		if(changeDHExponents) {
> -			if(generateOnThread) {
>  				Logger.minor(this, "No DH exponent have been created; generate the 
context on-thread!");
> -				// No need to synchronize here as we are on-thread
> -				dhContextFIFO.add(_genLightDiffieHellmanContext());
> +				for(int i=dhContextFIFOSize; i<DH_CONTEXT_BUFFER_SIZE-1; i++)
> +					_fillJFKDHFIFO();
> +				
> +				result = _genLightDiffieHellmanContext();
>  			} else {
> -				// Use the ticket to do it off-thread
> -				node.getTicker().queueTimedJob(new Runnable() {
> -					public void run() {
> -						synchronized (dhContextFIFO) {
> -							dhContextFIFO.addLast(_genLightDiffieHellmanContext());
> -						}
> -					}
> -				}, 0);
> -				Logger.minor(this, "The DH exponents will been renewed soonish");
> +				result = (DiffieHellmanLightContext) dhContextFIFO.removeFirst();
> +				
> +				// Shall we replace one element of the queue ?
> +				if((jfkDHLastGenerationTimestamp + 30000 /*30sec*/) < now) {
> +					jfkDHLastGenerationTimestamp = now;
> +					requeueElement = false;
> +					_fillJFKDHFIFO();
> +				}
>  			}
> +			
> +			if(requeueElement)
> +				dhContextFIFO.addLast(result);
>  		}
> -
> -		DiffieHellmanLightContext result;
> -		synchronized (dhContextFIFO) {
> -			// Don't remove the exponent from the list if it's the only remaining 
one.
> -			result = (DiffieHellmanLightContext) (dhContextBufferSize < 2 ? 
dhContextFIFO.getFirst() : dhContextFIFO.removeFirst());
> -		}
> +		
>  		return result;
>  	}
>  
> 
> _______________________________________________
> cvs mailing list
> cvs at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
> 
> 
-------------- 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/20071023/b08f88d3/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Oct 23 00:00:26 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 01:00:26 +0100
Subject: [freenet-dev] [freenet-cvs] r15472 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071022112856.C5B2647B315@freenetproject.org>
References: <20071022112856.C5B2647B315@freenetproject.org>
Message-ID: <200710230100.27585.toad@amphibian.dyndns.org>

On Monday 22 October 2007 12:28, you wrote:
> Author: nextgens
> Date: 2007-10-22 11:28:56 +0000 (Mon, 22 Oct 2007)
> New Revision: 15472
> 
> Modified:
>    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> Log:
> JFK:
> 	Renew DH Exponentials once every 15mins if we aren't connected yet.

This is executed on the ticker, we should avoid the latency by regenerating 
off-thread.
> 
> Modified: trunk/freenet/src/freenet/node/FNPPacketMangler.java
> ===================================================================
> --- trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-22 11:22:47 
UTC (rev 15471)
> +++ trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-22 11:28:56 
UTC (rev 15472)
> @@ -508,8 +508,11 @@
>  	 */
>  	private void sendJFKMessage1(PeerNode pn, Peer replyTo) {
>  		if(logMINOR) Logger.minor(this, "Sending a JFK(1) message to "+pn);
> -		if(pn.jfkContext == null) // get a new DH exponents only if needed
> +		final long now = System.currentTimeMillis();
> +		if((pn.jfkContext == null) || ((pn.jfkContextLifetime + 15*60*1000) < 
now)) {
>  			pn.jfkContext = getLightDiffieHellmanContext();
> +			pn.jfkContextLifetime = now;
> +		}
>  		int offset = 0;
>  		byte[] myExponential = 
stripBigIntegerToNetworkFormat(pn.jfkContext.myExponential);
>  		byte[] nonce = new byte[NONCE_SIZE];
> @@ -538,7 +541,11 @@
>  	 */
>  	private void sendJFKMessage2(byte[] nonceInitator, byte[] hisExponential, 
PeerNode pn, Peer replyTo) {
>  		if(logMINOR) Logger.minor(this, "Sending a JFK(2) message to "+pn);
> -		pn.jfkContext = getLightDiffieHellmanContext();
> +		final long now = System.currentTimeMillis();
> +		if((pn.jfkContext == null) || ((pn.jfkContextLifetime + 15*60*1000) < 
now)) {
> +			pn.jfkContext = getLightDiffieHellmanContext();
> +			pn.jfkContextLifetime = now;
> +		}
>  		// g^r
>  		byte[] myExponential = 
stripBigIntegerToNetworkFormat(pn.jfkContext.myExponential);
>  		// Nr
-------------- 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/20071023/5ce0e22d/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Oct 23 00:45:00 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 01:45:00 +0100
Subject: [freenet-dev] [freenet-cvs] r15483 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071022210120.7B42E3908BF@freenetproject.org>
References: <20071022210120.7B42E3908BF@freenetproject.org>
Message-ID: <200710230145.04535.toad@amphibian.dyndns.org>

On Monday 22 October 2007 22:01, you wrote:
> Author: nextgens
> Date: 2007-10-22 21:01:20 +0000 (Mon, 22 Oct 2007)
> New Revision: 15483
> 
> Modified:
>    trunk/freenet/src/freenet/node/RequestHandler.java
> Log:
> Simplify the logic, test for node.passOpennetRefsThroughDarknet() earlier 
on.
> 
> Don't send anything if we don't want to help path-folding.

Not sending anything is actively sabotaging path folding by causing opennet 
nodes to waste threads waiting for a message which will never come. The 
intended behaviour is to always send *something* to indicate the completion 
of the request. Normally on a pure darknet node that would simply be an 
FNPOpennetCompletedAck.

If you want to eliminate this spurious message in the pure darknet case, 
without breaking pass-opennet-refs-over-darknet which IMHO is an important 
piece of functionality, you will have to define a way for nodes to declare at 
connection time that they are not interested in opennet in any way 
whatsoever. Then we can safely not send an ack to such nodes if they 
are !wantsOpennetRefs().
> 
> Modified: trunk/freenet/src/freenet/node/RequestHandler.java
> ===================================================================
> --- trunk/freenet/src/freenet/node/RequestHandler.java	2007-10-22 20:40:07 
UTC (rev 15482)
> +++ trunk/freenet/src/freenet/node/RequestHandler.java	2007-10-22 21:01:20 
UTC (rev 15483)
> @@ -148,7 +148,8 @@
>              	node.addTransferringRequestHandler(uid);
>              	if(bt.send(node.executor)) {
>              		status = RequestSender.SUCCESS; // for byte logging
> -           			finishOpennetNoRelayChecked();
> +            		if(node.passOpennetRefsThroughDarknet())
> +            			finishOpennetNoRelayChecked();

We've fetched it from our datastore. We therefore cannot relay a downstream 
noderef. We can either send our own noderef, if we want a connection, or we 
can send an FNPOpennetCompletedAck to indicate that we don't want to.

>              	}
>              }
>              return;
> @@ -187,7 +188,8 @@
>              		finalTransferFailed = true;
>              	} else {
>      				// Successful CHK transfer, maybe path fold
> -    				finishOpennetChecked();
> +            		if(node.passOpennetRefsThroughDarknet())
> +            			finishOpennetChecked();

Again, we might have opennet enabled and pass-opennet-refs-through-darknet 
disabled, and even if not, we need to send an FNPOpennetCompletedAck.
>              	}
>  				status = rs.getStatus();
>          	    return;
> @@ -262,7 +264,7 @@
>  	}
>  
>  	private void finishOpennetChecked() {
> -		if(!(node.passOpennetRefsThroughDarknet() || source.isOpennet())) {
> +		if(!source.isOpennet()) {

This is plain wrong. If we want to pass refs through darknet peers, then we 
should pass a ref to the requester if possible. If we don't want anything to 
do with opennet, we should send an acknowledgement.

>  			Message msg = DMT.createFNPOpennetCompletedAck(uid);
>  			try {
>  				source.sendAsync(msg, null, 0, this);
> @@ -290,7 +292,7 @@
>      }
>      
>  	private void finishOpennetNoRelayChecked() {
> -		if(!(node.passOpennetRefsThroughDarknet() || source.isOpennet())) {
> +		if(!source.isOpennet()) {

Here too.

>  			Message msg = DMT.createFNPOpennetCompletedAck(uid);
>  			try {
>  				source.sendAsync(msg, null, 0, this);

Normally I would let you correct it yourself, but there were a number of 
issues which needed dealing with.

We should fix the traffic analysis vulnerability in passing opennet refs soon 
(i.e. pad the noderef to exactly 2kB and split it up into two 
packets/messages rather than sending potentially oversize, variable length 
packets). But not before 1066.
-------------- 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/20071023/dae80a3a/attachment.pgp 

From nextgens at freenetproject.org  Tue Oct 23 07:34:56 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 23 Oct 2007 09:34:56 +0200
Subject: [freenet-dev] [freenet-cvs] r15459 -
	trunk/freenet/src/freenet/node/useralerts
In-Reply-To: <200710230031.16867.toad@amphibian.dyndns.org>
References: <20071020194539.DBC2F47A119@freenetproject.org>
	<200710230031.16867.toad@amphibian.dyndns.org>
Message-ID: <20071023073455.GB4248@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 00:31:10]:

> Do we still need MeaningfulNodeNameUserAlert ? Isn't it simpler/better to just 
> ask the user once in the first-time wizard?
> 

Well, as the wizard is skippable it might be better to keep it.

> On Saturday 20 October 2007 20:45, bombe at freenetproject.org wrote:
> > Author: bombe
> > Date: 2007-10-20 19:45:39 +0000 (Sat, 20 Oct 2007)
> > New Revision: 15459
> > 
> > Modified:
> >    
> trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java
> > Log:
> > fix HTMLNode usage
> > 
> > Modified: 
> trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java
> > ===================================================================
> > --- 
> trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java	
> 2007-10-20 19:41:34 UTC (rev 15458)
> > +++ 
> trunk/freenet/src/freenet/node/useralerts/MeaningfulNodeNameUserAlert.java	
> 2007-10-20 19:45:39 UTC (rev 15459)
> > @@ -39,7 +39,7 @@
> >  
> >  		HTMLNode alertNode = new HTMLNode("div");
> >  		HTMLNode textNode = alertNode.addChild("div");
> > -		textNode.addChild(l10n("noNodeNick"));
> > +		textNode.addChild("#", l10n("noNodeNick"));
> >  		HTMLNode formNode = alertNode.addChild("form", new String[] 
> { "action", "method" }, new String[] { "/config/", "post" });
> >  		formNode.addChild("input", new String[] { "type", "name", "value" }, new 
> String[] { "hidden", "formPassword", node.clientCore.formPassword });
> >  		HTMLNode listNode = formNode.addChild("ul", "class", "config");
> > 
> > _______________________________________________
> > cvs mailing list
> > cvs at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
> > 
> > 



> _______________________________________________
> 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/20071023/4574ff65/attachment.pgp 

From nextgens at freenetproject.org  Tue Oct 23 07:56:34 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 23 Oct 2007 09:56:34 +0200
Subject: [freenet-dev] [freenet-cvs] r15469 -
	trunk/freenet/src/freenet/node
In-Reply-To: <200710230045.29024.toad@amphibian.dyndns.org>
References: <20071021152724.977DA479884@freenetproject.org>
	<200710230045.29024.toad@amphibian.dyndns.org>
Message-ID: <20071023075634.GD4248@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 00:45:28]:

> On Sunday 21 October 2007 16:27, you wrote:
> > Author: nextgens
> > Date: 2007-10-21 15:27:24 +0000 (Sun, 21 Oct 2007)
> > New Revision: 15469
> > 
> > Modified:
> >    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> >    trunk/freenet/src/freenet/node/PeerNode.java
> > Log:
> > JFK:
> > 	* Keep 10 signed exponents in a FIFO queue
> > 	* Serve a new one whenever possible
> > 	* Refill the queue every 30 sec if needed
> > 
> > That's probably better this way. What about the NewArbitraryValue I've 
> introduced? well you tell me :p
> 
> Increasing it uses more memory, and an attacker could exhaust a larger queue 
> almost as quickly. However it would allow slightly more forward secrecy under 
> heavy load. But the difference is marginal: our *real* forward secrecy 
> depends on how long the connections retain the negotiated keys, not on their 
> being completely unrelated to one another.

I might implement re-keying once the current trunk is released.

> 
> In fact you could argue that it's unnecesary complexity to have a queue at 
> all, but since the JFK paper suggests it, it's probably a good idea.
> 
> Is 1 *new* DH exponent every 30sec a reasonable rate ?
> 
> Yes. It's a trivial amount of CPU and memory, unlike the cost of creating a 
> new DH exponent per packet, which is what we'd be doing with STS (one of the 
> reasons for using JFK).
> 
> Oh and you should synchronize on pn when accessing pn.jfkContext. The below 
> suggests NPEs.

Well, I access it only in sendMessage1 & sendMessage2 and I check if
it's null there... That shouldn't be a problem anymore in current
trunk.

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/20071023/e617f8ac/attachment.pgp 

From nextgens at freenetproject.org  Tue Oct 23 08:04:42 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 23 Oct 2007 10:04:42 +0200
Subject: [freenet-dev] [freenet-cvs] r15472 -
	trunk/freenet/src/freenet/node
In-Reply-To: <200710230100.27585.toad@amphibian.dyndns.org>
References: <20071022112856.C5B2647B315@freenetproject.org>
	<200710230100.27585.toad@amphibian.dyndns.org>
Message-ID: <20071023080441.GE4248@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 01:00:26]:

> On Monday 22 October 2007 12:28, you wrote:
> > Author: nextgens
> > Date: 2007-10-22 11:28:56 +0000 (Mon, 22 Oct 2007)
> > New Revision: 15472
> > 
> > Modified:
> >    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> > Log:
> > JFK:
> > 	Renew DH Exponentials once every 15mins if we aren't connected yet.
> 
> This is executed on the ticker, we should avoid the latency by regenerating 
> off-thread.

Well, it is off-thread: we use the ticker. I don't get it :  is your point
that we shouldn't use the ticket for pre-computing things ?

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/20071023/019a1481/attachment.pgp 

From nextgens at freenetproject.org  Tue Oct 23 08:15:00 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 23 Oct 2007 10:15:00 +0200
Subject: [freenet-dev] [freenet-cvs] r15483 -
	trunk/freenet/src/freenet/node
In-Reply-To: <200710230145.04535.toad@amphibian.dyndns.org>
References: <20071022210120.7B42E3908BF@freenetproject.org>
	<200710230145.04535.toad@amphibian.dyndns.org>
Message-ID: <20071023081500.GF4248@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 01:45:00]:

> On Monday 22 October 2007 22:01, you wrote:
> > Author: nextgens
> > Date: 2007-10-22 21:01:20 +0000 (Mon, 22 Oct 2007)
> > New Revision: 15483
> > 
> > Modified:
> >    trunk/freenet/src/freenet/node/RequestHandler.java
> > Log:
> > Simplify the logic, test for node.passOpennetRefsThroughDarknet() earlier 
> on.
> > 
> > Don't send anything if we don't want to help path-folding.
> 
> Not sending anything is actively sabotaging path folding by causing opennet 
> nodes to waste threads waiting for a message which will never come. The 
> intended behaviour is to always send *something* to indicate the completion 
> of the request. Normally on a pure darknet node that would simply be an 
> FNPOpennetCompletedAck.

I hope that the code is bullet-proof against that... My node has been
acting that way since the beginning :p Well, those messages will
eventually expire anyway, won't they ?

May you add a few comments in the code about that please? It's far from
beeing obvious logic-wise as far as I'm concerned.

> 
> If you want to eliminate this spurious message in the pure darknet case, 
> without breaking pass-opennet-refs-over-darknet which IMHO is an important 
> piece of functionality, you will have to define a way for nodes to declare at 
> connection time that they are not interested in opennet in any way 
> whatsoever. Then we can safely not send an ack to such nodes if they 
> are !wantsOpennetRefs().

Ok, it got one slot on my TODO.

> > 
> > Modified: trunk/freenet/src/freenet/node/RequestHandler.java
> > ===================================================================
> > --- trunk/freenet/src/freenet/node/RequestHandler.java	2007-10-22 20:40:07 
> UTC (rev 15482)
> > +++ trunk/freenet/src/freenet/node/RequestHandler.java	2007-10-22 21:01:20 
> UTC (rev 15483)
> > @@ -148,7 +148,8 @@
> >              	node.addTransferringRequestHandler(uid);
> >              	if(bt.send(node.executor)) {
> >              		status = RequestSender.SUCCESS; // for byte logging
> > -           			finishOpennetNoRelayChecked();
> > +            		if(node.passOpennetRefsThroughDarknet())
> > +            			finishOpennetNoRelayChecked();
> 
> We've fetched it from our datastore. We therefore cannot relay a downstream 
> noderef. We can either send our own noderef, if we want a connection, or we 
> can send an FNPOpennetCompletedAck to indicate that we don't want to.
> 
> >              	}
> >              }
> >              return;
> > @@ -187,7 +188,8 @@
> >              		finalTransferFailed = true;
> >              	} else {
> >      				// Successful CHK transfer, maybe path fold
> > -    				finishOpennetChecked();
> > +            		if(node.passOpennetRefsThroughDarknet())
> > +            			finishOpennetChecked();
> 
> Again, we might have opennet enabled and pass-opennet-refs-through-darknet 
> disabled, and even if not, we need to send an FNPOpennetCompletedAck.
> >              	}
> >  				status = rs.getStatus();
> >          	    return;
> > @@ -262,7 +264,7 @@
> >  	}
> >  
> >  	private void finishOpennetChecked() {
> > -		if(!(node.passOpennetRefsThroughDarknet() || source.isOpennet())) {
> > +		if(!source.isOpennet()) {
> 
> This is plain wrong. If we want to pass refs through darknet peers, then we 
> should pass a ref to the requester if possible. If we don't want anything to 
> do with opennet, we should send an acknowledgement.
> 

Ok, now I get it but that should be commented in the code ;)

> >  			Message msg = DMT.createFNPOpennetCompletedAck(uid);
> >  			try {
> >  				source.sendAsync(msg, null, 0, this);
> > @@ -290,7 +292,7 @@
> >      }
> >      
> >  	private void finishOpennetNoRelayChecked() {
> > -		if(!(node.passOpennetRefsThroughDarknet() || source.isOpennet())) {
> > +		if(!source.isOpennet()) {
> 
> Here too.
> 
> >  			Message msg = DMT.createFNPOpennetCompletedAck(uid);
> >  			try {
> >  				source.sendAsync(msg, null, 0, this);
> 
> Normally I would let you correct it yourself, but there were a number of 
> issues which needed dealing with.
> 

You're welcome.

> We should fix the traffic analysis vulnerability in passing opennet refs soon 
> (i.e. pad the noderef to exactly 2kB and split it up into two 
> packets/messages rather than sending potentially oversize, variable length 
> packets). But not before 1066.

^-^ that should have been done since ages imho.

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/20071023/847651e2/attachment.pgp 

From nextgens at freenetproject.org  Tue Oct 23 08:44:02 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 23 Oct 2007 10:44:02 +0200
Subject: [freenet-dev] Emu, new IP address, renewed SSL certificates,
	scheduled downtime
Message-ID: <20071023084402.GG4248@freenetproject.org>

Hi,

	As some of you might have noticed, emu's IP address has changed
	(from 80.68.80.201 to 89.16.176.201). Both IP addresses should
	be available for the time being as we need to wait for DNS 
	records to propagate before deprecating the old one.

	The current set of SSL certificates in use on emu has expired,
	hence I have regenerated new ones... You can check their
	validity using openssl if you already have our CA 
	(https://emu.freenetproject.org/freenet.pem).

openssl s_client -CAfile freenet.pem -connect emu.freenetproject.org:443

	If you don't, here are the new fingerprints:
For emu.freenetproject.org
SHA1 Fingerprint=43:C3:A6:57:A1:20:85:57:0E:E6:B9:74:AC:7E:04:7C:52:E3:D2:D9
For bugs.freenetproject.org
SHA1 Fingerprint=88:BF:1F:CA:08:D1:C1:DE:9A:46:D7:FA:7F:8E:48:53:A0:B6:36:64
For the CA (still the same)
SHA1 Fingerprint=FF:E0:D8:D6:57:E6:68:51:2B:3B:38:13:80:4F:AB:71:7B:2B:B5:EF

	A side note: Emu will go down for a scheduled maintenance at
	19:50 GMT on the 25th. The downtime is planned to be of at least
	a few hours.

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/20071023/5d3d1d69/attachment.pgp 

From nextgens at freenetproject.org  Tue Oct 23 14:53:51 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 23 Oct 2007 16:53:51 +0200
Subject: [freenet-dev] [freenet-cvs] r15472 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071023080441.GE4248@freenetproject.org>
References: <20071022112856.C5B2647B315@freenetproject.org>
	<200710230100.27585.toad@amphibian.dyndns.org>
	<20071023080441.GE4248@freenetproject.org>
Message-ID: <20071023145350.GK4248@freenetproject.org>

* Florent Daigni?re <nextgens at freenetproject.org> [2007-10-23 10:04:42]:

> * Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 01:00:26]:
> 
> > On Monday 22 October 2007 12:28, you wrote:
> > > Author: nextgens
> > > Date: 2007-10-22 11:28:56 +0000 (Mon, 22 Oct 2007)
> > > New Revision: 15472
> > > 
> > > Modified:
> > >    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> > > Log:
> > > JFK:
> > > 	Renew DH Exponentials once every 15mins if we aren't connected yet.
> > 
> > This is executed on the ticker, we should avoid the latency by regenerating 
> > off-thread.
> 
> Well, it is off-thread: we use the ticker. I don't get it :  is your point
> that we shouldn't use the ticket for pre-computing things ?
> 
> NextGen$

Ok, I've switched to a proper thread using the Executor in r15496 :)

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/20071023/21c95a85/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Oct 23 16:10:45 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 17:10:45 +0100
Subject: [freenet-dev] [freenet-cvs] r15472 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071023145350.GK4248@freenetproject.org>
References: <20071022112856.C5B2647B315@freenetproject.org>
	<20071023080441.GE4248@freenetproject.org>
	<20071023145350.GK4248@freenetproject.org>
Message-ID: <200710231710.52302.toad@amphibian.dyndns.org>

On Tuesday 23 October 2007 15:53, you wrote:
> * Florent Daigni?re <nextgens at freenetproject.org> [2007-10-23 10:04:42]:
> 
> > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 01:00:26]:
> > 
> > > On Monday 22 October 2007 12:28, you wrote:
> > > > Author: nextgens
> > > > Date: 2007-10-22 11:28:56 +0000 (Mon, 22 Oct 2007)
> > > > New Revision: 15472
> > > > 
> > > > Modified:
> > > >    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> > > > Log:
> > > > JFK:
> > > > 	Renew DH Exponentials once every 15mins if we aren't connected yet.
> > > 
> > > This is executed on the ticker, we should avoid the latency by 
regenerating 
> > > off-thread.
> > 
> > Well, it is off-thread: we use the ticker. I don't get it :  is your point
> > that we shouldn't use the ticket for pre-computing things ?
> > 
> > NextGen$
> 
> Ok, I've switched to a proper thread using the Executor in r15496 :)

Ticker will use a proper thread, unless you tell it not to by using 
FastRunnable.
> 
> NextGen$
> 
-------------- 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/20071023/3b4ff66f/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Oct 23 16:12:07 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 17:12:07 +0100
Subject: [freenet-dev] [freenet-cvs] r15483 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071023081500.GF4248@freenetproject.org>
References: <20071022210120.7B42E3908BF@freenetproject.org>
	<200710230145.04535.toad@amphibian.dyndns.org>
	<20071023081500.GF4248@freenetproject.org>
Message-ID: <200710231712.08623.toad@amphibian.dyndns.org>

On Tuesday 23 October 2007 09:15, you wrote:
> * Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 01:45:00]:
> 
> > On Monday 22 October 2007 22:01, you wrote:
> > > Author: nextgens
> > > Date: 2007-10-22 21:01:20 +0000 (Mon, 22 Oct 2007)
> > > New Revision: 15483
> > > 
> > > Modified:
> > >    trunk/freenet/src/freenet/node/RequestHandler.java
> > > Log:
> > > Simplify the logic, test for node.passOpennetRefsThroughDarknet() 
earlier 
> > on.
> > > 
> > > Don't send anything if we don't want to help path-folding.
> > 
> > Not sending anything is actively sabotaging path folding by causing 
opennet 
> > nodes to waste threads waiting for a message which will never come. The 
> > intended behaviour is to always send *something* to indicate the 
completion 
> > of the request. Normally on a pure darknet node that would simply be an 
> > FNPOpennetCompletedAck.
> 
> I hope that the code is bullet-proof against that... My node has been
> acting that way since the beginning :p Well, those messages will
> eventually expire anyway, won't they ?

Bullet-proof against what? Not sending any ack? Yes, but it slows things down 
by wasting threads.
> 
> May you add a few comments in the code about that please? It's far from
> beeing obvious logic-wise as far as I'm concerned.

Didn't I just do that?
> 
> > If you want to eliminate this spurious message in the pure darknet case, 
> > without breaking pass-opennet-refs-over-darknet which IMHO is an important 
> > piece of functionality, you will have to define a way for nodes to declare 
at 
> > connection time that they are not interested in opennet in any way 
> > whatsoever. Then we can safely not send an ack to such nodes if they 
> > are !wantsOpennetRefs().
> 
> Ok, it got one slot on my TODO.
-------------- 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/20071023/dca966dd/attachment.pgp 

From nextgens at freenetproject.org  Tue Oct 23 16:15:33 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 23 Oct 2007 18:15:33 +0200
Subject: [freenet-dev] [freenet-cvs] r15483 -
	trunk/freenet/src/freenet/node
In-Reply-To: <200710231712.08623.toad@amphibian.dyndns.org>
References: <20071022210120.7B42E3908BF@freenetproject.org>
	<200710230145.04535.toad@amphibian.dyndns.org>
	<20071023081500.GF4248@freenetproject.org>
	<200710231712.08623.toad@amphibian.dyndns.org>
Message-ID: <20071023161533.GL4248@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 17:12:07]:

> On Tuesday 23 October 2007 09:15, you wrote:
> > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-23 01:45:00]:
> > 
> > > On Monday 22 October 2007 22:01, you wrote:
> > > > Author: nextgens
> > > > Date: 2007-10-22 21:01:20 +0000 (Mon, 22 Oct 2007)
> > > > New Revision: 15483
> > > > 
> > > > Modified:
> > > >    trunk/freenet/src/freenet/node/RequestHandler.java
> > > > Log:
> > > > Simplify the logic, test for node.passOpennetRefsThroughDarknet() 
> earlier 
> > > on.
> > > > 
> > > > Don't send anything if we don't want to help path-folding.
> > > 
> > > Not sending anything is actively sabotaging path folding by causing 
> opennet 
> > > nodes to waste threads waiting for a message which will never come. The 
> > > intended behaviour is to always send *something* to indicate the 
> completion 
> > > of the request. Normally on a pure darknet node that would simply be an 
> > > FNPOpennetCompletedAck.
> > 
> > I hope that the code is bullet-proof against that... My node has been
> > acting that way since the beginning :p Well, those messages will
> > eventually expire anyway, won't they ?
> 
> Bullet-proof against what? Not sending any ack? Yes, but it slows things down 
> by wasting threads.
> > 
> > May you add a few comments in the code about that please? It's far from
> > beeing obvious logic-wise as far as I'm concerned.
> 
> Didn't I just do that?

Ok, cool then :)

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/20071023/130b8c8e/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Oct 23 17:05:17 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 18:05:17 +0100
Subject: [freenet-dev] Freenet 0.7 build 1066
Message-ID: <200710231805.23257.toad@amphibian.dyndns.org>

Freenet 0.7 build 1066 is available. It will be mandatory on the 30th of 
October. It includes some fairly large changes including:
- Merge of JFK, a Summer of Code project to implement a new, better link 
encryption setup protocol (we were using a form of STS).
- The opennet peers limit takes into account connected darknet peers, so as 
you get more Friends you will lose Strangers.
- Fix a bug that caused the node to stop accepting requests after incoming 
inserts got stuck.
- Faster IP detection through plugins, and some other plugin fixes.
- Move the datastore to a subdirectory so that it is easier to move it.
- Updates to translations.
Thanks to all contributors! (nextgens, toad, bombe, kryptos, Michael Tanzer, 
batosai and SpanishGuy).
-------------- 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/20071023/65144ffe/attachment.pgp 

From toad at amphibian.dyndns.org  Tue Oct 23 17:33:02 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 23 Oct 2007 18:33:02 +0100
Subject: [freenet-dev] Freenet 0.7 build 1067
In-Reply-To: <200710231805.23257.toad@amphibian.dyndns.org>
References: <200710231805.23257.toad@amphibian.dyndns.org>
Message-ID: <200710231833.10050.toad@amphibian.dyndns.org>

1067 fixes a stupid bug in 1066. Sorry folks. Upgrade to 1067.

On Tuesday 23 October 2007 18:05, Matthew Toseland wrote:
> Freenet 0.7 build 1066 is available. It will be mandatory on the 30th of 
> October. It includes some fairly large changes including:
> - Merge of JFK, a Summer of Code project to implement a new, better link 
> encryption setup protocol (we were using a form of STS).
> - The opennet peers limit takes into account connected darknet peers, so as 
> you get more Friends you will lose Strangers.
> - Fix a bug that caused the node to stop accepting requests after incoming 
> inserts got stuck.
> - Faster IP detection through plugins, and some other plugin fixes.
> - Move the datastore to a subdirectory so that it is easier to move it.
> - Updates to translations.
> Thanks to all contributors! (nextgens, toad, bombe, kryptos, Michael Tanzer, 
> batosai and SpanishGuy).
-------------- 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/20071023/aff1d52c/attachment.pgp 

From toad at amphibian.dyndns.org  Wed Oct 24 00:45:46 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 24 Oct 2007 01:45:46 +0100
Subject: [freenet-dev] Freenet GSoC 2007 detailed roundup
Message-ID: <200710240145.53651.toad@amphibian.dyndns.org>

Last year:
All the students were people we already knew.
Projects:
- Freemail. We'd been told this would be important long term by some potential 
important users, as well as for dogfood, and I agree personally, but nobody 
really used it since then. Partly because it didn't really work, at least not 
for me. A year later, it's working, we have a new (anonymous!) developer, and 
we will hopefully include it in 0.7.0. The student dev is around from time to 
time, occasional commits.
- Simulations. Vivee's simulations this year partly built on MRogers' sims 
last year. Some of the conclusions from last year we will use in future. 
Mrogers is around from time to time but no code.
- Thaw. Runaway success of GSoC 2006. Jflesch is still actively developing it 
and it has many many users and is bundled with Freenet. We asked for it in a 
fairly vague way, he'd done a small amount of work on it already.
- Installer/etc. Lots of important but boring stuff was written around that 
time, by one of our core devs (who remains a core dev), who got to stay out 
of the fast food industry and keep working on Freenet. He was a mentor this 
year.

This year:
Many people we don't know: Outsiders. Mainly judged on their applications with 
some feedback. Our selection process wasn't great. Some students' actual 
abilities were way below that suggested by their CVs. One project had to be 
entirely rewritten, mostly by the mentor although with some help from the 
student. Most others were disappointing. Well, last year's were disappointing 
too really, but this year's much more so. This is partly because of a policy 
of having self-contained projects: in theory it should reduce mentoring load, 
in practice it keeps students from having to become part of the community.

Six projects:
- More simulations. Reasonably successful, helped us to deal with a 
long-standing problem and paved the way for further development in several 
interesting areas. Insider (known by our maths guru). Student on IRC.
- Searching. This more or less works, but is rather less than we'd hoped for 
especially as we thought of it as a relatively easy project. Deployed. 
Student not visible atm.
- C++ library. No documentation, few examples, but the architecture seems 
elegant enough, the example given is both functional and short. Not really 
deployable right now. Not helped by the student moving to america around the 
completion date! This and previous were mentored by me, and I had a lot of 
time off for various reasons, see below. Student not visible atm.
- Blogging plugin. Not quite deployed yet due to dependancies issues, but 
functional, and much more code than some other projects. Insider (known by a 
dev). Not recently visible.
- Unit tests. Generally a success, although less volume than we'd hoped for. 
Our expectations may have been unrealistic, and we should have encouraged the 
student to get into the more interesting classes sooner. These things are 
probably much harder for somebody new to the code, but that may be a good 
thing: having somebody figure out exactly what the code is supposed to do, 
document a little, and express it in unit tests. Almost an insider; user, at 
least. Made an effort to get wider involvement, active on IRC, blogged: he's 
an insider *now*, so this is a result, although he hasn't been seen that much 
recently.
- New crypto setup. Had to be rewritten, with some help from the student. The 
rewritten version has now been deployed. On the other hand, the student has 
been visible consistently since the SoC, committing from time to time, so we 
may yet get a capable long term contributor out of it.

One big question is what would have happened if we had accepted Julia 
Medvedeva's Summer of Code proposal. She came up with an extremely ambitious 
solution to our searching problem, which needed a lot of reworking but could 
have turned into something very useful (or perhaps into nothing); it was 
related to her thesis project, so she would probably have produced something. 
Instead we took on a different student to just implement exactly what we 
needed in searching...

Next year obviously our selection process will be different. Several good 
ideas at the conference: Interview the students ASAP, get them to do some 
code / fix a bug, deal with applications differently in the light of what 
we've learned, select the best student with a useful project not the 
application most closely matching our immediate needs (it's going to be much 
quicker to implement it ourselves than to mentor the student if we get a poor 
student). And be more willing to fail them at mid-term!

Communications:
Way too much private communications on the GSoC, and very little public 
communication. This was a mistake. It reflected a wider culture - we only 
have a few devs, I review almost all commits (code review is of course a 
great way to find bugs, originally introduced for security reasons), but have 
almost always replied privately to commit mails. We need to get GSoC students 
involved in the project as a whole, which requires making them part of the 
community. In terms of wider culture, as much as possible should be done in 
the open, although not every last nitpick. It's an open question as to how 
much to use the internal messaging system vs the mailing lists (the former is 
quite high noise, though we can find quiet places; we have anonymous 
contributors using it already). Bit of a problem if your sole full time dev 
qualifies as a disruptive person now doesn't it? :) Regular meetings might be 
worth looking at.

I wasn't available as much as I should have been, and didn't give my students 
notice when I was going to disappear for a while. Likewise, my students 
tended to disappear for longish periods without advance notice. One of our 
best students actively sought me out on IRC when his mentor wasn't available, 
which is great. Hopefully next year I will be able to be more consistently 
available to my students.


Other stuff from the conference:

Plugins
- Our initial suspicions that well-defined APIs are vital were confirmed. We 
need to do something about this. Interesting hearing about others' 
experience - we only have a few self-contained plugins atm, and no real API; 
some projects e.g. Crystal Space are composed entirely of plugins.

Version control
- Met gitta, talked about GIT over Freenet. Maybe not GIT, maybe some other 
distributed VCS, but we need to be able to develop freenet over freenet in 
the long run (aka dogfood, though our long term reasons are a little 
different to Mozilla's). From talking to folk about DVCS's it shouldn't hurt 
the development process.

Web spam
- This was useful new information too - one of our core technologies may be 
relying on something like a CAPTCHA for several years, if they are unreliable 
long term then we may have to rethink.

Conclusion:

We would like to be in GSoC 2008. But we will do it differently! We've learned 
a lot, and probably gained some devs. Meanwhile last year's fruits continue 
to unfold. Oh and the conference rocked - much better than last year, 
probably largely because of more people and more warning.
-------------- 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/20071024/fb686bd9/attachment.pgp 

From toad at amphibian.dyndns.org  Wed Oct 24 15:23:10 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 24 Oct 2007 16:23:10 +0100
Subject: [freenet-dev] [freenet-cvs] r15523 -
	trunk/freenet/src/freenet/node
In-Reply-To: <20071024141517.F323C479864@freenetproject.org>
References: <20071024141517.F323C479864@freenetproject.org>
Message-ID: <200710241623.17693.toad@amphibian.dyndns.org>

Comments below...

What exactly is this key for? I believe it is for round trip verification ... 
does resetting it have any impact on forward secrecy?

On Wednesday 24 October 2007 15:15, you wrote:
> Author: nextgens
> Date: 2007-10-24 14:15:17 +0000 (Wed, 24 Oct 2007)
> New Revision: 15523
> 
> Modified:
>    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> Log:
> JFK: 
> 	Change the transient key on a regular basis (at least once every 30mins). 
We need it to be deterministic if we want to have a strict PFS interval.
> 
> Modified: trunk/freenet/src/freenet/node/FNPPacketMangler.java
> ===================================================================
> --- trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-24 09:53:20 
UTC (rev 15522)
> +++ trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-24 14:15:17 
UTC (rev 15523)
> -	// The following is used in the HMAC calculation of JFK message3 and 
message4
> +	/** The following is used in the HMAC calculation of JFK message3 and 
message4 */
>  	private static final byte[] JFK_PREFIX_INITIATOR, JFK_PREFIX_RESPONDER;
>  	static {
>  		byte[] I = null,R = null;
> @@ -103,6 +100,21 @@
>  	private static final int TRANSIENT_KEY_SIZE = HASH_LENGTH;
>  	/** The key used to authenticate the hmac */
>  	private final byte[] transientKey = new byte[TRANSIENT_KEY_SIZE];
> +	public static final int TRANSIENT_KEY_REKEYING_MIN_INTERVAL = 30*60*1000;
> +	/** The Runnable in charge of rekeying on a regular basis */
> +	private final Runnable transitentKeyRekeyer = new Runnable() {
> +		public void run() {
> +			resetTransientKey();
> +			
> +			try {
> +				// Ugly hack to let the node start up. When we are first
> +				// called in the constructor the ticker is not available!
> +				while(!node.isHasStarted())
> +					Thread.sleep(1000);
> +			} catch (InterruptedException e) {}
> +			node.getTicker().queueTimedJob(transitentKeyRekeyer, 
TRANSIENT_KEY_REKEYING_MIN_INTERVAL);
> +		}
> +	};

All you have to do is add a start() method to FNPPacketMangler, and have it 
called during the start() phase of the node (before PacketSender start). 
Include the initial scheduling of the above in that method.

>  	/** Minimum headers overhead */
>  	private static final int HEADERS_LENGTH_MINIMUM =
>  		4 + // sequence number
> @@ -139,7 +151,10 @@
>  		fullHeadersLengthMinimum = HEADERS_LENGTH_MINIMUM + 
sock.getHeadersLength();
>  		fullHeadersLengthOneMessage = HEADERS_LENGTH_ONE_MESSAGE + 
sock.getHeadersLength();
>  		logMINOR = Logger.shouldLog(Logger.MINOR, this);
> -		resetTransientKey();
> +		
> +		// Yeah there is a race condition... the key might be at 0 for a while...
> +		// but it will get reset soonish and current runs will be invalidated.
> +		node.executor.execute(transitentKeyRekeyer, "JFK transientRekeyer");
>  	}

Should be in start(), *not* in FNPPM.
-------------- 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/20071024/81f73dec/attachment.pgp 

From nextgens at freenetproject.org  Wed Oct 24 15:49:35 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Wed, 24 Oct 2007 17:49:35 +0200
Subject: [freenet-dev] [freenet-cvs] r15523 -
	trunk/freenet/src/freenet/node
In-Reply-To: <200710241623.17693.toad@amphibian.dyndns.org>
References: <20071024141517.F323C479864@freenetproject.org>
	<200710241623.17693.toad@amphibian.dyndns.org>
Message-ID: <20071024154935.GD4244@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-24 16:23:10]:

> Comments below...
> 
> What exactly is this key for? I believe it is for round trip verification ... 

It is.

> does resetting it have any impact on forward secrecy?

When we rekey we have to flush the cache because it gets invalidated.
Granted we could flush the cache without rekeying... Flushing the
cache has an impact on forward secrecy.

> 
> On Wednesday 24 October 2007 15:15, you wrote:
> > Author: nextgens
> > Date: 2007-10-24 14:15:17 +0000 (Wed, 24 Oct 2007)
> > New Revision: 15523
> > 
> > Modified:
> >    trunk/freenet/src/freenet/node/FNPPacketMangler.java
> > Log:
> > JFK: 
> > 	Change the transient key on a regular basis (at least once every 30mins). 
> We need it to be deterministic if we want to have a strict PFS interval.
> > 
> > Modified: trunk/freenet/src/freenet/node/FNPPacketMangler.java
> > ===================================================================
> > --- trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-24 09:53:20 
> UTC (rev 15522)
> > +++ trunk/freenet/src/freenet/node/FNPPacketMangler.java	2007-10-24 14:15:17 
> UTC (rev 15523)
> > -	// The following is used in the HMAC calculation of JFK message3 and 
> message4
> > +	/** The following is used in the HMAC calculation of JFK message3 and 
> message4 */
> >  	private static final byte[] JFK_PREFIX_INITIATOR, JFK_PREFIX_RESPONDER;
> >  	static {
> >  		byte[] I = null,R = null;
> > @@ -103,6 +100,21 @@
> >  	private static final int TRANSIENT_KEY_SIZE = HASH_LENGTH;
> >  	/** The key used to authenticate the hmac */
> >  	private final byte[] transientKey = new byte[TRANSIENT_KEY_SIZE];
> > +	public static final int TRANSIENT_KEY_REKEYING_MIN_INTERVAL = 30*60*1000;
> > +	/** The Runnable in charge of rekeying on a regular basis */
> > +	private final Runnable transitentKeyRekeyer = new Runnable() {
> > +		public void run() {
> > +			resetTransientKey();
> > +			
> > +			try {
> > +				// Ugly hack to let the node start up. When we are first
> > +				// called in the constructor the ticker is not available!
> > +				while(!node.isHasStarted())
> > +					Thread.sleep(1000);
> > +			} catch (InterruptedException e) {}
> > +			node.getTicker().queueTimedJob(transitentKeyRekeyer, 
> TRANSIENT_KEY_REKEYING_MIN_INTERVAL);
> > +		}
> > +	};
> 
> All you have to do is add a start() method to FNPPacketMangler, and have it 
> called during the start() phase of the node (before PacketSender start). 
> Include the initial scheduling of the above in that method.
> 
> >  	/** Minimum headers overhead */
> >  	private static final int HEADERS_LENGTH_MINIMUM =
> >  		4 + // sequence number
> > @@ -139,7 +151,10 @@
> >  		fullHeadersLengthMinimum = HEADERS_LENGTH_MINIMUM + 
> sock.getHeadersLength();
> >  		fullHeadersLengthOneMessage = HEADERS_LENGTH_ONE_MESSAGE + 
> sock.getHeadersLength();
> >  		logMINOR = Logger.shouldLog(Logger.MINOR, this);
> > -		resetTransientKey();
> > +		
> > +		// Yeah there is a race condition... the key might be at 0 for a while...
> > +		// but it will get reset soonish and current runs will be invalidated.
> > +		node.executor.execute(transitentKeyRekeyer, "JFK transientRekeyer");
> >  	}
> 
> Should be in start(), *not* in FNPPM.


-------------- 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/20071024/4d2f5c52/attachment.pgp 

From toad at amphibian.dyndns.org  Wed Oct 24 17:06:31 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 24 Oct 2007 18:06:31 +0100
Subject: [freenet-dev] Freenet 0.7 build 1069 with some security fixes
Message-ID: <200710241806.36887.toad@amphibian.dyndns.org>

Freenet 0.7 build 1069 is now available. Please upgrade. This includes a fix 
to a weak keys issue in our Diffie-Hellman code (including STS and JFK), 
which apparently also affected Freenet 0.5 (we are not going to fix it in 0.5 
as 0.5 is unmaintained, but if you want to send us a patch we will apply it), 
which allowed man-in-the-middle attacks to break our link encryption. Tor 
fixed a similar issue in 2005. Apologies for not fixing this earlier, I had 
thought it was a less serious vulnerability. 1069 also contains a few fixes 
to the new connection crypto setup code, fixes a rare NPE on startup, and 
another one caused when trying to insert a nonexistent directory via FCP.

Thanks for using Freenet, please report any bugs you find. This build will be 
mandatory on the 30th of October. Builds 1067 and 1068 contained fixes to the 
new crypto code in 1066, if you are curious. Sorry.

Also, Freemail has been pluginised, and apparently works, although it has many 
issues. If you want to try it, load it by typing Freemail* (or Freemail# if 
you don't want it downloaded on every startup) into the load a plugin box.
-------------- 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/20071024/9dd6c356/attachment.pgp 

From nextgens at freenetproject.org  Fri Oct 26 13:33:50 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Fri, 26 Oct 2007 15:33:50 +0200
Subject: [freenet-dev] Emu, new IP address, renewed SSL certificates,
	scheduled downtime
In-Reply-To: <20071023084402.GG4248@freenetproject.org>
References: <20071023084402.GG4248@freenetproject.org>
Message-ID: <20071026133350.GA4525@freenetproject.org>

* Florent Daigni?re <nextgens at freenetproject.org> [2007-10-23 10:44:02]:

> Hi,
> 
> 	As some of you might have noticed, emu's IP address has changed
> 	(from 80.68.80.201 to 89.16.176.201). Both IP addresses should
> 	be available for the time being as we need to wait for DNS 
> 	records to propagate before deprecating the old one.
> 
> 	The current set of SSL certificates in use on emu has expired,
> 	hence I have regenerated new ones... You can check their
> 	validity using openssl if you already have our CA 
> 	(https://emu.freenetproject.org/freenet.pem).
> 
> openssl s_client -CAfile freenet.pem -connect emu.freenetproject.org:443
> 
> 	If you don't, here are the new fingerprints:
> For emu.freenetproject.org
> SHA1 Fingerprint=43:C3:A6:57:A1:20:85:57:0E:E6:B9:74:AC:7E:04:7C:52:E3:D2:D9
> For bugs.freenetproject.org
> SHA1 Fingerprint=88:BF:1F:CA:08:D1:C1:DE:9A:46:D7:FA:7F:8E:48:53:A0:B6:36:64
> For the CA (still the same)
> SHA1 Fingerprint=FF:E0:D8:D6:57:E6:68:51:2B:3B:38:13:80:4F:AB:71:7B:2B:B5:EF
> 
> 	A side note: Emu will go down for a scheduled maintenance at
> 	19:50 GMT on the 25th. The downtime is planned to be of at least
> 	a few hours.
> 
> NextGen$

Hi,

	Emu is now back alive... everything but ipv6 should be working.

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/20071026/c9a8afb9/attachment.pgp 

From toad at amphibian.dyndns.org  Fri Oct 26 18:30:13 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 26 Oct 2007 19:30:13 +0100
Subject: [freenet-dev] Freenet 0.7 build 1070
Message-ID: <200710261930.18702.toad@amphibian.dyndns.org>

Freenet 0.7 build 1070 is now available. It will be mandatory on tuesday. Main 
changes:
- A new way to transfer opennet noderefs for path folding, with a significant 
security benefit against traffic analysis. Currently we support both the new 
and old formats, but the next build after this is mandatory will remove the 
support for the old insecure ref exchange format.
- Lots of internal code cleanups around opennet.
- Some changes to message coalescing, should slightly improve efficiency of 
using connections and security against traffic analysis.
- Remove the choose-which-networks-to-allow-access code from the first time 
wizard. Most people don't use this and it produces bad settings which will 
cause the node to fail to start up when your IP address changes.

Please upgrade! Please test the new build, and report any bugs you find. Thank 
you for using Freenet.
-------------- 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/20071026/ad9f2c85/attachment.pgp 

From toad at amphibian.dyndns.org  Fri Oct 26 23:48:42 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 00:48:42 +0100
Subject: [freenet-dev] Parallel negotiations
Message-ID: <200710270048.53827.toad@amphibian.dyndns.org>

Various odd errors recently (PacketSequenceException for example) seem to have 
been caused by running several JFK negotiations simultaneously and all of 
them succeeding. STS was stateful and therefore could only have one in 
flight, but JFK can have more than one. So one completes, then another 
completes; this exposed a bug which I fixed, but it is problematic as the 
second connection will clobber the first.

Options:
- 1) Introduce some state, resend the same message 2 after receiving the same 
message 1. Bad: memory DoS.
- 2) Ignore the problem. It works, don't fix it. Probably what we'll go with.
- 3) Stagger the sending of the phase 1 handshakes. The problem is that we may 
have to keep firewall tunnels open, so we have to send to each address every 
<30 secs. But there should be space within this to send to a few addresses...
- 4) Support multiple temporary connections. Drop according to a defined order 
in the noderef.
- 5) Support multiple permanent connections. Separate AIMD for each 
connection, so messages can be distributed according to whichever connection 
has the lowest RTT and has available bandwidth.

Any comments?
-------------- 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/20071027/26eb7cb8/attachment.pgp 

From srivatsan666 at gmail.com  Sat Oct 27 04:52:54 2007
From: srivatsan666 at gmail.com (Srivatsan Ravi)
Date: Sat, 27 Oct 2007 10:22:54 +0530
Subject: [freenet-dev] Parallel negotiations
In-Reply-To: <200710270048.53827.toad@amphibian.dyndns.org>
References: <200710270048.53827.toad@amphibian.dyndns.org>
Message-ID: <5ee09f060710262152q6ed405cak80097426ba6bb028@mail.gmail.com>

Nonce Ni allows the initiator to reuse the same exponential across the same
sessions(with the same or different responders) within the PFS interval
while ensuring that the resulting session key will be different. Thus we can
use it to differentiate between different parallel sessions( Can the
initiator handle the demultiplexing? )

On 10/27/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
>
> Various odd errors recently (PacketSequenceException for example) seem to
> have
> been caused by running several JFK negotiations simultaneously and all of
> them succeeding. STS was stateful and therefore could only have one in
> flight, but JFK can have more than one.




So one completes, then another
> completes; this exposed a bug which I fixed, but it is problematic as the
> second connection will clobber the first.
> What does this mean?
> Options:
> - 1) Introduce some state, resend the same message 2 after receiving the
> same
> message 1. Bad: memory DoS.
> - 2) Ignore the problem. It works, don't fix it. Probably what we'll go
> with.
> - 3) Stagger the sending of the phase 1 handshakes. The problem is that we
> may
> have to keep firewall tunnels open, so we have to send to each address
> every
> <30 secs. But there should be space within this to send to a few
> addresses...
> - 4) Support multiple temporary connections. Drop according to a defined
> order
> in the noderef.
> - 5) Support multiple permanent connections. Separate AIMD for each
> connection, so messages can be distributed according to whichever
> connection
> has the lowest RTT and has available bandwidth.
>
> Any comments?
>
> _______________________________________________
> 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/20071027/09dfaa7a/attachment.htm 

From bombe at pterodactylus.net  Sat Oct 27 14:37:39 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sat, 27 Oct 2007 16:37:39 +0200
Subject: [freenet-dev] PproxyToadlet / PluginManager
Message-ID: <1193495860.5971.8.camel@localhost>

Hi, there.

I've recently taking a look at PproxyToadlet because of issue 1823 and
while I'm fixing that I'd also remodel the plugin loading code and
interface. The current syntax of the single line labelled "Load plugin:"
is more than just a little bit confusing (and sparsely documented).

Here's what I think: We should split the "Load Plugin" section into two
parts: one for loading "official" plugins and one for loading other
plugins from arbitrary remote sources.

The first part would only require a name and a checkbox for auto-refresh
from the server on startup.

The second part would require a complete URL (and maybe the same
checkbox? If we allow users to load plugins from remote sources we can
also allow them to refresh that remote source on startup).

The name of the real plugin class is always taken from the JAR Manifest;
this is something that authors of remote plugins (are there any yet?)
and our build scripts for the "official plugins" need to take care of.

That would significantly improve the interface and encourage more users
to try out plugins. The first section could also include a current list
of "official" plugins so that users know about a couple of plugins they
could try.

Any further suggestions or comments?


	David
-------------- 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/20071027/b5519bab/attachment.pgp 

From bombe at pterodactylus.net  Sat Oct 27 14:45:05 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sat, 27 Oct 2007 16:45:05 +0200
Subject: [freenet-dev] New Toadlet: Online Documentation
Message-ID: <1193496305.5971.11.camel@localhost>

Hi, folks!

I'm feeling unusually creative this saturday: What about creating a
toadlet that includes documentation and FAQ sections in the web
interface?


	David
-------------- 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/20071027/3f2dec48/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 16:56:26 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 17:56:26 +0100
Subject: [freenet-dev] PproxyToadlet / PluginManager
In-Reply-To: <1193495860.5971.8.camel@localhost>
References: <1193495860.5971.8.camel@localhost>
Message-ID: <200710271756.33689.toad@amphibian.dyndns.org>

Sounds good to me. Long term plugins will be auto-updated from Freenet. Since 
they're not, we should warn users that the plugin will be downloaded from the 
non-anonymous web.

On Saturday 27 October 2007 15:37, David ?Bombe? Roden wrote:
> Hi, there.
> 
> I've recently taking a look at PproxyToadlet because of issue 1823 and
> while I'm fixing that I'd also remodel the plugin loading code and
> interface. The current syntax of the single line labelled "Load plugin:"
> is more than just a little bit confusing (and sparsely documented).
> 
> Here's what I think: We should split the "Load Plugin" section into two
> parts: one for loading "official" plugins and one for loading other
> plugins from arbitrary remote sources.
> 
> The first part would only require a name and a checkbox for auto-refresh
> from the server on startup.
> 
> The second part would require a complete URL (and maybe the same
> checkbox? If we allow users to load plugins from remote sources we can
> also allow them to refresh that remote source on startup).
> 
> The name of the real plugin class is always taken from the JAR Manifest;
> this is something that authors of remote plugins (are there any yet?)
> and our build scripts for the "official plugins" need to take care of.
> 
> That would significantly improve the interface and encourage more users
> to try out plugins. The first section could also include a current list
> of "official" plugins so that users know about a couple of plugins they
> could try.
> 
> Any further suggestions or comments?
> 
> 
> 	David
> 
-------------- 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/20071027/239b6bdd/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 16:58:59 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 17:58:59 +0100
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <1193496305.5971.11.camel@localhost>
References: <1193496305.5971.11.camel@localhost>
Message-ID: <200710271759.02593.toad@amphibian.dyndns.org>

On Saturday 27 October 2007 15:45, David ?Bombe? Roden wrote:
> Hi, folks!
> 
> I'm feeling unusually creative this saturday: What about creating a
> toadlet that includes documentation and FAQ sections in the web
> interface?

Either that, or put it on an Official Freenet Freesite. The problem with the 
latter is we'd have to implement Revocable Subspace Keys to do it.
> 
> 	David
-------------- 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/20071027/a30fc757/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 17:01:24 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 18:01:24 +0100
Subject: [freenet-dev] Parallel negotiations
In-Reply-To: <5ee09f060710262152q6ed405cak80097426ba6bb028@mail.gmail.com>
References: <200710270048.53827.toad@amphibian.dyndns.org>
	<5ee09f060710262152q6ed405cak80097426ba6bb028@mail.gmail.com>
Message-ID: <200710271801.25665.toad@amphibian.dyndns.org>

On Saturday 27 October 2007 05:52, Srivatsan Ravi wrote:
> Nonce Ni allows the initiator to reuse the same exponential across the same
> sessions(with the same or different responders) within the PFS interval
> while ensuring that the resulting session key will be different. Thus we can
> use it to differentiate between different parallel sessions( Can the
> initiator handle the demultiplexing? )

The problem is that we sometimes have several IP addresses for a node, and we 
will send handshakes to all of them simultaneously. If they all succeed, we 
will have to choose which to keep. We can't make the choice at receiving 
stage 2. In the short term, we will just keep the current code: the last 
success clobbers the first success. In the long term, we will probably 
support multiple simultaneous connections at least for a short time, and have 
some way to decide which one(s) to keep.
> 
> On 10/27/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> >
> > Various odd errors recently (PacketSequenceException for example) seem to
> > have
> > been caused by running several JFK negotiations simultaneously and all of
> > them succeeding. STS was stateful and therefore could only have one in
> > flight, but JFK can have more than one.
> 
> 
> 
> 
> So one completes, then another
> > completes; this exposed a bug which I fixed, but it is problematic as the
> > second connection will clobber the first.
> > What does this mean?
> > Options:
> > - 1) Introduce some state, resend the same message 2 after receiving the
> > same
> > message 1. Bad: memory DoS.
> > - 2) Ignore the problem. It works, don't fix it. Probably what we'll go
> > with.
> > - 3) Stagger the sending of the phase 1 handshakes. The problem is that we
> > may
> > have to keep firewall tunnels open, so we have to send to each address
> > every
> > <30 secs. But there should be space within this to send to a few
> > addresses...
> > - 4) Support multiple temporary connections. Drop according to a defined
> > order
> > in the noderef.
> > - 5) Support multiple permanent connections. Separate AIMD for each
> > connection, so messages can be distributed according to whichever
> > connection
> > has the lowest RTT and has available bandwidth.
> >
> > Any comments?
> >
> > _______________________________________________
> > 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: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071027/b17993e6/attachment.pgp 

From bombe at pterodactylus.net  Sat Oct 27 17:13:08 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sat, 27 Oct 2007 19:13:08 +0200
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <200710271759.02593.toad@amphibian.dyndns.org>
References: <1193496305.5971.11.camel@localhost>
	<200710271759.02593.toad@amphibian.dyndns.org>
Message-ID: <1193505189.5971.21.camel@localhost>

On Sat, 2007-10-27 at 17:58 +0100, Matthew Toseland wrote:

>  Either that, or put it on an Official Freenet Freesite. The problem
>  with the latter is we'd have to implement Revocable Subspace Keys to
>  do it.

That also wouldn't help users who just installed freenet and do not yet
have connections. Just clicking a link called "Documentation" or "FAQ"
in the web interface is something a lot more users will do than starting
to read the wiki or other resources.

Hmm... maybe online and offline documentation could be combined: a
documentation plugin that can read its content nodes from the disk (some
jar file) or from freenet. We could include stuff on how get connected
on-disk but the rest of the documentation would be downloaded from
freenet.

That means that plugins should be able to include themselves in the main
navigation menu, I think. Searching for a link called "Documentation" in
the "Plugins" section of the page is not quite intuitive.


	David
-------------- 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/20071027/a4623bc9/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 17:47:07 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 18:47:07 +0100
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <1193505189.5971.21.camel@localhost>
References: <1193496305.5971.11.camel@localhost>
	<200710271759.02593.toad@amphibian.dyndns.org>
	<1193505189.5971.21.camel@localhost>
Message-ID: <200710271847.16128.toad@amphibian.dyndns.org>

On Saturday 27 October 2007 18:13, David ?Bombe? Roden wrote:
> On Sat, 2007-10-27 at 17:58 +0100, Matthew Toseland wrote:
> 
> >  Either that, or put it on an Official Freenet Freesite. The problem
> >  with the latter is we'd have to implement Revocable Subspace Keys to
> >  do it.
> 
> That also wouldn't help users who just installed freenet and do not yet
> have connections. Just clicking a link called "Documentation" or "FAQ"
> in the web interface is something a lot more users will do than starting
> to read the wiki or other resources.
> 
> Hmm... maybe online and offline documentation could be combined: a
> documentation plugin that can read its content nodes from the disk (some
> jar file) or from freenet. We could include stuff on how get connected
> on-disk but the rest of the documentation would be downloaded from
> freenet.

Makes sense.
> 
> That means that plugins should be able to include themselves in the main
> navigation menu, I think. Searching for a link called "Documentation" in
> the "Plugins" section of the page is not quite intuitive.

Agreed.

They also need to be able to add stuff to the Welcome page: the XMLLibrarian 
plugin for example should create a search box there.
> 
> 
> 	David
-------------- 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/20071027/e22ebff9/attachment.pgp 

From bombe at pterodactylus.net  Sat Oct 27 18:03:34 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sat, 27 Oct 2007 20:03:34 +0200
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <200710271847.16128.toad@amphibian.dyndns.org>
References: <1193496305.5971.11.camel@localhost>
	<200710271759.02593.toad@amphibian.dyndns.org>
	<1193505189.5971.21.camel@localhost>
	<200710271847.16128.toad@amphibian.dyndns.org>
Message-ID: <1193508214.5971.25.camel@localhost>

On Sat, 2007-10-27 at 18:47 +0100, Matthew Toseland wrote:

> > Hmm... maybe online and offline documentation could be combined: a
> > documentation plugin that can read its content nodes from the disk (some
> > jar file) or from freenet. We could include stuff on how get connected
> > on-disk but the rest of the documentation would be downloaded from
> > freenet.
> Makes sense.

Didn't somebody want to create a wiki-plugin? At least for storing and
parsing the text data and displaying it that would be pretty perfect.


>  They also need to be able to add stuff to the Welcome page: the
>  XMLLibrarian plugin for example should create a search box there.

And the Freemail plugin could notify users of new emails.


	David
-------------- 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/20071027/1d13f14c/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 18:11:26 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 19:11:26 +0100
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <1193508214.5971.25.camel@localhost>
References: <1193496305.5971.11.camel@localhost>
	<200710271847.16128.toad@amphibian.dyndns.org>
	<1193508214.5971.25.camel@localhost>
Message-ID: <200710271911.34034.toad@amphibian.dyndns.org>

On Saturday 27 October 2007 19:03, David ?Bombe? Roden wrote:
> On Sat, 2007-10-27 at 18:47 +0100, Matthew Toseland wrote:
> 
> > > Hmm... maybe online and offline documentation could be combined: a
> > > documentation plugin that can read its content nodes from the disk (some
> > > jar file) or from freenet. We could include stuff on how get connected
> > > on-disk but the rest of the documentation would be downloaded from
> > > freenet.
> > Makes sense.
> 
> Didn't somebody want to create a wiki-plugin? At least for storing and
> parsing the text data and displaying it that would be pretty perfect.
> 
Yes, Freekiwiki. I haven't seen Volodya much in the last 6 months or so 
though. :|
> 
> >  They also need to be able to add stuff to the Welcome page: the
> >  XMLLibrarian plugin for example should create a search box there.
> 
> And the Freemail plugin could notify users of new emails.

By creating a UserAlert? :)

It should have a proper web interface in the long term. Is there a good 
java-based webmail we could steal from?
> 
> 	David
-------------- 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/20071027/526187bf/attachment.pgp 

From bombe at pterodactylus.net  Sat Oct 27 18:50:12 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sat, 27 Oct 2007 20:50:12 +0200
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <200710271911.34034.toad@amphibian.dyndns.org>
References: <1193496305.5971.11.camel@localhost>
	<200710271847.16128.toad@amphibian.dyndns.org>
	<1193508214.5971.25.camel@localhost>
	<200710271911.34034.toad@amphibian.dyndns.org>
Message-ID: <1193511012.5971.30.camel@localhost>

On Sat, 2007-10-27 at 19:11 +0100, Matthew Toseland wrote:

> Yes, Freekiwiki. I haven't seen Volodya much in the last 6 months or so 
> though. :|

The word on Frost is that he's been arrested last december in the US.


> By creating a UserAlert? :)

Well, why not?

(Somehow I feel driven into developing the Plugin API, AGAIN. :)


>  It should have a proper web interface in the long term. Is there a
>  good java-based webmail we could steal from?

None that I know of. Most of them are hacked together in PHP.


	David
-------------- 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/20071027/0170b431/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 19:40:13 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 20:40:13 +0100
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <1193511012.5971.30.camel@localhost>
References: <1193496305.5971.11.camel@localhost>
	<200710271911.34034.toad@amphibian.dyndns.org>
	<1193511012.5971.30.camel@localhost>
Message-ID: <200710272040.21116.toad@amphibian.dyndns.org>

On Saturday 27 October 2007 19:50, you wrote:
> > By creating a UserAlert? :)
> 
> Well, why not?
> 
> (Somehow I feel driven into developing the Plugin API, AGAIN. :)

If you'd like to work on the new plugins API, then talk to me about 
architecture, I've written a lot of the basic interfaces.
> 
> >  It should have a proper web interface in the long term. Is there a
> >  good java-based webmail we could steal from?
> 
> None that I know of. Most of them are hacked together in PHP.

:|
> 
> 	David
-------------- 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/20071027/b0630832/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 19:42:26 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 20:42:26 +0100
Subject: [freenet-dev] [freenet-cvs] r15614 - in
	trunk/freenet/src/freenet: clients/http l10n
In-Reply-To: <20071027181845.608E6390633@freenetproject.org>
References: <20071027181845.608E6390633@freenetproject.org>
Message-ID: <200710272042.27297.toad@amphibian.dyndns.org>

There is a global (Toadlet-level) unauthorized string iirc.

On Saturday 27 October 2007 19:18, you wrote:
> Author: bombe
> Date: 2007-10-27 18:18:45 +0000 (Sat, 27 Oct 2007)
> New Revision: 15614
> 
> Modified:
>    trunk/freenet/src/freenet/clients/http/PproxyToadlet.java
>    trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties
> Log:
> fix issue #1823
> 
> Modified: trunk/freenet/src/freenet/clients/http/PproxyToadlet.java
> ===================================================================
> --- trunk/freenet/src/freenet/clients/http/PproxyToadlet.java	2007-10-27 
17:54:26 UTC (rev 15613)
> +++ trunk/freenet/src/freenet/clients/http/PproxyToadlet.java	2007-10-27 
18:18:45 UTC (rev 15614)
> @@ -58,7 +58,7 @@
>  		}
>  
>  		if(!ctx.isAllowedFullAccess()) {
> -			super.sendErrorPage(ctx, 403, "Unauthorized", l10n("unauthorized"));
> +			super.sendErrorPage(ctx, 403, l10n("unauthorizedTitle"), 
l10n("unauthorized"));
>  			return;
>  		}
>  
> @@ -131,6 +131,7 @@
>  							Logger
>  							.error(this,
>  							"We don't allow downloads from anywhere else but our server");
> +							sendErrorPage(ctx, 403, l10n("Error"), 
l10n("downloadNotAllowedFromRemoteServer"));
>  							return;
>  						}
>  						String pluginname = filename.substring(0,
> @@ -153,8 +154,10 @@
>  								Logger
>  								.normal(this,
>  								"The plugin directory hasn't been found, let's create it");
> -								if (!pluginsDirectory.mkdir())
> +								if (!pluginsDirectory.mkdir()) {
> +									sendErrorPage(ctx, 500, l10n("Error"), 
l10n("pluginDirectoryNotCreated"));
>  									return;
> +								}
>  							}
>  
>  							File finalFile = new File("plugins/" + pluginname
> @@ -173,14 +176,17 @@
>  							Logger.error(this,
>  									"MalformedURLException has occured : " + mue,
>  									mue);
> +							sendErrorPage(ctx, l10n("Error"), l10n("pluginNotDownloaded"), mue);
>  							return;
>  						} catch (FileNotFoundException e) {
>  							Logger.error(this,
>  									"FileNotFoundException has occured : " + e, e);
> +							sendErrorPage(ctx, l10n("Error"), l10n("pluginNotDownloaded"), e);
>  							return;
>  						} catch (IOException ioe) {
>  							System.out.println("Caught :" + ioe.getMessage());
>  							ioe.printStackTrace();
> +							sendErrorPage(ctx, l10n("Error"), l10n("pluginNotDownloaded"), ioe);
>  							return;
>  						} finally {
>  							try {
> @@ -190,10 +196,13 @@
>  							}
>  						}
>  					}
> -					if (filename == null)
> +					if (filename == null) {
> +						sendErrorPage(ctx, 500, l10n("Error"), l10n("pluginNotDownloaded"));
>  						return;
> +					}
>  					else if(!downloaded) {
>  						Logger.error(this, "Can't load the given plugin; giving up");
> +						sendErrorPage(ctx, 500, l10n("Error"), l10n("pluginNotDownloaded"));
>  						return;
>  					}
>  				}
> 
> Modified: trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties
> ===================================================================
> --- trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties	2007-10-27 
17:54:26 UTC (rev 15613)
> +++ trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties	2007-10-27 
18:18:45 UTC (rev 15614)
> @@ -672,6 +672,8 @@
>  PluginToadlet.unsupportedMethodTitle=Unsupported Method
>  PluginToadlet.visit=Visit
>  PproxyToadlet.classNameTitle=Class Name
> +PproxyToadlet.downloadNotAllowedFromRemoteServer=Download of plugins is 
only allowed from our server.
> +PproxyToadlet.Error=Error
>  PproxyToadlet.internalIDTitle=Internal ID
>  PproxyToadlet.loadPluginLabel=Load Plugin:
>  PproxyToadlet.noPlugins=No plugins loaded
> @@ -684,7 +686,11 @@
>  PproxyToadlet.reload=Reload
>  PproxyToadlet.returnToPluginPage=Return to plugin page
>  PproxyToadlet.startedAtTitle=Started at
> +PproxyToadlet.pluginDirectoryNotCreated=The plugin directory could not be 
created.
> +PproxyToadlet.pluginNotDownloaded=The plugin could not be downloaded.
>  PproxyToadlet.pluginStopping=Plugin Stopping
> +PproxyToadlet.unauthorizedTitle=Unauthorized Access
> +PproxyToadlet.unauthorized=You are not authorized to view this page.
>  PproxyToadlet.unload=Unload
>  PproxyToadlet.unloadPluginTitle=Unload plugin?
>  PproxyToadlet.unloadPluginWithName=Are you sure you wish to unload ${name}?
> 
> _______________________________________________
> cvs mailing list
> cvs at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
> 
> 
-------------- 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/20071027/4ea40cd8/attachment.pgp 

From bombe at pterodactylus.net  Sat Oct 27 19:45:20 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sat, 27 Oct 2007 21:45:20 +0200
Subject: [freenet-dev] [freenet-cvs] r15614 -
	in	trunk/freenet/src/freenet: clients/http l10n
In-Reply-To: <200710272042.27297.toad@amphibian.dyndns.org>
References: <20071027181845.608E6390633@freenetproject.org>
	<200710272042.27297.toad@amphibian.dyndns.org>
Message-ID: <1193514320.5971.32.camel@localhost>

On Sat, 2007-10-27 at 20:42 +0100, Matthew Toseland wrote:

> There is a global (Toadlet-level) unauthorized string iirc.

Yes, but it's "you are not allowed..."-blabla and much too long for the
page title.


	David
-------------- 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/20071027/5932a7f5/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 19:49:18 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 20:49:18 +0100
Subject: [freenet-dev]
	=?utf-8?q?=5Bfreenet-cvs=5D_r15614_-_in=09trunk/fre?=
	=?utf-8?q?enet/src/freenet=3A_clients/http_l10n?=
In-Reply-To: <1193514320.5971.32.camel@localhost>
References: <20071027181845.608E6390633@freenetproject.org>
	<200710272042.27297.toad@amphibian.dyndns.org>
	<1193514320.5971.32.camel@localhost>
Message-ID: <200710272049.19669.toad@amphibian.dyndns.org>

On Saturday 27 October 2007 20:45, David ?Bombe? Roden wrote:
> On Sat, 2007-10-27 at 20:42 +0100, Matthew Toseland wrote:
> 
> > There is a global (Toadlet-level) unauthorized string iirc.
> 
> Yes, but it's "you are not allowed..."-blabla and much too long for the
> page title.

There should be a short version also iirc.
> 
> 
> 	David
> 
-------------- 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/20071027/0d8a6f79/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Oct 27 20:26:17 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 27 Oct 2007 21:26:17 +0100
Subject: [freenet-dev] [freenet-cvs] r15616 - in
	trunk/freenet/src/freenet: clients/http l10n
In-Reply-To: <20071027195805.D63A747B332@freenetproject.org>
References: <20071027195805.D63A747B332@freenetproject.org>
Message-ID: <200710272126.23361.toad@amphibian.dyndns.org>

More comments below. What Ian told me was we should localise stuff that a 
normal user will see i.e. only stuff that you don't have to turn on advanced 
mode for. That was specifically regarding me doing the work though, it *may* 
make sense to localise other stuff if we have the manpower.

On Saturday 27 October 2007 20:58, you wrote:
> Author: bombe
> Date: 2007-10-27 19:58:05 +0000 (Sat, 27 Oct 2007)
> New Revision: 15616
> 
> Modified:
>    trunk/freenet/src/freenet/clients/http/ConfigToadlet.java
>    trunk/freenet/src/freenet/clients/http/ConnectionsToadlet.java
>    trunk/freenet/src/freenet/clients/http/PproxyToadlet.java
>    trunk/freenet/src/freenet/clients/http/QueueToadlet.java
>    trunk/freenet/src/freenet/clients/http/StatisticsToadlet.java
>    trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties
> Log:
> fix issue #1824: add lots of l10n keys
> 
> Modified: trunk/freenet/src/freenet/clients/http/ConfigToadlet.java
> ===================================================================
> --- trunk/freenet/src/freenet/clients/http/ConfigToadlet.java	2007-10-27 
19:25:49 UTC (rev 15615)
> +++ trunk/freenet/src/freenet/clients/http/ConfigToadlet.java	2007-10-27 
19:58:05 UTC (rev 15616)
> @@ -52,7 +52,7 @@
>  		}
>  		
>  		if(!ctx.isAllowedFullAccess()) {
> -			super.sendErrorPage(ctx, 403, "Unauthorized", 
L10n.getString("Toadlet.unauthorized"));
> +			super.sendErrorPage(ctx, 403, 
L10n.getString("Toadlet.unauthorizedTitle"), 
L10n.getString("Toadlet.unauthorized"));
>  			return;
>  		}
>  		
> @@ -117,7 +117,7 @@
>  	public void handleGet(URI uri, HTTPRequest req, ToadletContext ctx) throws 
ToadletContextClosedException, IOException {
>  		
>  		if(!ctx.isAllowedFullAccess()) {
> -			super.sendErrorPage(ctx, 403, "Unauthorized", 
L10n.getString("Toadlet.unauthorized"));
> +			super.sendErrorPage(ctx, 403, L10n.getString("Unauthorized"), 
L10n.getString("Toadlet.unauthorized"));

IIRC they are case sensitive. Also shouldn't this be the same as the previous 
one? (Toadlet.unauthorizedTitle) ?
>  			return;
>  		}
>  		
> @@ -139,7 +139,7 @@
>  			HTMLNode nextTableCell = navigationTableRow;
>  			
>  			for(int i=0; i<sc.length;i++){
> -				
nextTableCell.addChild("td", "class", "config_navigation").addChild("li").addChild("a", "href", '#' 
+sc[i].getPrefix(), sc[i].getPrefix());
> +				
nextTableCell.addChild("td", "class", "config_navigation").addChild("li").addChild("a", "href", '#' 
+sc[i].getPrefix(), l10n(sc[i].getPrefix()));

Be consistent: if you're going to change the anchor IDs, also change the links 
to them.
>  			}
>  			contentNode.addChild(navigationBar);
>  		}
> @@ -183,7 +183,7 @@
>  			
>  			if(displayedConfigElements>0) {
>  				formNode.addChild("div", "class", "configprefix", sc[i].getPrefix());
> -				formNode.addChild("a", "id", sc[i].getPrefix());
> +				formNode.addChild("a", "id", l10n(sc[i].getPrefix()));
>  				formNode.addChild(configGroupUlNode);
>  			}
>  		}
> @@ -216,12 +216,12 @@
>  		
>  		if(value) {
>  			result.addChild("option", new String[] { "value", "selected" }, new 
String[] {
> -					"true", "selected" }, "true");
> -			result.addChild("option", "value", "false", "false");
> +					"true", "selected" }, l10n("true"));
> +			result.addChild("option", "value", "false", l10n("false"));
>  		} else {
> -			result.addChild("option", "value", "true", "true");
> +			result.addChild("option", "value", "true", l10n("true"));
>  			result.addChild("option", new String[] { "value", "selected" }, new 
String[] {
> -					"false", "selected" }, "false");
> +					"false", "selected" }, l10n("false"));

This should work, but be careful of any case where we actually check the value 
(there shouldn't be any...).
...
-------------- 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/20071027/63da5d35/attachment.pgp 

From bombe at pterodactylus.net  Sat Oct 27 21:13:48 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sat, 27 Oct 2007 23:13:48 +0200
Subject: [freenet-dev] [freenet-cvs] r15616 -
	in	trunk/freenet/src/freenet: clients/http l10n
In-Reply-To: <200710272126.23361.toad@amphibian.dyndns.org>
References: <20071027195805.D63A747B332@freenetproject.org>
	<200710272126.23361.toad@amphibian.dyndns.org>
Message-ID: <1193519628.5971.39.camel@localhost>

On Sat, 2007-10-27 at 21:26 +0100, Matthew Toseland wrote:

>  More comments below. What Ian told me was we should localise stuff
>  that a normal user will see i.e. only stuff that you don't have to
>  turn on advanced mode for. That was specifically regarding me doing
>  the work though, it *may* make sense to localise other stuff if we
>  have the manpower.

Hmm... in my opinion it's easier to include l10n every time you have to
display something and let the translators catch up. Having to insert
links and keys afterwards is more effort, IMHO.


>  IIRC they are case sensitive. Also shouldn't this be the same as the
>  previous one? (Toadlet.unauthorizedTitle) ?

Oops, you're right. Fixed.


>  Be consistent: if you're going to change the anchor IDs, also change
>  the links to them.

Oops, part 2. I never meant to change the anchor IDs. Fixed. Thanks. :)


>  This should work, but be careful of any case where we actually check
>  the value (there shouldn't be any...).

The transferred value is not translated, it will always be "true" and
"false," only the displayed stuff is changed.


	David
-------------- 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/20071027/9514411a/attachment.pgp 

From nextgens at freenetproject.org  Sat Oct 27 22:20:13 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Sun, 28 Oct 2007 00:20:13 +0200
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <200710271759.02593.toad@amphibian.dyndns.org>
References: <1193496305.5971.11.camel@localhost>
	<200710271759.02593.toad@amphibian.dyndns.org>
Message-ID: <20071027222013.GB3940@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-27 17:58:59]:

> On Saturday 27 October 2007 15:45, David ???Bombe??? Roden wrote:
> > Hi, folks!
> > 
> > I'm feeling unusually creative this saturday: What about creating a
> > toadlet that includes documentation and FAQ sections in the web
> > interface?
> 
> Either that, or put it on an Official Freenet Freesite. The problem with the 
> latter is we'd have to implement Revocable Subspace Keys to do it.

What about "enduring bookmarks" instead ? We could update them releasing
a new build if needed.

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/20071028/95590b88/attachment.pgp 

From nextgens at freenetproject.org  Sat Oct 27 22:34:16 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Sun, 28 Oct 2007 00:34:16 +0200
Subject: [freenet-dev] Parallel negotiations
In-Reply-To: <200710270048.53827.toad@amphibian.dyndns.org>
References: <200710270048.53827.toad@amphibian.dyndns.org>
Message-ID: <20071027223416.GD3940@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-10-27 00:48:42]:

> Various odd errors recently (PacketSequenceException for example) seem to have 
> been caused by running several JFK negotiations simultaneously and all of 
> them succeeding. STS was stateful and therefore could only have one in 
> flight, but JFK can have more than one. So one completes, then another 
> completes; this exposed a bug which I fixed, but it is problematic as the 
> second connection will clobber the first.
> 

Are those exceptions harmful ? what happens? we detect that the sequence
number is invalid and wait for the initiator to resend it with a "fixed"
sequence number ? Do we loose anything but time here ?

> Options:
> - 1) Introduce some state, resend the same message 2 after receiving the same 
> message 1. Bad: memory DoS.
> - 2) Ignore the problem. It works, don't fix it. Probably what we'll go with.
> - 3) Stagger the sending of the phase 1 handshakes. The problem is that we may 
> have to keep firewall tunnels open, so we have to send to each address every 
> <30 secs. But there should be space within this to send to a few addresses...
> - 4) Support multiple temporary connections. Drop according to a defined order 
> in the noderef.
> - 5) Support multiple permanent connections. Separate AIMD for each 
> connection, so messages can be distributed according to whichever connection 
> has the lowest RTT and has available bandwidth.
> 
> Any comments?

The current solution sucks. How long do we wait before sending the
handshake to next ip? iirc we don't wait at all... Meaning that we will
clobber the "fastest" link we have to a peer in favor of the crapiest
one!

Can't we ignore new calls to pn.completedHandshake if a link is already
existing ? That sounds to be the simplest solution to me.

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/20071028/dd0f2379/attachment.pgp 

From NEOatNHNG at users.sourceforge.net  Sat Oct 27 22:58:29 2007
From: NEOatNHNG at users.sourceforge.net (=?ISO-8859-15?Q?Michael_T=E4nzer?=)
Date: Sun, 28 Oct 2007 00:58:29 +0200
Subject: [freenet-dev] [freenet-cvs] r15616 -
 in	trunk/freenet/src/freenet: clients/http l10n
In-Reply-To: <200710272126.23361.toad@amphibian.dyndns.org>
References: <20071027195805.D63A747B332@freenetproject.org>
	<200710272126.23361.toad@amphibian.dyndns.org>
Message-ID: <4723C295.7050308@users.sourceforge.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Toseland wrote:
> More comments below. What Ian told me was we should localise stuff that a 
> normal user will see i.e. only stuff that you don't have to turn on advanced 
> mode for. That was specifically regarding me doing the work though, it *may* 
> make sense to localise other stuff if we have the manpower.
> 

Most of the advanced options include technical terms, which are often
(at least in German) not translatable or not well known by their German
translation, so it would result in a mix of two languages (more than it
already is) and this would be a problem to fit in the German grammar
(keeping the original meaning and in the same time producing a valid
German sentence would be hard, it already is sometimes). So I wouldn't
say I'm completely against it but it would be very difficult and could
lead to misconceptions which, especially in the advanced section, could
be critical.

What we should do is make the table entries in the status column in the
friends list (we could use the DarknetConnectionsToadlet.busyShort etc),
the string "Statistic gathering" in the statistics section and maybe the
dropdown values true and false translatable.

Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHI8KVPUBAMhFf+J4RAuiUAJ9rKDUKHfxrOtx4gr9FQgIRrDKB1ACgskUF
v9hehtQ6h7QZZkNb+pJW6K0=
=lPd6
-----END PGP SIGNATURE-----


From tommy100 at gmx.de  Sat Oct 27 23:40:40 2007
From: tommy100 at gmx.de (Thomas)
Date: Sun, 28 Oct 2007 01:40:40 +0200
Subject: [freenet-dev] Some updated german translations (r15621)
In-Reply-To: <4723C295.7050308@users.sourceforge.net>
References: <20071027195805.D63A747B332@freenetproject.org>	<200710272126.23361.toad@amphibian.dyndns.org>
	<4723C295.7050308@users.sourceforge.net>
Message-ID: <4723CC78.5090207@gmx.de>

see topic




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.de.override.properties
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20071028/2113eeee/attachment.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 370 bytes
Desc: OpenPGP digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20071028/2113eeee/attachment.pgp 

From bombe at pterodactylus.net  Sun Oct 28 05:54:58 2007
From: bombe at pterodactylus.net (David =?UTF-8?Q?=E2=80=98Bombe=E2=80=99?= Roden)
Date: Sun, 28 Oct 2007 06:54:58 +0100
Subject: [freenet-dev] New Toadlet: Online Documentation
In-Reply-To: <20071027222013.GB3940@freenetproject.org>
References: <1193496305.5971.11.camel@localhost>
	<200710271759.02593.toad@amphibian.dyndns.org>
	<20071027222013.GB3940@freenetproject.org>
Message-ID: <1193550898.5971.44.camel@localhost>

On Sun, 2007-10-28 at 00:20 +0200, Florent Daigni?re wrote:

>  What about "enduring bookmarks" instead ? We could update them
>  releasing a