From nextgens at freenetproject.org  Sun Apr  1 00:13:18 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sun, 1 Apr 2007 02:13:18 +0200
Subject: [freenet-dev] l10n, i18n
Message-ID: <20070401001315.GE5053@freenetproject.org>

Hi,
	Today I've commited what will be our "base framework" for
	internationalization... Review/comments are welcome.

	Help too :p

	In a first time we probably want to translate only what is visible
	on fproxy; even if we limit us to that, it's still a fair amount of
	work.

	All the framework stands in
	https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/l10n/
	Translations files will be UTF-8 encoded and kept in java
	properties files...

	The first task is to externalize strings... is there a special
	naming convention for keys ? I mean does ClassName.whatever fits
	the purpose or should we look for something a bit more evolved ?

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/20070401/d9e2e540/attachment.pgp 

From ian at locut.us  Sun Apr  1 02:02:37 2007
From: ian at locut.us (Ian Clarke)
Date: Sat, 31 Mar 2007 21:02:37 -0500
Subject: [freenet-dev] l10n, i18n
In-Reply-To: <20070401001315.GE5053@freenetproject.org>
References: <20070401001315.GE5053@freenetproject.org>
Message-ID: <823242bd0703311902q51118fa1t46f344f7cc38abfd@mail.gmail.com>

Really what is needed here are people fluent in two languages.  The
problem is that this approach imposes aadditional limitations, such as
that they must be familiar with subversion, and not intimidated by
things like java property files.

If you could find a way that non-devs could *easily* contribute
translation files, I suspect this would be a much faster process.

Ian.

On 3/31/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> Hi,
>         Today I've commited what will be our "base framework" for
>         internationalization... Review/comments are welcome.
>
>         Help too :p
>
>         In a first time we probably want to translate only what is visible
>         on fproxy; even if we limit us to that, it's still a fair amount of
>         work.
>
>         All the framework stands in
>         https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/l10n/
>         Translations files will be UTF-8 encoded and kept in java
>         properties files...
>
>         The first task is to externalize strings... is there a special
>         naming convention for keys ? I mean does ClassName.whatever fits
>         the purpose or should we look for something a bit more evolved ?
>
> NextGen$
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGDvkbU/Z/dHFfxtcRAh6gAKC2vjZV/qS1Yn5q9jKPitGIJ1iKOACgqsjO
> rSJl6LlawnTOezfB62wuOl0=
> =AUKB
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


-- 
Founder and CEO, Thoof Inc
Email: ian at thoof.com
Office: +1 512 524 8934 x 100
Cell: +1 512 422 3588
AIM: ian.clarke at mac.com
Skype: sanity


From nextgens at freenetproject.org  Sun Apr  1 12:03:26 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sun, 1 Apr 2007 14:03:26 +0200
Subject: [freenet-dev] l10n, i18n
In-Reply-To: <823242bd0703311902q51118fa1t46f344f7cc38abfd@mail.gmail.com>
References: <20070401001315.GE5053@freenetproject.org>
	<823242bd0703311902q51118fa1t46f344f7cc38abfd@mail.gmail.com>
Message-ID: <20070401120324.GA4408@freenetproject.org>

* Ian Clarke <ian at locut.us> [2007-03-31 21:02:37]:

> Really what is needed here are people fluent in two languages.  The
> problem is that this approach imposes aadditional limitations, such as
> that they must be familiar with subversion, and not intimidated by
> things like java property files.

Well, we need one way to get the files back ... either using subversion
or mailing lists.

> If you could find a way that non-devs could *easily* contribute
> translation files, I suspect this would be a much faster process.
> 

Ok, understood, I will write a plugin allowing people to edit/export java
property files 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/20070401/1d6cd3df/attachment.pgp 

From cacopatane at gmail.com  Sun Apr  1 17:50:55 2007
From: cacopatane at gmail.com (Caco Patane)
Date: Sun, 1 Apr 2007 14:50:55 -0300
Subject: [freenet-dev] l10n, i18n
In-Reply-To: <20070401120324.GA4408@freenetproject.org>
References: <20070401001315.GE5053@freenetproject.org>
	<823242bd0703311902q51118fa1t46f344f7cc38abfd@mail.gmail.com>
	<20070401120324.GA4408@freenetproject.org>
Message-ID: <b9160f500704011050q7e568047ia09cc7826068fce1@mail.gmail.com>

I can take the spanish stuff. No problem using svn.

On 4/1/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * Ian Clarke <ian at locut.us> [2007-03-31 21:02:37]:
>
> > Really what is needed here are people fluent in two languages.  The
> > problem is that this approach imposes aadditional limitations, such as
> > that they must be familiar with subversion, and not intimidated by
> > things like java property files.
>
> Well, we need one way to get the files back ... either using subversion
> or mailing lists.
>
> > If you could find a way that non-devs could *easily* contribute
> > translation files, I suspect this would be a much faster process.
> >
>
> Ok, understood, I will write a plugin allowing people to edit/export java
> property files then :)
>
> NextGen$
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGD5+MU/Z/dHFfxtcRAtBTAKDRDzQLttO4rRWPooxLk4bbxMlVHwCfbAxJ
> tmmTDvto3W/jG3nO29LsrW4=
> =IFlI
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


-- 
And the void rumbles in
Like an underground train
Forever comes closer
The world is in pain
We all must be shown, we must realise
That everyone changes and everything dies

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT dpu s:-- a-- C++ UL+++ P-- L++ E--- W+++ N o-- K- w---
O---- M V- PS+++ PE-- Y+ PGP t+ 5-- X+ R+++ tv-- b++ DI-- D++
G++ e h+ r-- y**
------END GEEK CODE BLOCK------

From alejandro at mosteo.com  Tue Apr  3 08:30:54 2007
From: alejandro at mosteo.com (Jano)
Date: Tue, 03 Apr 2007 10:30:54 +0200
Subject: [freenet-dev] 1026 - Internal error
Message-ID: <eut3bj$2mj$1@sea.gmane.org>

Internal Error: please report

java.lang.NullPointerException
        at
freenet.store.BerkeleyDBFreenetStore.checkSecondaryDatabaseError(BerkeleyDBFreenetStore.java:1901)
        at
freenet.store.BerkeleyDBFreenetStore.fetch(BerkeleyDBFreenetStore.java:1501)
        at freenet.node.Node.fetch(Node.java:1861)
        at freenet.node.Node.fetch(Node.java:2399)
        at freenet.node.Node.fetchKey(Node.java:2387)
        at
freenet.client.async.ClientRequestScheduler.register(ClientRequestScheduler.java:191)
        at freenet.node.SendableGet.schedule(SendableGet.java:106)
        at freenet.client.async.ClientGetter.start(ClientGetter.java:83)
        at freenet.client.async.ClientGetter.start(ClientGetter.java:60)
        at
freenet.client.HighLevelSimpleClientImpl.fetch(HighLevelSimpleClientImpl.java:128)
        at freenet.clients.http.Toadlet.fetch(Toadlet.java:107)
        at freenet.clients.http.FProxyToadlet.handleGet(FProxyToadlet.java:336)
        at freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:297)
        at
freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:416)
        at java.lang.Thread.run(Thread.java:619)

trying to retrieve ksk at gpl.txt from the web interface. Frost is also seeing
internal errors with code=17.



From nextgens at freenetproject.org  Tue Apr  3 10:29:53 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Tue, 3 Apr 2007 12:29:53 +0200
Subject: [freenet-dev] 1026 - Internal error
In-Reply-To: <eut3bj$2mj$1@sea.gmane.org>
References: <eut3bj$2mj$1@sea.gmane.org>
Message-ID: <20070403102952.GA3905@freenetproject.org>

* Jano <alejandro at mosteo.com> [2007-04-03 10:30:54]:

> Internal Error: please report
> 
> java.lang.NullPointerException
>         at
> freenet.store.BerkeleyDBFreenetStore.checkSecondaryDatabaseError(BerkeleyDBFreenetStore.java:1901)
>         at
> freenet.store.BerkeleyDBFreenetStore.fetch(BerkeleyDBFreenetStore.java:1501)
>         at freenet.node.Node.fetch(Node.java:1861)
>         at freenet.node.Node.fetch(Node.java:2399)
>         at freenet.node.Node.fetchKey(Node.java:2387)
>         at
> freenet.client.async.ClientRequestScheduler.register(ClientRequestScheduler.java:191)
>         at freenet.node.SendableGet.schedule(SendableGet.java:106)
>         at freenet.client.async.ClientGetter.start(ClientGetter.java:83)
>         at freenet.client.async.ClientGetter.start(ClientGetter.java:60)
>         at
> freenet.client.HighLevelSimpleClientImpl.fetch(HighLevelSimpleClientImpl.java:128)
>         at freenet.clients.http.Toadlet.fetch(Toadlet.java:107)
>         at freenet.clients.http.FProxyToadlet.handleGet(FProxyToadlet.java:336)
>         at freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:297)
>         at
> freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:416)
>         at java.lang.Thread.run(Thread.java:619)
> 
> trying to retrieve ksk at gpl.txt from the web interface. Frost is also seeing
> internal errors with code=17.

Hmm, if you are running the trunk version it means that the JVM/bdb code is
throwing a null object... Otherwise we will need the node's version number,
possibly the freenet-ext version number as well and the result of java
--version

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/20070403/f8e4bce0/attachment.pgp 

From sback at sback.it  Tue Apr  3 19:20:36 2007
From: sback at sback.it (Sback)
Date: Tue, 03 Apr 2007 21:20:36 +0200
Subject: [freenet-dev] crypto-DSA bugs
Message-ID: <4612A904.2020800@sback.it>

Hi,
 working on a class test for DSA.java, as needed for my Google Summer of
Code ranking, I have found two more bugs [another one is already fixed,
after nextgens gave me the repos access] in the current DSA implementation.
It is unlikely that they compare during the normal usage, but since
there are no raised exceptions, I believe they must be fixed.

The first bug is generated by this code [part of DSATest.java, not yet
committed]:

public void testSign_border() {
       
        BigInteger k = BigInteger.ONE;
        BigInteger q = Global.DSAgroupBigA.getQ().add(BigInteger.ONE);
        BigInteger p = q;
        BigInteger g = p.add(BigInteger.ONE);
       
        DSAGroup aDSAgroup = new DSAGroup(p,q,g);
       
        DSAPrivateKey aDSAPrivKey=new DSAPrivateKey(aDSAgroup,randomSource);
        DSAPublicKey aDSAPubKey=new DSAPublicKey(aDSAgroup,aDSAPrivKey);
    DSASignature aSignature=
               
DSA.sign(aDSAgroup,aDSAPrivKey,k,aDSAPrivKey.getX(),randomSource);
       
       
assertTrue(DSA.verify(aDSAPubKey,aSignature,aDSAPrivKey.getX(),false));
    }

As there are only few controls over parameters when creating a
DSAPrivateKey and a DSAPublicKey,
I've been able to generate a weird key pair that behaves not correctly
over the DSA.sign method.
I decided to use values that will create a R value [of the generated
signature] of 1.
R = (g^k mod p) mod q
[ k = 1, q = aPrimeNumber+1, p = q, g = p+1 ]
In this way the verify of the signature return FALSE, even if parameters
are correct.
It depends on the fact that DSA.verify, instead of raising an exception
over bad parameters,
catches it and return false. What is more, when using BigInteger.ZERO as
hased message,
it returns true correctly; but not with BigInteger.TEN... even more
uncertain

The second bug is generated througth this method [in the same test class]:

public void testSign_border2() {
       
        BigInteger q = BigInteger.ONE;
       
        DSAGroup aDSAgroup = new DSAGroup(
                Global.DSAgroupBigA.getP(),q,Global.DSAgroupBigA.getG());
       
        DSAPrivateKey aDSAPrivKey=new DSAPrivateKey(aDSAgroup,randomSource);

       //not bug correlated part------------------------------------------
        DSAPublicKey aDSAPubKey=new DSAPublicKey(aDSAgroup,aDSAPrivKey);
    DSASignature aSignature=
               
DSA.sign(aDSAgroup,aDSAPrivKey,aDSAPrivKey.getX(),randomSource);
       
       
assertTrue(DSA.verify(aDSAPubKey,aSignature,aDSAPrivKey.getX(),false));
        //not bug correlated part------------------------------------------
    }


In this way the problem is on the creation of the DSAPrivateKey, because
it remains
stuck in one creator method of DSAPrivateKey.java:

    public DSAPrivateKey(DSAGroup g, Random r) {
        BigInteger tempX;
        do {
            tempX = new NativeBigInteger(256, r);
        } while (tempX.compareTo(g.getQ()) > -1);
        this.x = tempX;
    }


if the Q value it is little enough [as 1 in my test, but I imagine it
could be a problem also for other small values]
it is almost impossible to generate a smaller X value. And it will
remain in the loop.


Both these two bugs are connected to the fact that there is no
parameters-checking when creating
DSA entities. In my opinion it should be enough to check them on the
standards that freenet follows
[that seems to be a mix between FIPS-186-2[0] and the
not-yet-standarized FIPS-182-3[1]].
Then, always IMHO, it could be even better to check on FIPS-186-2 and
raise only warnings
if they don't respect the not-yet-standardized FIPS-186-3 [because the
most part of method works
well with arguments valid for both the standards].

If you think it could be important to fix them and if you want I could
prepare the parameters-checking for
DSA entities and commit them.

Cheers,
 Sback

[0] http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
[1]
http://csrc.nist.gov/publications/drafts/fips_186-3/Draft-FIPS-186-3%20_March2006.pdf


From alejandro at mosteo.com  Wed Apr  4 16:44:16 2007
From: alejandro at mosteo.com (Jano)
Date: Wed, 04 Apr 2007 18:44:16 +0200
Subject: [freenet-dev] 1026 - Internal error
References: <eut3bj$2mj$1@sea.gmane.org>
	<20070403102952.GA3905@freenetproject.org>
Message-ID: <ev0kkv$vde$1@sea.gmane.org>

Florent Daigni?re (NextGen$) wrote:

> * Jano <alejandro at mosteo.com> [2007-04-03
> 10:30:54]:
> 
>> Internal Error: please report
>> 
>> java.lang.NullPointerException
>>         at
>>
freenet.store.BerkeleyDBFreenetStore.checkSecondaryDatabaseError(BerkeleyDBFreenetStore.java:1901)
>>         at
>> freenet.store.BerkeleyDBFreenetStore.fetch(BerkeleyDBFreenetStore.java:1501)
>>         at freenet.node.Node.fetch(Node.java:1861)
>>         at freenet.node.Node.fetch(Node.java:2399)
>>         at freenet.node.Node.fetchKey(Node.java:2387)
>>         at
>>
freenet.client.async.ClientRequestScheduler.register(ClientRequestScheduler.java:191)
>>         at freenet.node.SendableGet.schedule(SendableGet.java:106)
>>         at freenet.client.async.ClientGetter.start(ClientGetter.java:83)
>>         at freenet.client.async.ClientGetter.start(ClientGetter.java:60)
>>         at
>>
freenet.client.HighLevelSimpleClientImpl.fetch(HighLevelSimpleClientImpl.java:128)
>>         at freenet.clients.http.Toadlet.fetch(Toadlet.java:107)
>>         at
>>         freenet.clients.http.FProxyToadlet.handleGet(FProxyToadlet.java:336)
>>         at
>>        
freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:297)
>>         at
>>
freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:416)
>>         at java.lang.Thread.run(Thread.java:619)
>> 
>> trying to retrieve ksk at gpl.txt from the web interface.
>> Frost is also seeing internal errors with code=17.
> 
> Hmm, if you are running the trunk version it means that the JVM/bdb code is
> throwing a null object... Otherwise we will need the node's version number,
> possibly the freenet-ext version number as well and the result of java
> --version
> 
> NextGen$

Freenet 0.7 Build #1026 r12496
Freenet-ext Build #12 r12469

$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

(BTW -- it says b105 but is the same one from java.sun.com)




From toad at amphibian.dyndns.org  Sat Apr  7 21:04:25 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 7 Apr 2007 22:04:25 +0100
Subject: [freenet-dev] crypto-DSA bugs
In-Reply-To: <4612A904.2020800@sback.it>
References: <4612A904.2020800@sback.it>
Message-ID: <20070407210425.GB15073@amphibian.dyndns.org>

On Tue, Apr 03, 2007 at 09:20:36PM +0200, Sback wrote:
> Hi,
>  working on a class test for DSA.java, as needed for my Google Summer of
> Code ranking, I have found two more bugs [another one is already fixed,
> after nextgens gave me the repos access] in the current DSA implementation.
> It is unlikely that they compare during the normal usage, but since
> there are no raised exceptions, I believe they must be fixed.
> 
> The first bug is generated by this code [part of DSATest.java, not yet
> committed]:
> 
> public void testSign_border() {
>        
>         BigInteger k = BigInteger.ONE;
>         BigInteger q = Global.DSAgroupBigA.getQ().add(BigInteger.ONE);
>         BigInteger p = q;
>         BigInteger g = p.add(BigInteger.ONE);
>        
>         DSAGroup aDSAgroup = new DSAGroup(p,q,g);
>        
>         DSAPrivateKey aDSAPrivKey=new DSAPrivateKey(aDSAgroup,randomSource);
>         DSAPublicKey aDSAPubKey=new DSAPublicKey(aDSAgroup,aDSAPrivKey);
>     DSASignature aSignature=
>                
> DSA.sign(aDSAgroup,aDSAPrivKey,k,aDSAPrivKey.getX(),randomSource);
>        
>        
> assertTrue(DSA.verify(aDSAPubKey,aSignature,aDSAPrivKey.getX(),false));
>     }
> 
> As there are only few controls over parameters when creating a
> DSAPrivateKey and a DSAPublicKey,
> I've been able to generate a weird key pair that behaves not correctly
> over the DSA.sign method.
> I decided to use values that will create a R value [of the generated
> signature] of 1.
> R = (g^k mod p) mod q
> [ k = 1, q = aPrimeNumber+1, p = q, g = p+1 ]
> In this way the verify of the signature return FALSE, even if parameters
> are correct.
> It depends on the fact that DSA.verify, instead of raising an exception
> over bad parameters,
> catches it and return false. What is more, when using BigInteger.ZERO as
> hased message,
> it returns true correctly; but not with BigInteger.TEN... even more
> uncertain

Shouldn't this be caught in signing? It's not much use catching it on
verification: If it won't verify, it's not a valid signature.
> 
> The second bug is generated througth this method [in the same test class]:
> 
> public void testSign_border2() {
>        
>         BigInteger q = BigInteger.ONE;
>        
>         DSAGroup aDSAgroup = new DSAGroup(
>                 Global.DSAgroupBigA.getP(),q,Global.DSAgroupBigA.getG());
>        
>         DSAPrivateKey aDSAPrivKey=new DSAPrivateKey(aDSAgroup,randomSource);
> 
>        //not bug correlated part------------------------------------------
>         DSAPublicKey aDSAPubKey=new DSAPublicKey(aDSAgroup,aDSAPrivKey);
>     DSASignature aSignature=
>                
> DSA.sign(aDSAgroup,aDSAPrivKey,aDSAPrivKey.getX(),randomSource);
>        
>        
> assertTrue(DSA.verify(aDSAPubKey,aSignature,aDSAPrivKey.getX(),false));
>         //not bug correlated part------------------------------------------
>     }
> 
> 
> In this way the problem is on the creation of the DSAPrivateKey, because
> it remains
> stuck in one creator method of DSAPrivateKey.java:
> 
>     public DSAPrivateKey(DSAGroup g, Random r) {
>         BigInteger tempX;
>         do {
>             tempX = new NativeBigInteger(256, r);
>         } while (tempX.compareTo(g.getQ()) > -1);
>         this.x = tempX;
>     }
> 
> 
> if the Q value it is little enough [as 1 in my test, but I imagine it
> could be a problem also for other small values]
> it is almost impossible to generate a smaller X value. And it will
> remain in the loop.

Add an assertion. And maybe change the 256 to the number of bits
required (based on the group) in the new value.
> 
> 
> Both these two bugs are connected to the fact that there is no
> parameters-checking when creating
> DSA entities. In my opinion it should be enough to check them on the
> standards that freenet follows
> [that seems to be a mix between FIPS-186-2[0] and the
> not-yet-standarized FIPS-182-3[1]].
> Then, always IMHO, it could be even better to check on FIPS-186-2 and
> raise only warnings
> if they don't respect the not-yet-standardized FIPS-186-3 [because the
> most part of method works
> well with arguments valid for both the standards].

We don't exactly implement FIPS 2, because we use a 256-bit hash.
> 
> If you think it could be important to fix them and if you want I could
> prepare the parameters-checking for
> DSA entities and commit them.

By all means fix them.
> 
> Cheers,
>  Sback
> 
> [0] http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
> [1]
> http://csrc.nist.gov/publications/drafts/fips_186-3/Draft-FIPS-186-3%20_March2006.pdf
-------------- 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/20070407/9619e281/attachment.pgp 

From bbackde at googlemail.com  Thu Apr 12 07:37:29 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Thu, 12 Apr 2007 09:37:29 +0200
Subject: [freenet-dev] FYI: Next Frost release
Message-ID: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>

The next Frost release is the LAST release that accepts messages from
a Frost version
earlier than 20-Jun-2006! Starting with the release after the next one
all Frost messages
must contain a valid unique message id, or the message is revoked by
the receiving Frost.

I don't know if this affects the message code inside freenet, please handle.


From nextgens at freenetproject.org  Thu Apr 12 09:59:59 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 12 Apr 2007 11:59:59 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
Message-ID: <20070412095958.GA5445@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 09:37:29]:

> The next Frost release is the LAST release that accepts messages from
> a Frost version
> earlier than 20-Jun-2006! Starting with the release after the next one
> all Frost messages
> must contain a valid unique message id, or the message is revoked by
> the receiving Frost.
> 
> I don't know if this affects the message code inside freenet, please handle.

Yeah, it will break the "fproxyToFrost" inserter... But that shouldn't be
to hard to fix.

I have commited the testDDA infrastructure yesterday; it would be really
nice if frost was able to handle it before next release :)
It's not documented yet (might be done today) ; it's awaiting for code
review from toad.

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/20070412/713af345/attachment.pgp 

From bbackde at googlemail.com  Thu Apr 12 10:24:53 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Thu, 12 Apr 2007 12:24:53 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <20070412095958.GA5445@freenetproject.org>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
Message-ID: <d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>

As soon as I get a final doc for it I will include it. I planned the
release for today, but maybe I can postpone it until tomorrow :)

waiting for docs.

On 4/12/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 09:37:29]:
>
> > The next Frost release is the LAST release that accepts messages from
> > a Frost version
> > earlier than 20-Jun-2006! Starting with the release after the next one
> > all Frost messages
> > must contain a valid unique message id, or the message is revoked by
> > the receiving Frost.
> >
> > I don't know if this affects the message code inside freenet, please handle.
>
> Yeah, it will break the "fproxyToFrost" inserter... But that shouldn't be
> to hard to fix.
>
> I have commited the testDDA infrastructure yesterday; it would be really
> nice if frost was able to handle it before next release :)
> It's not documented yet (might be done today) ; it's awaiting for code
> review from toad.
>
> NextGen$
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGHgMeU/Z/dHFfxtcRAuwSAJ4sPsrQQvb3tm8S81fT48Qz48nNCgCdG826
> 20eZ0fN4szOlcRQF7gSSR/c=
> =ElBN
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From bbackde at googlemail.com  Thu Apr 12 12:06:28 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Thu, 12 Apr 2007 14:06:28 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
Message-ID: <d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>

I looked over your source, but where is the point when the node READS
the file written by the client? It looks like the readFile is created
by the node?

Did I misunderstand this?

I think its better when I wait with the testDDA implementation until
the node version that provides this new messages becomes
mandatory...then I will release a new Frost version.

On 4/12/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
> As soon as I get a final doc for it I will include it. I planned the
> release for today, but maybe I can postpone it until tomorrow :)
>
> waiting for docs.
>
> On 4/12/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 09:37:29]:
> >
> > > The next Frost release is the LAST release that accepts messages from
> > > a Frost version
> > > earlier than 20-Jun-2006! Starting with the release after the next one
> > > all Frost messages
> > > must contain a valid unique message id, or the message is revoked by
> > > the receiving Frost.
> > >
> > > I don't know if this affects the message code inside freenet, please handle.
> >
> > Yeah, it will break the "fproxyToFrost" inserter... But that shouldn't be
> > to hard to fix.
> >
> > I have commited the testDDA infrastructure yesterday; it would be really
> > nice if frost was able to handle it before next release :)
> > It's not documented yet (might be done today) ; it's awaiting for code
> > review from toad.
> >
> > NextGen$
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFGHgMeU/Z/dHFfxtcRAuwSAJ4sPsrQQvb3tm8S81fT48Qz48nNCgCdG826
> > 20eZ0fN4szOlcRQF7gSSR/c=
> > =ElBN
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
>


From nextgens at freenetproject.org  Thu Apr 12 12:26:38 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 12 Apr 2007 14:26:38 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
Message-ID: <20070412122638.GA5570@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 14:06:28]:

> I looked over your source, but where is the point when the node READS
> the file written by the client? It looks like the readFile is created
> by the node?
> 
> Did I misunderstand this?

Yes, "known issue" ... in the final version of the protocol the client
will choose the filename and the node will return if it can read from
it or not (assuming the file isn't empty).

I don't know if the node ought to prove it to the client (returning a
salted hash of the content for instance) or not.

Any views on the topic ?

> 
> I think its better when I wait with the testDDA implementation until
> the node version that provides this new messages becomes
> mandatory...then I will release a new Frost version.

The plan is to enforce it soon ... I mean to prevent DDA operations if
it's not enabled... I hope you don't mind releasing often :)

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/20070412/e96363c4/attachment.pgp 

From toad at amphibian.dyndns.org  Thu Apr 12 14:38:35 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 12 Apr 2007 15:38:35 +0100
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <20070412122638.GA5570@freenetproject.org>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
	<20070412122638.GA5570@freenetproject.org>
Message-ID: <20070412143834.GB29185@amphibian.dyndns.org>

On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 14:06:28]:
> 
> > I looked over your source, but where is the point when the node READS
> > the file written by the client? It looks like the readFile is created
> > by the node?
> > 
> > Did I misunderstand this?
> 
> Yes, "known issue" ... in the final version of the protocol the client
> will choose the filename and the node will return if it can read from
> it or not (assuming the file isn't empty).

Why would the filename be created by the client?

I thought the protocol was that the node writes a file which the client
must read, then it tells the client to write a specific block of data to
a specific file which the client must create.

I will review the code soon, today.
> 
> I don't know if the node ought to prove it to the client (returning a
> salted hash of the content for instance) or not.
> 
> Any views on the topic ?
-------------- 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/20070412/20203c68/attachment.pgp 

From nextgens at freenetproject.org  Thu Apr 12 14:47:46 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 12 Apr 2007 16:47:46 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <20070412143834.GB29185@amphibian.dyndns.org>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
	<20070412122638.GA5570@freenetproject.org>
	<20070412143834.GB29185@amphibian.dyndns.org>
Message-ID: <20070412144746.GB5570@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 15:38:35]:

> On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) wrote:
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 14:06:28]:
> > 
> > > I looked over your source, but where is the point when the node READS
> > > the file written by the client? It looks like the readFile is created
> > > by the node?
> > > 
> > > Did I misunderstand this?
> >

It's a variable naming missundersting: readFile is the file the node
writes and the client reads.

> > Yes, "known issue" ... in the final version of the protocol the client
> > will choose the filename and the node will return if it can read from
> > it or not (assuming the file isn't empty).
> 
> Why would the filename be created by the client?
> 
> I thought the protocol was that the node writes a file which the client
> must read, then it tells the client to write a specific block of data to
> a specific file which the client must create.

That's how it's implemented at the moment but it sucks... If you want
for instance to be able to use DDA (even read access only) on a directory
the node hasn't write access to it won't work as the node won't be able to
write the file the client is supposed to read.

I have created and documented two new messages : TestFileAccessQuery and
TestFileAccessReply; Those will probably be usefull to figure out if the
node and the FCP client are on the same computer.

I guess the solution will be to require the client to send us a hash of
the content he wants us to insert... but it requires both the client and
the node to compute the hash, and that obviously sucks :)

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/20070412/0e5ce215/attachment.pgp 

From bbackde at googlemail.com  Thu Apr 12 15:12:27 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Thu, 12 Apr 2007 17:12:27 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <20070412144746.GB5570@freenetproject.org>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
	<20070412122638.GA5570@freenetproject.org>
	<20070412143834.GB29185@amphibian.dyndns.org>
	<20070412144746.GB5570@freenetproject.org>
Message-ID: <d6149a790704120812p634dc2a2x41b0609f41770de8@mail.gmail.com>

On 4/12/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 15:38:35]:
>
> > On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) wrote:
> > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 14:06:28]:
> > >
> > > > I looked over your source, but where is the point when the node READS
> > > > the file written by the client? It looks like the readFile is created
> > > > by the node?
> > > >
> > > > Did I misunderstand this?
> > >
>
> It's a variable naming missundersting: readFile is the file the node
> writes and the client reads.
>
> > > Yes, "known issue" ... in the final version of the protocol the client
> > > will choose the filename and the node will return if it can read from
> > > it or not (assuming the file isn't empty).
> >
> > Why would the filename be created by the client?
> >
> > I thought the protocol was that the node writes a file which the client
> > must read, then it tells the client to write a specific block of data to
> > a specific file which the client must create.
>
> That's how it's implemented at the moment but it sucks... If you want
> for instance to be able to use DDA (even read access only) on a directory
> the node hasn't write access to it won't work as the node won't be able to
> write the file the client is supposed to read.
>
> I have created and documented two new messages : TestFileAccessQuery and
> TestFileAccessReply; Those will probably be usefull to figure out if the
> node and the FCP client are on the same computer.

Would be nice if you mark the messages with a "since xxx" because now
one could think the messages are there and can be used ... or can they
be used already?

>
> I guess the solution will be to require the client to send us a hash of
> the content he wants us to insert... but it requires both the client and
> the node to compute the hash, and that obviously sucks :)
>
> NextGen$
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGHkaSU/Z/dHFfxtcRAnnkAJ9qAgJos2/SJHRsH9qG6I2KXO1anACeNCnu
> kmTztzTRJorkgo+jzL6Rb1k=
> =MIUU
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From nextgens at freenetproject.org  Thu Apr 12 15:18:17 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 12 Apr 2007 17:18:17 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <d6149a790704120812p634dc2a2x41b0609f41770de8@mail.gmail.com>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
	<20070412122638.GA5570@freenetproject.org>
	<20070412143834.GB29185@amphibian.dyndns.org>
	<20070412144746.GB5570@freenetproject.org>
	<d6149a790704120812p634dc2a2x41b0609f41770de8@mail.gmail.com>
Message-ID: <20070412151817.GD5570@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 17:12:27]:

> >I have created and documented two new messages : TestFileAccessQuery and
> >TestFileAccessReply; Those will probably be usefull to figure out if the
> >node and the FCP client are on the same computer.
> 
> Would be nice if you mark the messages with a "since xxx" because now
> one could think the messages are there and can be used ... or can they
> be used already?

On trunk only :$ I'll mark it as "since 1027"

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/20070412/1b1fe001/attachment.pgp 

From nextgens at freenetproject.org  Thu Apr 12 14:47:46 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 12 Apr 2007 16:47:46 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <20070412143834.GB29185@amphibian.dyndns.org>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
	<20070412122638.GA5570@freenetproject.org>
	<20070412143834.GB29185@amphibian.dyndns.org>
Message-ID: <20070412144746.GB5570@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 15:38:35]:

> On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) wrote:
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 14:06:28]:
> > 
> > > I looked over your source, but where is the point when the node READS
> > > the file written by the client? It looks like the readFile is created
> > > by the node?
> > > 
> > > Did I misunderstand this?
> >

It's a variable naming missundersting: readFile is the file the node
writes and the client reads.

> > Yes, "known issue" ... in the final version of the protocol the client
> > will choose the filename and the node will return if it can read from
> > it or not (assuming the file isn't empty).
> 
> Why would the filename be created by the client?
> 
> I thought the protocol was that the node writes a file which the client
> must read, then it tells the client to write a specific block of data to
> a specific file which the client must create.

That's how it's implemented at the moment but it sucks... If you want
for instance to be able to use DDA (even read access only) on a directory
the node hasn't write access to it won't work as the node won't be able to
write the file the client is supposed to read.

I have created and documented two new messages : TestFileAccessQuery and
TestFileAccessReply; Those will probably be usefull to figure out if the
node and the FCP client are on the same computer.

I guess the solution will be to require the client to send us a hash of
the content he wants us to insert... but it requires both the client and
the node to compute the hash, and that obviously sucks :)

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/20070412/0e5ce215/attachment-0001.pgp 

From toad at amphibian.dyndns.org  Thu Apr 12 17:16:26 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 12 Apr 2007 18:16:26 +0100
Subject: [freenet-dev] TestDDA etc was Re:  FYI: Next Frost release
In-Reply-To: <20070412144746.GB5570@freenetproject.org>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
	<20070412122638.GA5570@freenetproject.org>
	<20070412143834.GB29185@amphibian.dyndns.org>
	<20070412144746.GB5570@freenetproject.org>
Message-ID: <20070412171626.GE29185@amphibian.dyndns.org>

Okay, in summary:

WRITE ACCESS
------------

Write access has to be per directory. The reason for this is that we
cannot write to an existing file created by the client: We have to write
to a temporary file in the same dir and then rename over the target, to
avoid symlink attacks.

Thus the directory-based TestDDA code works pretty well for this (sorry
I still haven't read it).

READ ACCESS
-----------

For directories where the node has write access, TestDDA can demonstrate
that the client has read access. For directories where the node does not
have write access, the easiest thing is simply to force the client to
use UploadFrom=direct. Later on we may provide an alternate mechanism,
such as a challenge to hash the file with a certain salt, or a request
for specific random offsets from the file. (The whole purpose of DDA is
to save disk space).

ERROR CODES
-----------

Because clients need backwards compatibility, they may want to just
submit the ClientGet or ClientPut, and if they get an error message,
respond to it by doing a TestDDA. If the node gets a request to upload a
file, (once this mechanism is mandatory), it should return an error
message requiring the client to either do a TestDDA or just upload the
file directly. If we have already done a TestDDA and this has failed
then there should be a different error code, and the client should
upload the file directly. The client should not be able to distinguish
between "the node can't see the directory at all" and "the node can't
create a file in the directory" when doing TestDDA.

TestFileAccessReply
-------------------

I am not convinced that this is useful. It is not a simple "are we on
the same machine" test because there are many cases where there are
partially shared filesystems on different machines. If the file does
exist, we cannot write to it (that is one of our security precautions,
maybe it should be revisited). If it doesn't, it is the directory which
we are querying, not the file, and the only way to be sure we can write
it is to do a full TestDDA. So it seems a confusing API to me, and
possibly one that can be exploited to leak information. It might be
useful to be able to check the status of previous TestDDA's, but I'm not
convinced that being able to verify that the node can read from / write
to a specific file is useful. What is the specific use case here? A
client which only wants to show files which both the node and the client
can read? There's no point, just show what the client can read, and
upload directly if necessary.

On Thu, Apr 12, 2007 at 04:47:46PM +0200, Florent Daigni?re (NextGen$) wrote:
> * Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 15:38:35]:
> 
> > On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) wrote:
> > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 14:06:28]:
> > > 
> > > > I looked over your source, but where is the point when the node READS
> > > > the file written by the client? It looks like the readFile is created
> > > > by the node?
> > > > 
> > > > Did I misunderstand this?
> > >
> 
> It's a variable naming missundersting: readFile is the file the node
> writes and the client reads.
> 
> > > Yes, "known issue" ... in the final version of the protocol the client
> > > will choose the filename and the node will return if it can read from
> > > it or not (assuming the file isn't empty).
> > 
> > Why would the filename be created by the client?
> > 
> > I thought the protocol was that the node writes a file which the client
> > must read, then it tells the client to write a specific block of data to
> > a specific file which the client must create.
> 
> That's how it's implemented at the moment but it sucks... If you want
> for instance to be able to use DDA (even read access only) on a directory
> the node hasn't write access to it won't work as the node won't be able to
> write the file the client is supposed to read.
> 
> I have created and documented two new messages : TestFileAccessQuery and
> TestFileAccessReply; Those will probably be usefull to figure out if the
> node and the FCP client are on the same computer.
> 
> I guess the solution will be to require the client to send us a hash of
> the content he wants us to insert... but it requires both the client and
> the node to compute the hash, and that obviously sucks :)
> 
> 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/20070412/f377e416/attachment.pgp 

From nextgens at freenetproject.org  Thu Apr 12 18:59:54 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Thu, 12 Apr 2007 20:59:54 +0200
Subject: [freenet-dev] TestDDA etc was Re:  FYI: Next Frost release
In-Reply-To: <20070412171626.GE29185@amphibian.dyndns.org>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<20070412095958.GA5445@freenetproject.org>
	<d6149a790704120324w1f2cad38gb6942ef3b3c2f333@mail.gmail.com>
	<d6149a790704120506v20e4e68apcc213f3cfe58b66e@mail.gmail.com>
	<20070412122638.GA5570@freenetproject.org>
	<20070412143834.GB29185@amphibian.dyndns.org>
	<20070412144746.GB5570@freenetproject.org>
	<20070412171626.GE29185@amphibian.dyndns.org>
Message-ID: <20070412185953.GA5497@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 18:16:26]:

> Okay, in summary:

Almost everything described below has been implemented in r12615 and
prior that... check it :)

Ok, I got rid of TestFileAccess messages.

> 
> WRITE ACCESS
> ------------
> 
> Write access has to be per directory. The reason for this is that we
> cannot write to an existing file created by the client: We have to write
> to a temporary file in the same dir and then rename over the target, to
> avoid symlink attacks.
> 
> Thus the directory-based TestDDA code works pretty well for this (sorry
> I still haven't read it).
> 
> READ ACCESS
> -----------
> 
> For directories where the node has write access, TestDDA can demonstrate
> that the client has read access. For directories where the node does not
> have write access, the easiest thing is simply to force the client to
> use UploadFrom=direct. Later on we may provide an alternate mechanism,
> such as a challenge to hash the file with a certain salt, or a request
> for specific random offsets from the file. (The whole purpose of DDA is
> to save disk space).
> 
> ERROR CODES
> -----------
> 
> Because clients need backwards compatibility, they may want to just
> submit the ClientGet or ClientPut, and if they get an error message,
> respond to it by doing a TestDDA. If the node gets a request to upload a
> file, (once this mechanism is mandatory), it should return an error
> message requiring the client to either do a TestDDA or just upload the
> file directly. If we have already done a TestDDA and this has failed
> then there should be a different error code, and the client should
> upload the file directly. The client should not be able to distinguish
> between "the node can't see the directory at all" and "the node can't
> create a file in the directory" when doing TestDDA.
> 
> TestFileAccessReply
> -------------------
> 
> I am not convinced that this is useful. It is not a simple "are we on
> the same machine" test because there are many cases where there are
> partially shared filesystems on different machines. If the file does
> exist, we cannot write to it (that is one of our security precautions,
> maybe it should be revisited). If it doesn't, it is the directory which
> we are querying, not the file, and the only way to be sure we can write
> it is to do a full TestDDA. So it seems a confusing API to me, and
> possibly one that can be exploited to leak information. It might be
> useful to be able to check the status of previous TestDDA's, but I'm not
> convinced that being able to verify that the node can read from / write
> to a specific file is useful. What is the specific use case here? A
> client which only wants to show files which both the node and the client
> can read? There's no point, just show what the client can read, and
> upload directly if necessary.
> 
> On Thu, Apr 12, 2007 at 04:47:46PM +0200, Florent Daigni?re (NextGen$) wrote:
> > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 15:38:35]:
> > 
> > > On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) wrote:
> > > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 14:06:28]:
> > > > 
> > > > > I looked over your source, but where is the point when the node READS
> > > > > the file written by the client? It looks like the readFile is created
> > > > > by the node?
> > > > > 
> > > > > Did I misunderstand this?
> > > >
> > 
> > It's a variable naming missundersting: readFile is the file the node
> > writes and the client reads.
> > 
> > > > Yes, "known issue" ... in the final version of the protocol the client
> > > > will choose the filename and the node will return if it can read from
> > > > it or not (assuming the file isn't empty).
> > > 
> > > Why would the filename be created by the client?
> > > 
> > > I thought the protocol was that the node writes a file which the client
> > > must read, then it tells the client to write a specific block of data to
> > > a specific file which the client must create.
> > 
> > That's how it's implemented at the moment but it sucks... If you want
> > for instance to be able to use DDA (even read access only) on a directory
> > the node hasn't write access to it won't work as the node won't be able to
> > write the file the client is supposed to read.
> > 
> > I have created and documented two new messages : TestFileAccessQuery and
> > TestFileAccessReply; Those will probably be usefull to figure out if the
> > node and the FCP client are on the same computer.
> > 
> > I guess the solution will be to require the client to send us a hash of
> > the content he wants us to insert... but it requires both the client and
> > the node to compute the hash, and that obviously sucks :)
> > 
> > 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/20070412/2723fe95/attachment.pgp 

From joelcsalomon at gmail.com  Thu Apr 12 19:40:04 2007
From: joelcsalomon at gmail.com (Joel C. Salomon)
Date: Thu, 12 Apr 2007 15:40:04 -0400
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
Message-ID: <7871fcf50704121240o2c244201j4944599aa7a4ce3f@mail.gmail.com>

On 4/12/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
> Starting with the release after the next one all Frost messages
> must contain a valid unique message id, or the message is revoked by
> the receiving Frost.

What purpose does the UMID serve?

--Joel


From bbackde at googlemail.com  Thu Apr 12 20:14:24 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Thu, 12 Apr 2007 22:14:24 +0200
Subject: [freenet-dev] FYI: Next Frost release
In-Reply-To: <7871fcf50704121240o2c244201j4944599aa7a4ce3f@mail.gmail.com>
References: <d6149a790704120037g536ae846oe0c377ef74ca0184@mail.gmail.com>
	<7871fcf50704121240o2c244201j4944599aa7a4ce3f@mail.gmail.com>
Message-ID: <d6149a790704121314y31720172w8c26508abd80b577@mail.gmail.com>

It uniquely identifies a specific message, the UMID serves a primary
key in the message database table (prevents duplicate messages) and is
used in the reply-to chain of message threads. Very important thing.

On 4/12/07, Joel C. Salomon <joelcsalomon at gmail.com> wrote:
> On 4/12/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote:
> > Starting with the release after the next one all Frost messages
> > must contain a valid unique message id, or the message is revoked by
> > the receiving Frost.
>
> What purpose does the UMID serve?
>
> --Joel
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From toad at amphibian.dyndns.org  Fri Apr 13 15:17:52 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 13 Apr 2007 16:17:52 +0100
Subject: [freenet-dev] [freenet-cvs] r12626 -
	trunk/freenet/src/freenet/l10n
In-Reply-To: <20070413140916.74A39478068@emu.freenetproject.org>
References: <20070413140916.74A39478068@emu.freenetproject.org>
Message-ID: <20070413151752.GL9206@amphibian.dyndns.org>

On Fri, Apr 13, 2007 at 02:09:16PM +0000, nextgens at freenetproject.org wrote:
> Author: nextgens
> Date: 2007-04-13 14:09:16 +0000 (Fri, 13 Apr 2007)
> New Revision: 12626
> 
> Modified:
>    trunk/freenet/src/freenet/l10n/L10n.java
> Log:
> Doh
> 
> Modified: trunk/freenet/src/freenet/l10n/L10n.java
> ===================================================================
> --- trunk/freenet/src/freenet/l10n/L10n.java	2007-04-13 14:06:20 UTC (rev 12625)
> +++ trunk/freenet/src/freenet/l10n/L10n.java	2007-04-13 14:09:16 UTC (rev 12626)
> @@ -96,9 +96,9 @@
>  	public static HTMLNode getHTMLNode(String key) {
>  		String value = getString(key, true);
>  		if(value != null)
> -			return new HTMLNode("#", value);
> +			return new HTMLNode("#", getDefaultString(value));

Eh? Surely ,value was right if value != null?

>  		else
> -			return new HTMLNode("#", value).addChild("span", "id", "translate_it").addChild("a", "href", "/?translate=" + key).addChild("small", " (translate it in your native language!)");
> +			return new HTMLNode("#", getDefaultString(value)).addChild("span", "id", "translate_it").addChild("a", "href", "/?translate=" + key).addChild("small", " (translate it in your native language!)");
>  	}
>  	
>  	public static String getDefaultString(String key) {
-------------- 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/20070413/ca7052e6/attachment.pgp 

From nextgens at freenetproject.org  Fri Apr 13 15:24:11 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Fri, 13 Apr 2007 17:24:11 +0200
Subject: [freenet-dev] [freenet-cvs] r12626 -
	trunk/freenet/src/freenet/l10n
In-Reply-To: <20070413151752.GL9206@amphibian.dyndns.org>
References: <20070413140916.74A39478068@emu.freenetproject.org>
	<20070413151752.GL9206@amphibian.dyndns.org>
Message-ID: <20070413152411.GF5555@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-13 16:17:52]:

> On Fri, Apr 13, 2007 at 02:09:16PM +0000, nextgens at freenetproject.org wrote:
> > Author: nextgens
> > Date: 2007-04-13 14:09:16 +0000 (Fri, 13 Apr 2007)
> > New Revision: 12626
> > 
> > Modified:
> >    trunk/freenet/src/freenet/l10n/L10n.java
> > Log:
> > Doh
> > 
> > Modified: trunk/freenet/src/freenet/l10n/L10n.java
> > ===================================================================
> > --- trunk/freenet/src/freenet/l10n/L10n.java	2007-04-13 14:06:20 UTC (rev 12625)
> > +++ trunk/freenet/src/freenet/l10n/L10n.java	2007-04-13 14:09:16 UTC (rev 12626)
> > @@ -96,9 +96,9 @@
> >  	public static HTMLNode getHTMLNode(String key) {
> >  		String value = getString(key, true);
> >  		if(value != null)
> > -			return new HTMLNode("#", value);
> > +			return new HTMLNode("#", getDefaultString(value));
> 
> Eh? Surely ,value was right if value != null?

Doh ... fixed in r12632
-------------- 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/20070413/576d863a/attachment.pgp 

From bbackde at googlemail.com  Sat Apr 14 08:32:25 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Sat, 14 Apr 2007 10:32:25 +0200
Subject: [freenet-dev] TestDDA questions
Message-ID: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>

I read the wiki doc about TestDDA and I have some comments/questions.

1)
Please define "READ" and "WRITE" exactly.
> Do you plan to do any read operation?

After some time I came to the conclusion that "READ" means I want to
GET/request a file from freenet, and the node have to write it into
the directory. IMHO READ/WRITE with the opposite meaning is to
abstract for a client developer *g*. But at least define READ^=GET and
WRITE^=PUT to make it clearer.


2)
>You can retry to enable DDA requests more than once for either the
same or a different directory. Only last test result will be taken
into account.

Please describe in more detail. Can I TestDDA several directories at
the beginning of my application run, because I use multiple
directories? Or is always only 1 directory allowed for DDA? And how
does the node remember what client tested which directory, is this
bound to the socket connection of the client and must be repeated for
each new connection?


3) TestDDAReply

> You *SHOULD* send a TestDDAResponse message after getting it.

*SHOULD* or *MUST* ? I think you must.

And I miss some words that the client have to create a new file and
write the WriteContent into it. How should a client behave if the file
creation fails ? Just skip the creation and let the node recognize
that the file is not there?


4) Windows vs. *nix
Maybe add some words that the TestDDA concept is bound to the
directory name completely. Mapped network drives with different names
(e.g. on linux and windows) could be DDA eligable, but due to the
directory name used in TestDDA you cannot use DDA there.


I will do some tests with the new code. Is it really true that 1028
will make this mandatory? In all other cases you gave us a specific
amount of time instead a fix next version number. What if you need to
release 2 version in the next few days?


From bbackde at googlemail.com  Sat Apr 14 09:27:50 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Sat, 14 Apr 2007 11:27:50 +0200
Subject: [freenet-dev] Fwd: TestDDA questions
In-Reply-To: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
Message-ID: <d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>

One more question: DDA makes most sense when I want to PUT (write)
files from a read-only medium like a CD. But with the current TestDDA
implementation I would not any longer be able to PUT files from a CD
using DDA (because the client cannot write the file to the requested
directory), true? I have to transfer all big files using DIRECT to the
node...

In this case the current TestDDA should never become mandatory.

---------- Forwarded message ----------
From: bbackde at googlemail.com <bbackde at googlemail.com>
Date: Apr 14, 2007 10:32 AM
Subject: TestDDA questions
To: Discussion of development issues <devl at freenetproject.org>


I read the wiki doc about TestDDA and I have some comments/questions.

1)
Please define "READ" and "WRITE" exactly.
> Do you plan to do any read operation?

After some time I came to the conclusion that "READ" means I want to
GET/request a file from freenet, and the node have to write it into
the directory. IMHO READ/WRITE with the opposite meaning is to
abstract for a client developer *g*. But at least define READ^=GET and
WRITE^=PUT to make it clearer.


2)
>You can retry to enable DDA requests more than once for either the
same or a different directory. Only last test result will be taken
into account.

Please describe in more detail. Can I TestDDA several directories at
the beginning of my application run, because I use multiple
directories? Or is always only 1 directory allowed for DDA? And how
does the node remember what client tested which directory, is this
bound to the socket connection of the client and must be repeated for
each new connection?


3) TestDDAReply

> You *SHOULD* send a TestDDAResponse message after getting it.

*SHOULD* or *MUST* ? I think you must.

And I miss some words that the client have to create a new file and
write the WriteContent into it. How should a client behave if the file
creation fails ? Just skip the creation and let the node recognize
that the file is not there?


4) Windows vs. *nix
Maybe add some words that the TestDDA concept is bound to the
directory name completely. Mapped network drives with different names
(e.g. on linux and windows) could be DDA eligable, but due to the
directory name used in TestDDA you cannot use DDA there.


I will do some tests with the new code. Is it really true that 1028
will make this mandatory? In all other cases you gave us a specific
amount of time instead a fix next version number. What if you need to
release 2 version in the next few days?


From nextgens at freenetproject.org  Sat Apr 14 10:30:53 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sat, 14 Apr 2007 12:30:53 +0200
Subject: [freenet-dev] TestDDA questions
In-Reply-To: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
Message-ID: <20070414103052.GA5400@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 10:32:25]:

> I read the wiki doc about TestDDA and I have some comments/questions.
> 
> 1)
> Please define "READ" and "WRITE" exactly.
> > Do you plan to do any read operation?
> 
> After some time I came to the conclusion that "READ" means I want to
> GET/request a file from freenet, and the node have to write it into
> the directory. IMHO READ/WRITE with the opposite meaning is to
> abstract for a client developer *g*. But at least define READ^=GET and
> WRITE^=PUT to make it clearer.
> 

You got it right : READ= get a file from freenet

> 
> 2)
> >You can retry to enable DDA requests more than once for either the
> same or a different directory. Only last test result will be taken
> into account.
> 
> Please describe in more detail. Can I TestDDA several directories at
> the beginning of my application run, because I use multiple
> directories? Or is always only 1 directory allowed for DDA? And how
> does the node remember what client tested which directory, is this
> bound to the socket connection of the client and must be repeated for
> each new connection?
> 

You can TestDDA as many directories as you want when your application
starts; the node handles it per socket, meaning that you have to repeat
it on each new connection... And you can't replay TestDDAResponses.

> 
> 3) TestDDAReply
> 
> > You *SHOULD* send a TestDDAResponse message after getting it.
> 
> *SHOULD* or *MUST* ? I think you must.

Well, if you don't the node won't clean up the files, so yes I guess
it's a must.

> 
> And I miss some words that the client have to create a new file and
> write the WriteContent into it. How should a client behave if the file
> creation fails ? Just skip the creation and let the node recognize
> that the file is not there?
> 

Yes, the test will fail; the client ought to fallback to direct access
mode.

> 
> 4) Windows vs. *nix
> Maybe add some words that the TestDDA concept is bound to the
> directory name completely. Mapped network drives with different names
> (e.g. on linux and windows) could be DDA eligable, but due to the
> directory name used in TestDDA you cannot use DDA there.


There is no crossplatform way of identifying them (thanks to windows not
respecting URI conventions) ... and java isn't able to handle that anyway.

On linux you don't map a network drive; you mount it. And mounted
filesystems will usable with testDDA provided the mount point path is
the same... I guess you can do the same on windows mapping the same
drive letter.

> 
> I will do some tests with the new code. Is it really true that 1028
> will make this mandatory? In all other cases you gave us a specific
> amount of time instead a fix next version number. What if you need to
> release 2 version in the next few days?

Well, the API is stable now (me and toad agree on it) so it's unlikely
to change... 1027 won't enforce testDDA but will feature it; 1028 is
planned to be a self-mandatory release so yes it will enforce it... and
no, sorry there is no ETA appart from "soon" yet.

I will update the wiki to take your remarks into account :)

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/20070414/6a8c4c7d/attachment.pgp 

From nextgens at freenetproject.org  Sat Apr 14 10:34:30 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sat, 14 Apr 2007 12:34:30 +0200
Subject: [freenet-dev] TestDDA questions
In-Reply-To: <20070414103052.GA5400@freenetproject.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<20070414103052.GA5400@freenetproject.org>
Message-ID: <20070414103430.GB5400@freenetproject.org>

* Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> [2007-04-14 12:30:53]:

> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 10:32:25]:
> 
> > I read the wiki doc about TestDDA and I have some comments/questions.
> > 
> > 1)
> > Please define "READ" and "WRITE" exactly.
> > > Do you plan to do any read operation?
> > 
> > After some time I came to the conclusion that "READ" means I want to
> > GET/request a file from freenet, and the node have to write it into
> > the directory. IMHO READ/WRITE with the opposite meaning is to
> > abstract for a client developer *g*. But at least define READ^=GET and
> > WRITE^=PUT to make it clearer.
> > 
> 
> You got it right : READ= get a file from freenet


Sorry, no it's the other way around :

WantWrite means that you will want the node to be able to *write* to the
specified directory (ie get files from freenet and put them there)
WantRead means that you want the node to read files from there and to
PUT them on freenet.

Apologizes for the confusion.
-------------- 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/20070414/00528bd5/attachment.pgp 

From bbackde at googlemail.com  Sat Apr 14 10:45:07 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Sat, 14 Apr 2007 12:45:07 +0200
Subject: [freenet-dev] TestDDA questions
In-Reply-To: <20070414103430.GB5400@freenetproject.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<20070414103052.GA5400@freenetproject.org>
	<20070414103430.GB5400@freenetproject.org>
Message-ID: <d6149a790704140345o643fbf8exb4d60bec2bbc45e@mail.gmail.com>

Ah, so for WantRead a client must handle WriteFilename and
ContentToWrite, true? Really consuding, is'nt it ;)

On 4/14/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> [2007-04-14 12:30:53]:
>
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 10:32:25]:
> >
> > > I read the wiki doc about TestDDA and I have some comments/questions.
> > >
> > > 1)
> > > Please define "READ" and "WRITE" exactly.
> > > > Do you plan to do any read operation?
> > >
> > > After some time I came to the conclusion that "READ" means I want to
> > > GET/request a file from freenet, and the node have to write it into
> > > the directory. IMHO READ/WRITE with the opposite meaning is to
> > > abstract for a client developer *g*. But at least define READ^=GET and
> > > WRITE^=PUT to make it clearer.
> > >
> >
> > You got it right : READ= get a file from freenet
>
>
> Sorry, no it's the other way around :
>
> WantWrite means that you will want the node to be able to *write* to the
> specified directory (ie get files from freenet and put them there)
> WantRead means that you want the node to read files from there and to
> PUT them on freenet.
>
> Apologizes for the confusion.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGIK42U/Z/dHFfxtcRApWzAKChHH5Jn0i8LTRcQquRFKugZd3lbwCgqzXp
> F5RetxQYvHd4II7RE1bkl5A=
> =sPXO
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From nextgens at freenetproject.org  Sat Apr 14 10:58:29 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sat, 14 Apr 2007 12:58:29 +0200
Subject: [freenet-dev] Fwd: TestDDA questions
In-Reply-To: <d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
Message-ID: <20070414105829.GC5400@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 11:27:50]:

> One more question: DDA makes most sense when I want to PUT (write)
> files from a read-only medium like a CD. But with the current TestDDA
> implementation I would not any longer be able to PUT files from a CD
> using DDA (because the client cannot write the file to the requested
> directory), true? I have to transfer all big files using DIRECT to the
> node...

Well, yes the node will refuse to read things if it can't write into
that directory; TestDDA architecture doesn't allow us to do otherwise.
The current behaviour sucks as well: imagine that the node and the
client aren't on the same computer ; the client asks /etc/passwd to be
inserted into freenet using DDA ... The node will accept it as it also
exists on his side but the content of the files is different.

In the long term we will ask the client to send us a salted hash of the
full content in ClientPuts so that we can ensure it has read access to
the file. Toad wants that the node chooses the salt and that it is not
predictable ... it involves using a challenge/response mechanism
=> more complexity won't be implemented "soon"

I am convinced we need the hash to be salted but I'm not convinced that
we have to randomize it on a per-request basis : We could send an
identifier in the NodeHello message and ensure it matches the salt.
@toad any problem with that approach ?

If there isn't any I might implement it soon.

> In this case the current TestDDA should never become mandatory.

The tradeoff is speed vs security in multi-user environments. When I say
"will become mandatory" you shall understand "will be the default
configuration of the node" ; In spite there is no plan to get rid of the
configuration setting yet, FCP client authors should assume that the
node won't let them proceed unless they do a TestDDA.

Well, I'll make it clear on the wiki. What I suggest is that you don't
send testDDA messages preemptively : ClientPut/Get requests with testdda
enabled are cheap to handle ... If the node is old it will work, if not
it will reply with a ProtocolError and then you have to do the TestDDA
proceedure... If it completes successfully you re-send the ClientPut/Get
with dda otherwise you use direct mode.

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/20070414/98273102/attachment.pgp 

From nextgens at freenetproject.org  Sat Apr 14 10:59:46 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sat, 14 Apr 2007 12:59:46 +0200
Subject: [freenet-dev] TestDDA questions
In-Reply-To: <d6149a790704140345o643fbf8exb4d60bec2bbc45e@mail.gmail.com>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<20070414103052.GA5400@freenetproject.org>
	<20070414103430.GB5400@freenetproject.org>
	<d6149a790704140345o643fbf8exb4d60bec2bbc45e@mail.gmail.com>
Message-ID: <20070414105946.GD5400@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 12:45:07]:

> Ah, so for WantRead a client must handle WriteFilename and
> ContentToWrite, true? Really consuding, is'nt it ;)

I have explained the why in my other message :)

> 
> On 4/14/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> 
> wrote:
> >* Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> [2007-04-14 
> >12:30:53]:
> >
> >> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 10:32:25]:
> >>
> >> > I read the wiki doc about TestDDA and I have some comments/questions.
> >> >
> >> > 1)
> >> > Please define "READ" and "WRITE" exactly.
> >> > > Do you plan to do any read operation?
> >> >
> >> > After some time I came to the conclusion that "READ" means I want to
> >> > GET/request a file from freenet, and the node have to write it into
> >> > the directory. IMHO READ/WRITE with the opposite meaning is to
> >> > abstract for a client developer *g*. But at least define READ^=GET and
> >> > WRITE^=PUT to make it clearer.
> >> >
> >>
> >> You got it right : READ= get a file from freenet
> >
> >
> >Sorry, no it's the other way around :
> >
> >WantWrite means that you will want the node to be able to *write* to the
> >specified directory (ie get files from freenet and put them there)
> >WantRead means that you want the node to read files from there and to
> >PUT them on freenet.
> >
> >Apologizes for the confusion.
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.6 (GNU/Linux)
> >
> >iD8DBQFGIK42U/Z/dHFfxtcRApWzAKChHH5Jn0i8LTRcQquRFKugZd3lbwCgqzXp
> >F5RetxQYvHd4II7RE1bkl5A=
> >=sPXO
> >-----END PGP SIGNATURE-----
> >
> >_______________________________________________
> >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/20070414/7b592f28/attachment.pgp 

From nextgens at freenetproject.org  Sat Apr 14 11:03:18 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sat, 14 Apr 2007 13:03:18 +0200
Subject: [freenet-dev] Fwd: TestDDA questions
In-Reply-To: <20070414105829.GC5400@freenetproject.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
	<20070414105829.GC5400@freenetproject.org>
Message-ID: <20070414110318.GE5400@freenetproject.org>

* Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> [2007-04-14 12:58:29]:

> In the long term we will ask the client to send us a salted hash of the
> full content in ClientPuts so that we can ensure it has read access to
> the file. Toad wants that the node chooses the salt and that it is not
> predictable ... it involves using a challenge/response mechanism
> => more complexity won't be implemented "soon"
> 
> I am convinced we need the hash to be salted but I'm not convinced that
> we have to randomize it on a per-request basis : We could send an
> identifier in the NodeHello message and ensure it matches the salt.
> @toad any problem with that approach ?
> 
> If there isn't any I might implement it soon.
> 

In fact we might even ask for H( NodeHello.id + Client(Put|Get).id,
content) so that it would be unique ... provided we keep track of
identifiers when requests are terminated.

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/20070414/35e2e8df/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Apr 14 12:20:19 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 14 Apr 2007 13:20:19 +0100
Subject: [freenet-dev] Fwd: TestDDA questions
In-Reply-To: <d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
Message-ID: <20070414122018.GA3877@amphibian.dyndns.org>

On Sat, Apr 14, 2007 at 11:27:50AM +0200, bbackde at googlemail.com wrote:
> One more question: DDA makes most sense when I want to PUT (write)
> files from a read-only medium like a CD. But with the current TestDDA
> implementation I would not any longer be able to PUT files from a CD
> using DDA (because the client cannot write the file to the requested
> directory), true? I have to transfer all big files using DIRECT to the
> node...

This is also a usability feature: The user should not have to tell the
client whether to use DDA, it should just use it if it is detected that
*for that specific directory* there is a shared filesystem.

However, we do need a way to do this with a reasonable level of local
security. In other words, the client must prove to the node that it has
access to the file in question. However the benefit is that we
unambiguously know that the client does have access; this will avoid
wierd bugs with wierd setups, as well as security issues.

For a CD-ROM I would argue that DDA doesn't make much sense because it
is a removable medium: by the time the node gets around to inserting it
the CD-ROM will probably be gone!
-------------- 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/20070414/5e48c110/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Apr 14 12:23:01 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 14 Apr 2007 13:23:01 +0100
Subject: [freenet-dev] Fwd: TestDDA questions
In-Reply-To: <20070414105829.GC5400@freenetproject.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
	<20070414105829.GC5400@freenetproject.org>
Message-ID: <20070414122301.GB3877@amphibian.dyndns.org>

On Sat, Apr 14, 2007 at 12:58:29PM +0200, Florent Daigni?re (NextGen$) wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 11:27:50]:
> 
> > One more question: DDA makes most sense when I want to PUT (write)
> > files from a read-only medium like a CD. But with the current TestDDA
> > implementation I would not any longer be able to PUT files from a CD
> > using DDA (because the client cannot write the file to the requested
> > directory), true? I have to transfer all big files using DIRECT to the
> > node...
> 
> Well, yes the node will refuse to read things if it can't write into
> that directory; TestDDA architecture doesn't allow us to do otherwise.
> The current behaviour sucks as well: imagine that the node and the
> client aren't on the same computer ; the client asks /etc/passwd to be
> inserted into freenet using DDA ... The node will accept it as it also
> exists on his side but the content of the files is different.
> 
> In the long term we will ask the client to send us a salted hash of the
> full content in ClientPuts so that we can ensure it has read access to
> the file. Toad wants that the node chooses the salt and that it is not
> predictable ... it involves using a challenge/response mechanism
> => more complexity won't be implemented "soon"

That's one option. Another option would be to send the file over the
connection as in UploadFrom=direct, but also include the filename. The
node would compare the file sent over the connection with the file on
disk and if they match, use the file on disk. If they don't it would
treat it as a direct upload. Would this be simpler for a client to
implement?

Bback/other client authors: Do you need chunking support? I had hoped to
avoid it as most of the time the node and the client are on the same
server, but if it is the price we pay for you to use a single
connection, then we will pay it.
> 
> I am convinced we need the hash to be salted but I'm not convinced that
> we have to randomize it on a per-request basis : We could send an
> identifier in the NodeHello message and ensure it matches the salt.
> @toad any problem with that approach ?
> 
> If there isn't any I might implement it soon.
> 
> > In this case the current TestDDA should never become mandatory.
> 
> The tradeoff is speed vs security in multi-user environments. When I say
> "will become mandatory" you shall understand "will be the default
> configuration of the node" ; In spite there is no plan to get rid of the
> configuration setting yet, FCP client authors should assume that the
> node won't let them proceed unless they do a TestDDA.
> 
> Well, I'll make it clear on the wiki. What I suggest is that you don't
> send testDDA messages preemptively : ClientPut/Get requests with testdda
> enabled are cheap to handle ... If the node is old it will work, if not
> it will reply with a ProtocolError and then you have to do the TestDDA
> proceedure... If it completes successfully you re-send the ClientPut/Get
> with dda otherwise you use direct mode.
> 
> 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/20070414/c5cd9e64/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Apr 14 12:24:17 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 14 Apr 2007 13:24:17 +0100
Subject: [freenet-dev] Fwd: TestDDA questions
In-Reply-To: <20070414110318.GE5400@freenetproject.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
	<20070414105829.GC5400@freenetproject.org>
	<20070414110318.GE5400@freenetproject.org>
Message-ID: <20070414122417.GC3877@amphibian.dyndns.org>

On Sat, Apr 14, 2007 at 01:03:18PM +0200, Florent Daigni?re (NextGen$) wrote:
> * Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> [2007-04-14 12:58:29]:
> 
> > In the long term we will ask the client to send us a salted hash of the
> > full content in ClientPuts so that we can ensure it has read access to
> > the file. Toad wants that the node chooses the salt and that it is not
> > predictable ... it involves using a challenge/response mechanism
> > => more complexity won't be implemented "soon"
> > 
> > I am convinced we need the hash to be salted but I'm not convinced that
> > we have to randomize it on a per-request basis : We could send an
> > identifier in the NodeHello message and ensure it matches the salt.
> > @toad any problem with that approach ?
> > 
> > If there isn't any I might implement it soon.
> > 
> 
> In fact we might even ask for H( NodeHello.id + Client(Put|Get).id,
> content) so that it would be unique ... provided we keep track of
> identifiers when requests are terminated.

What's this NodeHello.id ? You mean ClientHello.name ? That's chosen by
the client.
-------------- 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/20070414/b54dec0a/attachment.pgp 

From nextgens at freenetproject.org  Sat Apr 14 12:25:54 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sat, 14 Apr 2007 14:25:54 +0200
Subject: [freenet-dev] Fwd: TestDDA questions
In-Reply-To: <20070414122417.GC3877@amphibian.dyndns.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<d6149a790704140227s2838c655g7095022501adff01@mail.gmail.com>
	<20070414105829.GC5400@freenetproject.org>
	<20070414110318.GE5400@freenetproject.org>
	<20070414122417.GC3877@amphibian.dyndns.org>
Message-ID: <20070414122554.GG5400@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-14 13:24:17]:

> On Sat, Apr 14, 2007 at 01:03:18PM +0200, Florent Daigni?re (NextGen$) wrote:
> > * Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> [2007-04-14 12:58:29]:
> > 
> > > In the long term we will ask the client to send us a salted hash of the
> > > full content in ClientPuts so that we can ensure it has read access to
> > > the file. Toad wants that the node chooses the salt and that it is not
> > > predictable ... it involves using a challenge/response mechanism
> > > => more complexity won't be implemented "soon"
> > > 
> > > I am convinced we need the hash to be salted but I'm not convinced that
> > > we have to randomize it on a per-request basis : We could send an
> > > identifier in the NodeHello message and ensure it matches the salt.
> > > @toad any problem with that approach ?
> > > 
> > > If there isn't any I might implement it soon.
> > > 
> > 
> > In fact we might even ask for H( NodeHello.id + Client(Put|Get).id,
> > content) so that it would be unique ... provided we keep track of
> > identifiers when requests are terminated.
> 
> What's this NodeHello.id ? You mean ClientHello.name ? That's chosen by
> the client.

NodeHello is the reply the node gives after a ClientHello ... a new
field we would introduce.
-------------- 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/20070414/2b114925/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Apr 14 12:26:40 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 14 Apr 2007 13:26:40 +0100
Subject: [freenet-dev] TestDDA questions
In-Reply-To: <20070414103052.GA5400@freenetproject.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<20070414103052.GA5400@freenetproject.org>
Message-ID: <20070414122640.GD3877@amphibian.dyndns.org>

On Sat, Apr 14, 2007 at 12:30:53PM +0200, Florent Daigni?re (NextGen$) wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 10:32:25]:
> 
> > I read the wiki doc about TestDDA and I have some comments/questions.
> > 
> > 1)
> > Please define "READ" and "WRITE" exactly.
> > > Do you plan to do any read operation?
> > 
> > After some time I came to the conclusion that "READ" means I want to
> > GET/request a file from freenet, and the node have to write it into
> > the directory. IMHO READ/WRITE with the opposite meaning is to
> > abstract for a client developer *g*. But at least define READ^=GET and
> > WRITE^=PUT to make it clearer.
> > 
> 
> You got it right : READ= get a file from freenet

I thought READ meant *read from the disk* ? Isn't that the simplest
terminology?
> 
> > 2)
> > >You can retry to enable DDA requests more than once for either the
> > same or a different directory. Only last test result will be taken
> > into account.
> > 
> > Please describe in more detail. Can I TestDDA several directories at
> > the beginning of my application run, because I use multiple
> > directories? Or is always only 1 directory allowed for DDA? And how
> > does the node remember what client tested which directory, is this
> > bound to the socket connection of the client and must be repeated for
> > each new connection?
> 
> You can TestDDA as many directories as you want when your application
> starts; the node handles it per socket, meaning that you have to repeat
> it on each new connection... And you can't replay TestDDAResponses.
> 
> > 3) TestDDAReply
> > 
> > > You *SHOULD* send a TestDDAResponse message after getting it.
> > 
> > *SHOULD* or *MUST* ? I think you must.
> 
> Well, if you don't the node won't clean up the files, so yes I guess
> it's a must.
> 
> > And I miss some words that the client have to create a new file and
> > write the WriteContent into it. How should a client behave if the file
> > creation fails ? Just skip the creation and let the node recognize
> > that the file is not there?
> 
> Yes, the test will fail; the client ought to fallback to direct access
> mode.
> 
> > 4) Windows vs. *nix
> > Maybe add some words that the TestDDA concept is bound to the
> > directory name completely. Mapped network drives with different names
> > (e.g. on linux and windows) could be DDA eligable, but due to the
> > directory name used in TestDDA you cannot use DDA there.
> 
> There is no crossplatform way of identifying them (thanks to windows not
> respecting URI conventions) ... and java isn't able to handle that anyway.

Absolute pathnames. They include the directory and the drive.
> 
> On linux you don't map a network drive; you mount it. And mounted
> filesystems will usable with testDDA provided the mount point path is
> the same... I guess you can do the same on windows mapping the same
> drive letter.
> 
> > I will do some tests with the new code. Is it really true that 1028
> > will make this mandatory? In all other cases you gave us a specific
> > amount of time instead a fix next version number. What if you need to
> > release 2 version in the next few days?
> 
> Well, the API is stable now (me and toad agree on it) so it's unlikely
> to change... 1027 won't enforce testDDA but will feature it; 1028 is
> planned to be a self-mandatory release so yes it will enforce it... and
> no, sorry there is no ETA appart from "soon" yet.

Why do you want 1028 to be self-mandatory?
> 
> I will update the wiki to take your remarks into account :)
> 
> 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/20070414/2acc4c3d/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Apr 14 12:27:41 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 14 Apr 2007 13:27:41 +0100
Subject: [freenet-dev] TestDDA questions
In-Reply-To: <20070414105946.GD5400@freenetproject.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<20070414103052.GA5400@freenetproject.org>
	<20070414103430.GB5400@freenetproject.org>
	<d6149a790704140345o643fbf8exb4d60bec2bbc45e@mail.gmail.com>
	<20070414105946.GD5400@freenetproject.org>
Message-ID: <20070414122741.GE3877@amphibian.dyndns.org>

On Sat, Apr 14, 2007 at 12:59:46PM +0200, Florent Daigni?re (NextGen$) wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 12:45:07]:
> 
> > Ah, so for WantRead a client must handle WriteFilename and
> > ContentToWrite, true? Really consuding, is'nt it ;)
> 
> I have explained the why in my other message :)

Well, it needs to be properly documented...
-------------- 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/20070414/24a6c8c5/attachment.pgp 

From nextgens at freenetproject.org  Sat Apr 14 12:29:06 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sat, 14 Apr 2007 14:29:06 +0200
Subject: [freenet-dev] TestDDA questions
In-Reply-To: <20070414122640.GD3877@amphibian.dyndns.org>
References: <d6149a790704140132y395b853aj9a725f75fecd4608@mail.gmail.com>
	<20070414103052.GA5400@freenetproject.org>
	<20070414122640.GD3877@amphibian.dyndns.org>
Message-ID: <20070414122905.GH5400@freenetproject.org>

* Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-14 13:26:40]:

> Why do you want 1028 to be self-mandatory?

So that we see how the network behaves and how messed up its topology is
soon.

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/20070414/7634475b/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Apr 14 13:30:20 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 14 Apr 2007 14:30:20 +0100
Subject: [freenet-dev] Stuff related to TestDDA
Message-ID: <20070414133020.GA9836@amphibian.dyndns.org>

Please have a look at these bugs, and give us some feedback
https://bugs.freenetproject.org/view.php?id=1298
- Enforce that uploaded files do not change while being uploaded.
https://bugs.freenetproject.org/view.php?id=1299
- Chunked uploading/downloading.
https://bugs.freenetproject.org/view.php?id=1300
- UploadFrom=direct+disk (send it over the socket but specify a
  filename, if the node can read it it saves the same amount of disk
  space as DDA, but it always works, and is faster than nextgens'
  FileHash mechanism for big read-only files on localhost).
-------------- 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/20070414/f955c873/attachment.pgp 

From nextgens at freenetproject.org  Sun Apr 15 17:17:20 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Sun, 15 Apr 2007 19:17:20 +0200
Subject: [freenet-dev] Fproxy and CSSes
Message-ID: <20070415171719.GA22927@freenetproject.org>

Hi,
	Today I have implemented the ticket #1279 [1]: It's now possible 
	to set and use an external CSS with fproxy. I hope it will
	encourage people to contribute and that it will lead to the
	improvement of bundled ones [2].

	Contributions are welcome!

NextGen$
[1] https://bugs.freenetproject.org/view.php?id=1279
[2] http://archives.freenetproject.org/message/20060620.192151.2f1c98c9.en.html
-------------- 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/20070415/4f0bbf34/attachment.pgp 

From toad at amphibian.dyndns.org  Wed Apr 18 14:29:50 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 18 Apr 2007 15:29:50 +0100
Subject: [freenet-dev] Freenet 0.7 build 1027
Message-ID: <20070418142950.GE12247@amphibian.dyndns.org>

Freenet 0.7 build 1027 is now available. Please upgrade! If the
auto-update system does not pick it up in a few days please tell us.
Highlights:
- Improved load limiting. The node should send many more requests than
  it was doing (this should have happened at xmas but there was a bug).
- Improved pre-emptive rejection. The node should reject requests only
  when it needs to, and not accept more requests than it can handle
  without a timeout, even if they all succeed (this does happen...).
- Lots of work on localisation. Not yet ready for translations, but will
  be soon.
- New FCP API for testing whether direct disk access is allowed (TestDDA
  etc) and related things (e.g. FileHash on ClientPut). This is not
  mandatory but will be in a future release. Also the API for config
  over FCP is almost ready.
- Support for themes external to the node.
- Better stats, and better stats page.
- Changes to the plugins API. You may need to update your plugins
  manually.
-------------- 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/20070418/a2530555/attachment.pgp 

From toad at amphibian.dyndns.org  Fri Apr 20 15:59:38 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 20 Apr 2007 16:59:38 +0100
Subject: [freenet-dev] Freenet 0.7 build 1029
Message-ID: <20070420155938.GA19963@amphibian.dyndns.org>

Freenet 0.7 build 1029 is now available. Please upgrade. This build is
mandatory on May 4th, and makes 1021 (the build in which STS was added)
mandatory immediately. This build includes some new diagnostic code to
make it easier to map the long range network topology, so we can
determine whether the cause of all our problems is in fact #freenet-refs
causing a strung-out network where newbies are almost exclusively
connected to newbies etc, or if it is working and we have a more or less
small world network. Note that this will make it easier for an attacker
to determine the network topology also. It is already possible for him
to do this because of swapping, at least for the short range. The code
will be removed when it is no longer necessary, but we need this
information, and mostly attackers are interested in the short-range
topology. Also there is a minor fix to timeouts when starting up the
datastore. Please upgrade, and tell us if the auto-update system isn't
working.
-------------- 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/20070420/e812d0fc/attachment.pgp 

From fake_email.qwerty at yahoo.com  Sat Apr 21 19:04:36 2007
From: fake_email.qwerty at yahoo.com (Fake Email)
Date: Sat, 21 Apr 2007 12:04:36 -0700 (PDT)
Subject: [freenet-dev] Story Submitted to Slashdot
Message-ID: <379674.58815.qm@web63704.mail.re1.yahoo.com>

When Developers Attack

What do you do when you fork your project and the users shun the new application and keep using the old one?  The Freenet Project has had an ongoing problem where many of the users have kept using the older 0.5 network because it was stable and had Open Net while the new 0.7 network was slow, buggy, and difficult to connect to.  

The Freenet developers Zothar  and Nextgens decided that they should attack and destroy the old network instead of making the new network more stable and easier to use.  The following is an IRC chat between two of the Freenet developers.

[20:12:25] <nextgens> Zothar_Work> I need to talk about bringing 0.5 down with toad
[20:12:38] <nextgens> Zothar_Work> I've got some ideas on how to do it
[20:12:52] <nextgens> that would definitly shut up 0.5 trolls, wouldn't it ?
[20:14:08] <Zothar_Work> nextgens: yeah, that would probably do it
[20:14:13] <FuriousRage> censoring at hand?
[20:14:24] <nextgens> it's not about censoring
[20:14:30] <Zothar_Work> I find it interesting that Frost on 0.5 doesn't seem to be having the board spoofing problem 0.7 does
[20:14:36] <nextgens> it's about prooving that 0.5 has to be replaced :)
[20:14:43] <Zothar_Work> FuriousRage: vulnerability demonstration
[20:15:19] <Zothar_Work> that would be indirect "settling"

When asked to condem this action, the primary developer Matthew Toseland (Toad) remained silent.
       
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://emu.freenetproject.org/pipermail/devl/attachments/20070421/f61cb015/attachment.htm 

From Volodya at WhenGendarmeSleeps.org  Mon Apr 23 20:04:56 2007
From: Volodya at WhenGendarmeSleeps.org (Volodya)
Date: Mon, 23 Apr 2007 21:04:56 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <379674.58815.qm@web63704.mail.re1.yahoo.com>
References: <379674.58815.qm@web63704.mail.re1.yahoo.com>
Message-ID: <462D1168.8020701@WhenGendarmeSleeps.org>

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

Fake Email wrote:
> When Developers Attack
> 
> What do you do when you fork your project and the users shun the new
> application and keep using the old one?  The Freenet Project has had an
> ongoing problem where many of the users have kept using the older 0.5
> network because it was stable and had Open Net while the new 0.7 network
> was slow, buggy, and difficult to connect to.  
> 
> The Freenet developers Zothar  and Nextgens decided that they should
> attack and destroy the old network instead of making the new network
> more stable and easier to use.  The following is an IRC chat between two
> of the Freenet developers.
> 
> [20:12:25] <nextgens> Zothar_Work> I need to talk about bringing 0.5
> down with toad
> [20:12:38] <nextgens> Zothar_Work> I've got some ideas on how to do it
> [20:12:52] <nextgens> that would definitly shut up 0.5 trolls, wouldn't it ?
> [20:14:08] <Zothar_Work> nextgens: yeah, that would probably do it
> [20:14:13] <FuriousRage> censoring at hand?
> [20:14:24] <nextgens> it's not about censoring
> [20:14:30] <Zothar_Work> I find it interesting that Frost on 0.5 doesn't
> seem to be having the board spoofing problem 0.7 does
> [20:14:36] <nextgens> it's about prooving that 0.5 has to be replaced :)
> [20:14:43] <Zothar_Work> FuriousRage: vulnerability demonstration
> [20:15:19] <Zothar_Work> that would be indirect "settling"
> 
> When asked to condem this action, the primary developer Matthew Toseland
> (Toad) remained silent.

Well, people do get pushed to extreme measures when protecting themselves from the attack.
And 0,5 community seems to be bent on sabotaging the work done by the developers so far. I
wouldn't support identifying any of the 0,5 posters in public, since some of them can
actually get into trouble, but it would be nice if somebody can go on 0,5 and do traffic
analysis on the Frost keys and then sending private message to people with their ip address.

- --
http://freedom.libsyn.com/       Voice of Freedom, Radical Podcast
http://freeselfdefence.info/     Self-defence wiki
http://www.kingstonstudents.org/ Kingston University students' forum

 "None of us are free until all of us are free."    ~ Mihail Bakunin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFGLRFouWy2EFICg+0RAn+nAJ45HHF+LfFpNl6gXPmugraqTyW4RgCfUugG
JkiXlGEysjQ4YhsUvzgG9Gw=
=sfX7
-----END PGP SIGNATURE-----


From toad at amphibian.dyndns.org  Mon Apr 23 20:15:28 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 23 Apr 2007 21:15:28 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <462D1168.8020701@WhenGendarmeSleeps.org>
References: <379674.58815.qm@web63704.mail.re1.yahoo.com>
	<462D1168.8020701@WhenGendarmeSleeps.org>
Message-ID: <20070423201528.GA4386@amphibian.dyndns.org>

On Mon, Apr 23, 2007 at 09:04:56PM +0100, Volodya wrote:
> 
> Well, people do get pushed to extreme measures when protecting themselves from the attack.
> And 0,5 community seems to be bent on sabotaging the work done by the developers so far. I
> wouldn't support identifying any of the 0,5 posters in public, since some of them can
> actually get into trouble, but it would be nice if somebody can go on 0,5 and do traffic
> analysis on the Frost keys and then sending private message to people with their ip address.

It's not something I can do, but it would be fun and useful to trace
somebody on opennet/0.5. The question is how to do it - the least nasty
way to do it would be for somebody (a prominent frost poster who
contributes content) to volunteer... Then there's the question of
whether anyone would believe us if we don't actually post his IP
publicly...

How to organise such an attempt to trace somebody, in an ethical way, as
a means of investigating the security of 0.5 and/or 0.7 opennet?
-------------- 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/20070423/628ff1d9/attachment.pgp 

From ian at locut.us  Mon Apr 23 21:39:52 2007
From: ian at locut.us (Ian Clarke)
Date: Mon, 23 Apr 2007 16:39:52 -0500
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <20070423201528.GA4386@amphibian.dyndns.org>
References: <379674.58815.qm@web63704.mail.re1.yahoo.com>
	<462D1168.8020701@WhenGendarmeSleeps.org>
	<20070423201528.GA4386@amphibian.dyndns.org>
Message-ID: <823242bd0704231439n247aebe8vb9291c59385067e3@mail.gmail.com>

On 4/23/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:>
> It's not something I can do, but it would be fun and useful to trace
> somebody on opennet/0.5. The question is how to do it - the least nasty
> way to do it would be for somebody (a prominent frost poster who
> contributes content) to volunteer... Then there's the question of
> whether anyone would believe us if we don't actually post his IP
> publicly...
>
> How to organise such an attempt to trace somebody, in an ethical way, as
> a means of investigating the security of 0.5 and/or 0.7 opennet?

I woudn't bother, enough time has been wasted on this pointless feud already.

Ian.

-- 
Founder and CEO, Thoof Inc
Email: ian at thoof.com
Office: +1 512 524 8934 x 100
Cell: +1 512 422 3588
AIM: ian.clarke at mac.com
Skype: sanity


From toad at amphibian.dyndns.org  Mon Apr 23 22:27:31 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 23 Apr 2007 23:27:31 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <823242bd0704231439n247aebe8vb9291c59385067e3@mail.gmail.com>
References: <379674.58815.qm@web63704.mail.re1.yahoo.com>
	<462D1168.8020701@WhenGendarmeSleeps.org>
	<20070423201528.GA4386@amphibian.dyndns.org>
	<823242bd0704231439n247aebe8vb9291c59385067e3@mail.gmail.com>
Message-ID: <20070423222731.GB4386@amphibian.dyndns.org>

On Mon, Apr 23, 2007 at 04:39:52PM -0500, Ian Clarke wrote:
> On 4/23/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:>
> > It's not something I can do, but it would be fun and useful to trace
> > somebody on opennet/0.5. The question is how to do it - the least nasty
> > way to do it would be for somebody (a prominent frost poster who
> > contributes content) to volunteer... Then there's the question of
> > whether anyone would believe us if we don't actually post his IP
> > publicly...
> >
> > How to organise such an attempt to trace somebody, in an ethical way, as
> > a means of investigating the security of 0.5 and/or 0.7 opennet?
> 
> I woudn't bother, enough time has been wasted on this pointless feud already.

You mean it might burst our false sense of security bubble?
> 
> Ian.
-------------- 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/20070423/f6ee610a/attachment.pgp 

From joelcsalomon at gmail.com  Mon Apr 23 23:17:52 2007
From: joelcsalomon at gmail.com (Joel C. Salomon)
Date: Mon, 23 Apr 2007 19:17:52 -0400
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <20070423201528.GA4386@amphibian.dyndns.org>
References: <379674.58815.qm@web63704.mail.re1.yahoo.com>
	<462D1168.8020701@WhenGendarmeSleeps.org>
	<20070423201528.GA4386@amphibian.dyndns.org>
Message-ID: <7871fcf50704231617kfc3e4dfo5d574f394fbfb3d0@mail.gmail.com>

On 4/23/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> How to organise such an attempt to trace somebody, in an ethical way, as
> a means of investigating the security of 0.5 and/or 0.7 opennet?

Somebody volunteers to be selected?

--Joel


From freenet-dev at kork.dyndns.org  Tue Apr 24 11:10:29 2007
From: freenet-dev at kork.dyndns.org (Marco Gruss)
Date: Tue, 24 Apr 2007 13:10:29 +0200
Subject: [freenet-dev] Story Submitted to Slashdot
Message-ID: <462DE5A5.8080601@kork.dyndns.org>

Hi,

Ian Clarke wrote:
 > I woudn't bother, enough time has been wasted on this pointless
 > feud already.
What's with this "feud" anyway? Anybody care to shed some light on this
for the people not hanging out on IRC?

TIA!
Marco


From toad at amphibian.dyndns.org  Tue Apr 24 12:26:55 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 24 Apr 2007 13:26:55 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <462DE5A5.8080601@kork.dyndns.org>
References: <462DE5A5.8080601@kork.dyndns.org>
Message-ID: <20070424122655.GK16502@amphibian.dyndns.org>

On Tue, Apr 24, 2007 at 01:10:29PM +0200, Marco Gruss wrote:
> Hi,
> 
> Ian Clarke wrote:
>  > I woudn't bother, enough time has been wasted on this pointless
>  > feud already.
> What's with this "feud" anyway? Anybody care to shed some light on this
> for the people not hanging out on IRC?

It's more Frost than IRC. As I understand it:
- Lots of people are still on 0.5.
- But probably fewer than are on 0.7 (I have reason to believe the 0.7
  network size estimates are an underestimate).
- Newbies no longer come to 0.5: Freenet has never been able to handle
  churn (install -> this sucks -> uninstall) very well.
- More of the people still on 0.5 have huge datastores.
- Result: 0.5 is faster. Duh!
- It was much slower when it was mainstream, because it had more users
  and a lot more churn.
- One guy from 0.5 posts lists of files available on 0.5 to various
  boards (often off topic) on 0.7, regularly, as Anonymous, in the hope
  of getting newbies onto 0.5. This has provoked a lot of flame wars,
  especially as most Frost users are reluctant to block Anonymous posts
  (a lot of interesting posts are unsigned).
- Somebody has been spamming 0.7 Frost boards recently. Sometimes he
  posts messages which are made up of random words stuck together in a
  pattern resembling old messages, more recently he's been copying
  messages from one board to another or within a board (because of a bug
  in Frost this can be done while preserving the signature; the recent
  frost release introduces a new message format which fixes the
  problem).
- Some people think the spammer and the 0.5 guy are the same person.
- Some people think it would be interesting to attack 0.5 in order to
  demonstrate that it is insecure, and more generally to attack opennet
  to demonstrate that opennet is insecure.
- Some people think I am deliberately sabotaging 0.7 to keep the
  paedophiles and warez doods out.
- And of course, the traditional hatred of all things darknet.
> 
> TIA!
> Marco
-------------- 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/20070424/24f9f96f/attachment.pgp 

From ian at locut.us  Tue Apr 24 14:09:22 2007
From: ian at locut.us (Ian Clarke)
Date: Tue, 24 Apr 2007 09:09:22 -0500
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <20070424122655.GK16502@amphibian.dyndns.org>
References: <462DE5A5.8080601@kork.dyndns.org>
	<20070424122655.GK16502@amphibian.dyndns.org>
Message-ID: <823242bd0704240709w2548191cq32e6fde48729dc7c@mail.gmail.com>

Ok, and so the next question:

Why are you fueling this dumb debate by participating in it?

Ian.

On 4/24/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> On Tue, Apr 24, 2007 at 01:10:29PM +0200, Marco Gruss wrote:
> > Hi,
> >
> > Ian Clarke wrote:
> >  > I woudn't bother, enough time has been wasted on this pointless
> >  > feud already.
> > What's with this "feud" anyway? Anybody care to shed some light on this
> > for the people not hanging out on IRC?
>
> It's more Frost than IRC. As I understand it:
> - Lots of people are still on 0.5.
> - But probably fewer than are on 0.7 (I have reason to believe the 0.7
>   network size estimates are an underestimate).
> - Newbies no longer come to 0.5: Freenet has never been able to handle
>   churn (install -> this sucks -> uninstall) very well.
> - More of the people still on 0.5 have huge datastores.
> - Result: 0.5 is faster. Duh!
> - It was much slower when it was mainstream, because it had more users
>   and a lot more churn.
> - One guy from 0.5 posts lists of files available on 0.5 to various
>   boards (often off topic) on 0.7, regularly, as Anonymous, in the hope
>   of getting newbies onto 0.5. This has provoked a lot of flame wars,
>   especially as most Frost users are reluctant to block Anonymous posts
>   (a lot of interesting posts are unsigned).
> - Somebody has been spamming 0.7 Frost boards recently. Sometimes he
>   posts messages which are made up of random words stuck together in a
>   pattern resembling old messages, more recently he's been copying
>   messages from one board to another or within a board (because of a bug
>   in Frost this can be done while preserving the signature; the recent
>   frost release introduces a new message format which fixes the
>   problem).
> - Some people think the spammer and the 0.5 guy are the same person.
> - Some people think it would be interesting to attack 0.5 in order to
>   demonstrate that it is insecure, and more generally to attack opennet
>   to demonstrate that opennet is insecure.
> - Some people think I am deliberately sabotaging 0.7 to keep the
>   paedophiles and warez doods out.
> - And of course, the traditional hatred of all things darknet.
> >
> > TIA!
> > Marco
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGLfePA9rUluQ9pFARAvNLAKCtAkqwf7OQc84iOkzXCUgBaQNNNwCfV66t
> zXGoeptMoLqUwkHT2wwitfk=
> =7ixA
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


-- 
Founder and CEO, Thoof Inc
Email: ian at thoof.com
Office: +1 512 524 8934 x 100
Cell: +1 512 422 3588
AIM: ian.clarke at mac.com
Skype: sanity


From bbackde at googlemail.com  Tue Apr 24 16:27:22 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Tue, 24 Apr 2007 18:27:22 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
Message-ID: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>

Just an obervation: I have a download running which stucks at some
point. But it keeps running, means it doesn't fail. No matter how long
the node runs, the download seems to hang. If I restart the node, then
suddenly the download continues and more blocks arrive, until it
stucks again. If I restart the node each time when the download
stucks, then it completes sometimes.

Could this be an internal problem?


From jdaviestx at tx.rr.com  Tue Apr 24 17:54:45 2007
From: jdaviestx at tx.rr.com (jdaviestx at tx.rr.com)
Date: Tue, 24 Apr 2007 10:54:45 -0700
Subject: [freenet-dev] Story Submitted to Slashdot
Message-ID: <5172132.1177437285862.JavaMail.root@web34>

---- Matthew Toseland <toad at amphibian.dyndns.org> wrote: 

> - And of course, the traditional hatred of all things darknet.

Hmmm... hatred?  I don't know if I know of anybody who *hates* the idea of the darknet - that would be some pretty amazing censorship resistance... if it worked.  When I first started hearing it described on here, it sounded like a bit of a stretch (where am I going to find three people, in real life, who run Freenet nodes 24x7?  How can I even explain Freenet to my non-Freenet aware but technologically literate friends?  Where am I going to get some friends?) but if it worked, I was all for it.  The problem is, people have been building their small-world connections for, what, two years now?  The darknet hasn't made it over to me yet... although it seems to be working for some of you, the rest of us just kind of wish for something that provided 90% anonymity that we could actually use.


From toad at amphibian.dyndns.org  Wed Apr 25 15:50:28 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 25 Apr 2007 16:50:28 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
Message-ID: <20070425155027.GA11213@amphibian.dyndns.org>

On Tue, Apr 24, 2007 at 06:27:22PM +0200, bbackde at googlemail.com wrote:
> Just an obervation: I have a download running which stucks at some
> point. But it keeps running, means it doesn't fail. No matter how long
> the node runs, the download seems to hang. If I restart the node, then
> suddenly the download continues and more blocks arrive, until it
> stucks again. If I restart the node each time when the download
> stucks, then it completes sometimes.
>
> Could this be an internal problem?

Quite possibly. We've had such reports from time to time, but it is very
difficult to reproduce so it can't be debugged. :(
-------------- 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/20070425/5c4c29b6/attachment.pgp 

From toad at amphibian.dyndns.org  Thu Apr 26 18:37:26 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 26 Apr 2007 19:37:26 +0100
Subject: [freenet-dev] Freenet 0.7 build 1030
Message-ID: <20070426183726.GA17267@amphibian.dyndns.org>

Freenet 0.7 build 1030 is now available. Please upgrade.

Major changes:
- New bookmark editor. Bookmarks are now organised into categories.
- Localisation infrastructure is 99% there. If you still want to help
  with translations, get in touch with us.
- Update to freenet-ext.jar build 13 (datastore fixes).
- IP detection, node to node messages etc fixes.
Related changes:
- The installer should work better on OS/X and maybe on *nix.
- Fix bugs in JSTUN plugin and make it work on java 1.5 again. Upgrade
  your JSTUN plugin if you need it (most people do): Type JSTUN* in the
  load box on the plugins page (note that doing it this way contacts
  downloads.freenetproject.org on every startup), or download it to
  JSTUN.jar in your freenet directory and type *@file:JSTUN.jar.
-------------- 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/20070426/7b5e8dba/attachment.pgp 

From toad at amphibian.dyndns.org  Sat Apr 28 17:21:53 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Sat, 28 Apr 2007 18:21:53 +0100
Subject: [freenet-dev] Sharp request specialisation despite load
Message-ID: <20070428172152.GA25839@amphibian.dyndns.org>

At least something seems to be working:

CHK at c5Ew7yFTTDApBxbwD3Ge~CACOu3B6q2AfKE1JEStUuo,~HfYNW7kN2ETmP2VRYtMruphH7OQR~fRVrcmqmUJZpI,AAIC--8

From Frost, a graph of the incoming requests on a (heavily loaded because low bandwidth iirc)
node he was looking at.
-------------- 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/20070428/81a30acd/attachment.pgp 

From luke771 at gmail.com  Sat Apr 28 20:52:32 2007
From: luke771 at gmail.com (Luke771)
Date: Sat, 28 Apr 2007 22:52:32 +0200
Subject: [freenet-dev] it. transl. v.7 ph00
Message-ID: <4633B410.8080103@gmail.com>

updated at r1045
L.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freenet.l10n.it.override.properties.ph00.v07.gz
Type: application/x-gzip
Size: 12802 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070428/fbb19f2c/attachment.bin 

From luke771 at gmail.com  Sat Apr 28 21:47:56 2007
From: luke771 at gmail.com (Luke771)
Date: Sat, 28 Apr 2007 23:47:56 +0200
Subject: [freenet-dev] it. transl. v.8 - ph00
Message-ID: <4633C10C.1070002@gmail.com>

Fixed some typos and changed a couple of strings.
L
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freenet.l10n.it.override.properties.ph00.v08.gz
Type: application/x-gzip
Size: 12808 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070428/d246b006/attachment.bin 

From m.rogers at cs.ucl.ac.uk  Sun Apr 29 01:01:08 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Sun, 29 Apr 2007 02:01:08 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <5172132.1177437285862.JavaMail.root@web34>
References: <5172132.1177437285862.JavaMail.root@web34>
Message-ID: <4633EE54.6070802@cs.ucl.ac.uk>

jdaviestx wrote:
> The problem is, people have been building their small-world connections for, what, two years now?  The darknet hasn't made it over to me yet...

This is definitely one of the downsides of the darknet approach in
general. But it's exacerbated by the fact that Freenet is trying to
build one global network, as opposed to, say, WASTE, where there are
lots of small, separate networks. It's probably easier to find three
friends who want to set up a small network than it is to find three
friends who already belong to the big network, and that's likely to
remain true until the big network becomes ubiquitous. Of course we don't
want to stay in small, isolated networks forever; ideally we'd set up
small networks with our friends and merge them into the big network
later, but unfortunately I don't think Freenet's architecture can
accommodate that.

Cheers,
Michael


From liquido at mail.com  Sun Apr 29 12:59:27 2007
From: liquido at mail.com (jag heter)
Date: Sun, 29 Apr 2007 07:59:27 -0500
Subject: [freenet-dev] Swedish translation V.4 - Cooo
Message-ID: <20070429125927.1D1B51F50B1@ws1-2.us4.outblaze.com>

Here is V.4 of the swedish translation

/Cooo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://emu.freenetproject.org/pipermail/devl/attachments/20070429/320a46eb/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freenet.l10n.se.override.properties.0.4-Cooo
Type: application/octet-stream
Size: 36631 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070429/320a46eb/attachment.obj 

From luke771 at gmail.com  Sun Apr 29 15:03:52 2007
From: luke771 at gmail.com (Luke771)
Date: Sun, 29 Apr 2007 17:03:52 +0200
Subject: [freenet-dev] ita. transl. v.9 ph00
Message-ID: <4634B3D8.8080505@gmail.com>

updated to r13047
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freenet.l10n.it.override.properties.ph00.v09.gz
Type: application/x-gzip
Size: 14171 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070429/0cc0b75f/attachment.bin 

From toad at amphibian.dyndns.org  Mon Apr 30 13:06:43 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 30 Apr 2007 14:06:43 +0100
Subject: [freenet-dev] Aristocracy again: frost thread
Message-ID: <20070430130643.GD31041@amphibian.dyndns.org>

----- Anonymous ----- 2007.04.29 - 03:05:11GMT -----

You are only halfway there. Someone needs to download it now. As I recall, the last race results for the 0.5 network were 18 hours from the beginning of the insert to the completion of the download.

There are some things to think about while the second part of the race is taking place, you are the developer of this network. If there was anyone who would know how to tune their node for best performance, it would be you. Another thing is that you most likely have many long established connections to others who also have many long established connections. Think about the performance of the newbie -> newbie -> newbie -> newbie nodes. I see the 0.7 network to be like a pyramid scheme. The ones who got here first have the best connection because they have been able to weed out the low performing nodes, while the next level gets stuck with the low performing nodes, and it gets worse from there until the data from the newest user has to go through several levels of poorly performing nodes to finally reach you and your clique of fast nodes.

----- Zeren at Ev72+T5cnPcLHRRiLYEjAt+8YQ8 ----- 2007.04.29 - 15:05:24GMT -----

Isn't that what you would expect from a network seeking security via detachable clusters of mutually-trusted nodes?  Security will be enhanced for those more established.  New nodes initially need to behave well during an evaluation period connecting largely to other nodes of unknown trustworthiness.  Since those more established will tend to be more long-term, their connections will be stronger and the need to risk new connections will be less.

Yes, this does mean new nodes will initially see mostly other new nodes with a high turnover.  It also means that when a massive assault on the network occurs, detached proven clusters or groups of clusters could survive in relative isolation for the time necessary.

That said, during relatively safe periods, we should also to try to connect to new nodes as much as possible to help new nodes become established.

----- toad at zceUWxlSaHLmvEMnbr4RHnVfehA ----- 2007.04.30 - 12:58:54GMT -----

What this means is that new nodes are slow, old nodes are fast. Aristocracy, like the first poster said. We talked about this on 0.5 too. Dealing with newbies (who generally are new nodes, with high turnover i.e. high likelihood of leaving) well is a problem. Opennet doesn't *necessaily* solve the problem; on 0.5 it took a long time to get good connections. One advantage is that nodes with true darknet connections are fast.

Implementing opennet would:
- Force old nodes to connect to newbies. But not necessarily level the playing field.
- Increase the proportion of newbies who decide to stay.
- Reduce the need to get new nodes manually.
- Reduce the performance incentive to get new darknet nodes.
- Grow the network fast.
-------------- 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/20070430/6f241912/attachment.pgp 

From bbackde at googlemail.com  Mon Apr 30 16:19:10 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Mon, 30 Apr 2007 18:19:10 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070425155027.GA11213@amphibian.dyndns.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
Message-ID: <d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>

This seems to be related to the problem, maybe you get an idea what wents wrong:

----- Underworld at TKeLmt1AnnTXyPZReBJzxFzbceg ----- 2007.04.29 -
20:34:36GMT -----

FYI -
If a FQUID download stalls, try lowering the priority, and then
raising it again. This seems to get things moving. I had been using
"Retry Failed Blocks" but this actually restarts the download from
scratch.
I don't know why this works, but it does.
You can also do the same thing from the FProxy Queue Page. So the
stalling is a really a Freenet issue and not a problem with FQUID.

----- Anonymous ----- 2007.04.29 - 21:08:44GMT -----

I've noticed this as well on downloads.  If I change the priority,
either lower or higher, the download will start retrieving blocks
again.


On 4/25/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> On Tue, Apr 24, 2007 at 06:27:22PM +0200, bbackde at googlemail.com wrote:
> > Just an obervation: I have a download running which stucks at some
> > point. But it keeps running, means it doesn't fail. No matter how long
> > the node runs, the download seems to hang.