Steve Dougherty | 20 Jul 19:27 2014

GitHub Repository Restructuring

Thanks to nextgens we've finally restructured the repositories on
GitHub. There are backups of all the deleted repositories here:
https://archives.freenetproject.org/github-backups-official/

The changes:

* Repositories with names ending in "-staging" are renamed to remove
  the "-staging". GitHub redirects the old names to the new.
* Repositories with names ending in "-official" are deleted. They were
  strict subsets of the "-staging" repositories.
* The IpToCountry is deleted. It had a single commit from 2011 with a
  copy of database.
* The testnet repositories are deleted.
* The jSite repository is deleted in favor of its official and
  up-to-date upstream: https://github.com/bombe/jsite
* Push permissions are now restricted to project release managers:
  https://github.com/orgs/freenet/teams/freenet-release-managers
  Other authors can push to their personal repositories and open pull
  requests to the project ones.

Thaw is an unofficial plugin in the project organization, [0] but its
author's copy appears abandoned. [1] It's not clear whether it makes
sense to do anything with it. Bombe's version has branches with more
recent activity - would it make sense to delete the project one in favor
of it?

Thanks,
- Steve Dougherty

[0] https://github.com/freenet/Thaw
(Continue reading)

Piotr Chmielnicki | 20 Jul 03:58 2014

Freenet nomad usage

Hello,

People move. We all want some of our moves/travels to stay private.
Unfortunately (in this context), Freenet inserts all known public IPs to
the noderef (or the ARKs linked from the noderef). So, from a noderef it
is possible to discover all IPs where the node was running and the ARK
history could be used to get more precise insight.

In OpenNet mode, this can be used to create a big graph that trace all
different locations of a same Freenet user. That could also be used to
monitor a specific node/user moves ...

In DarkNet mode, this could also be a problem because low-trusted or
deleted (the ARK should not change ...) friends could monitor travels of
a user.

I naive approach to solve that problem would be a "travel mode" where
the node would temporary act as a new OpenNet node (generating temporary
noderef at startup). Other solutions may be better.

Have a nice week-end,

Piotr Chmielnicki

PS : I didn't subscribed to this mailing list so please cc me.

_______________________________________________
Devl mailing list
(Continue reading)

xor | 19 Jul 14:54 2014

Backups of the bugtracker

Hey,
I'm using the bugtracker very heavily for planning WOT development. It would 
throw me back a lot if it was lost.

Who does the backups? How frequently are they done?

If nobody is dealing with it frequently, I would be willing to do them to my 
own storage, I've got admin privileges on the bugtracker already anyway.

Thanks! :)
_______________________________________________
Devl mailing list
Devl@...
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
unixninja92 | 14 Jul 01:56 2014

[GSoC 2014 Crypto API] Status Update 6


Hi all,

This week I mostly worked on unit testing and getting the hashing and
key generation classes ready for merging. I sent in a pull request for
my Hashing API along with my class that would run benchmarks at
start-up and policy file checks for JCE and NSS at the beginning of
the week. I spent the next two days going back and fixing stuff in the
Hashing API. After a long discussion over IRC and github it was
decided that we didn't want to slow Freenet start-up any more with
benchmarks and doing them any other way was outside the scope of my
GSoC project. I have since removed the benchmarking code from my
Hashing API pull request. The Hashing API is pretty much all set now,
but feel free to take a look and let me know if you find anything :)
(I was trying to squash the benchmarking commits out and accidentally
brought in a commit that is not mine into the pull request. Haven't
figured out how to remove it yet.)

I have started writing unit tests and documentation for
MessageAuthCode as well as documentation for a few other classes. I
mostly focused on KeyGenUtils. I have the class as well as it's
documentation and unit tests ready for submitting as a pull request. I
should have this request in tomorrow (Monday). I took the feedback I
got on my Hashing API and applied it to most of the other classes I
have created.

I also ripped out DH support from KeyExchange and the JFKExchange
classes as we will soon only support negType 9 and up.

So this next week I will have a pull request for KeyGenUtils right
(Continue reading)

Steve Dougherty | 12 Jul 22:18 2014

Freenet 0.7.5 build 1464 released

There is a new paper [0] out which was years in the making. It includes
many measurements taken from the live Freenet network with as many as
150 instrumented nodes at once. It even offers suggestions for
improvement! It covers node churn, approximating node uptime with probe
requests, and link length distribution and its impact on routing
efficiency.

In response to this paper's findings on link length distribution, we
plan to implement preferential acceptance of connections based on link
length in order to improve the distribution. There are too many long
links compared to an ideal distribution. [1] It's not yet complete, but
there are changes in this release toward that goal:

- Plot FOAF link length distribution on the statistics page. This
  should be helpful in displaying the local impact of the upcoming
  changes. The green is the proportion in the bucket; gray is
  cumulative.
- Include location in path folding and announcement noderefs. This must
  go mandatory before the preferential acceptance can be deployed;
  without this a peer's location is not known at the time it would need
  to be.

It will be mandatory 2014-07-19.

Reminder: Deprecated things such as
freenet.l10n.BaseL10n.addL10nSubstitution() are subject to removal in a
future version.

The website now shows screenshots more recent than 2009. (!)

(Continue reading)

xor | 8 Jul 06:23 2014

The purpose of NodeClientCore.formPassword in comparison to ToadletContext.checkFullAccess()

While porting Freetalk code to WOT, I was wondering about why page rendering 
code which does "writes" checks whether the request type is "POST"
- by "writes" I mean stuff which changes anything about the Freetalk database 
such as posting a message.

The "blame" feature of Git shows that it came from this commit:

https://github.com/freenet/plugin-Freetalk-staging/commit/ea251b3957cb217fc59284f5d9ab5500dd66f728

I suppose the goal of this commit was to ensure that the higher-level code had 
checked whether the request contained a valid formPassword: It only does the 
password-check for POST, not for GET. See:
https://github.com/freenet/plugin-Freetalk-staging/blob/ea251b3957cb217fc59284f5d9ab5500dd66f728/src/plugins/Freetalk/ui/web/WebInterfaceToadlet.java

This made me wonder about WHY the node has formPassword at all. To understand 
that lets examine which ways can be used to restrict access to a node:
The access controls which the node offers are IP-based only. We have two 
configuration options:
- Which IPs can access the node
- Which IPs are allowed "full access". Internally, this can be validated when 
processing a request via ToadletContext.checkFullAccess().

Those two options seem to target the same goal as the formPassword mechanism: 
Web interface code usually only allows the user to "modify" stuff if he has 
full access. And the formPassword code also does that as we have seen in the 
above Freetalk code.

This made me wonder why we HAVE the formPassword if checkFullAccess can do the 
same thing. So I grepped the source code and it turns out that there is only 
one write access to the NodeClientCore.formPassword variable: In the 
(Continue reading)

Arne Babenhauserheide | 7 Jul 09:49 2014
Picon

Re: Measuring Freenet: Diskussion von Freenet Entwicklern

Hi Stef,

I forwarded your message to devl.

Am Sonntag, 6. Juli 2014, 23:01:00 schrieb Stef:
> from looking over the logs (I hope I found all the points concerning us ;) ), one main point of discussion is
the simulation study about the impact of a suboptimal distance distribution on the routing.
> 1) The study is, as already noted in some of the logs, not really realistic, because we use neither caching
nor churn nor FOAF-routing.

I think we missed that.

>  It only shows that the routing performance in Kleinberg's model (so an artificial network model) is
drastically decreased if  long-range neighbors are chosen uniformly at random rather than proportional
to 1/d (d = distance). We changed Kleinberg's model slightly to allow for arbitrary degree distributions
and used the measured degree distribution in Freenet. An implementation can be found here: https://github.com/stef-roos/GTNA/blob/grouting/src/gtna/networks/model/smallWorld/KleinbergDegreeDist.java

That’s cool - thanks!

> So the actual hop counts are likely very different in the real network (so best forget about those numbers
;)). However, it seems reasonable that the routing in actual Freenet Opennet is worse than it could be as
well. (caching might mitigate the effect to some extent...) 

We could find other indicators for that misrouting. For example the distance of the originating peer of a
request decreases for the first hops (as it should be) but then actually inreases at low HTL. This suggests
that the requests might bounce around on random routes. The much higher success-rate in realtime routing
suggests, that part of our problems could also be due to overload (realtime routing has different
bandwidth-limiting which is optimized for latency instead of throughput, and that means that it
operates with less connection overload and consequently with less misrouting.

(Continue reading)

Arne Babenhauserheide | 7 Jul 09:24 2014
Picon

Fwd: Re: Measuring Freenet: Diskussion von Freenet Entwicklern

===== From: Stef

Hi Arne,

switching to english, in case you want to forward.

from looking over the logs¹ (I hope I found all the points concerning us ;) ), one main point of discussion is
the simulation study about the impact of a suboptimal distance distribution on the routing.

1) The study is, as already noted in some of the logs, not really realistic, because we use neither caching
nor churn nor FOAF-routing.
 It only shows that the routing performance in Kleinberg's model (so an artificial network model) is
drastically decreased if  long-range neighbors are chosen uniformly at random rather than proportional
to 1/d (d = distance). We changed Kleinberg's model slightly to allow for arbitrary degree distributions
and used the measured degree distribution in Freenet. An implementation can be found here: https://github.com/stef-roos/GTNA/blob/grouting/src/gtna/networks/model/smallWorld/KleinbergDegreeDist.java
So the actual hop counts are likely very different in the real network (so best forget about those numbers
;)). However, it seems reasonable that the routing in actual Freenet Opennet is worse than it could be as
well. (caching might mitigate the effect to some extent...) 

2) differences to Oscar's simulation: Which simulation are you referring to? I assume those in
Distributed Routing in Small-World networks, where he compared random ID placements for Darknets with
swapping? well, he used a rather high uniform degree (6 log_2 n are more than 80 neighbors per node) for all
nodes while we used a non-uniform degree distribution with a lot of nodes with a degree of less than 10, that
will lead to different results, especially if the assignment is random  and the target is found by chance
because it is the neighbor of a contacted node...

3) yeah, binning and restricting connections, not exactly an elegant solution, but it seems like you
couldn't think of anything better either...

I considered  doing some strange statistical tests for checking locally if the neighbor selection could be
(Continue reading)

Volker Fervers | 7 Jul 08:27 2014
Picon

database

Hi all,

I remember posts about the search for an alternative to db4o. Are there
any candidates?

Thank you!
GV
unixninja92 | 6 Jul 18:29 2014

[GSoC 2014 Crypto API] Status Update 5


Hi all,

I've had a busy two weeks. Last week I was moving so I didn't get a
chance to send out an update. I submitted a pull request for upgrading
Freenet to BC150 but after a long discussion, I ended up closing it
and changing a few things in CryptBucket. I have since made another
simpler and cleaner pull request that simply allows us to upgrade to
BC150 right away without trying to add support for the new OCB nonce
length that we aren’t using yet.

While implementing JFK message 3 in KeyExchange, I realized that I
also needed a class for encrypting and decrypting byte[]s. After some
discussion on irc with nextgens and others I created the CryptBitSet
class. This can use either BitSets or byte[]s. The advantage of
BitSets is that they make boolean arithmetic much cleaner looking. I
ended up removing AES/CTR, Rijndael ECB and PCFB from CryptBucket and
put them into CryptBitSet. I also added support for ChaCha. After
talking with toad about the current use of Rijndael/CTR (just used in
db4o right now), I found another class to create. I need to write a
replacement for EncryptingIoAdapter. It will be extend
RandomAccessThing rather than IoAdapter. In terms of crypt it will
using the version of ChaCha in BouncyCastle v1.51. This enables ChaCha
to act like a block cipher in CTR mode. I'm anticipating BC151 will be
released as stable relatively soon since they just released the last
beta before stable.

CryptSignature can now accept just a public key rather than a key pair
and only verify things, not sign. Added a KeyType and KeyPairType
class to make key generation and length easier to keep track of. Also
(Continue reading)

Steve Dougherty | 5 Jul 06:40 2014

1464 prerelease testing snapshot

There's a snapshot of something like what will become 1464 on the
webserver (update.sh testing or update.cmd testing) and inserting currently.

This is 1409348672cc32e04231fd739a6bbf09c5f64afd with normalizing stats
page histograms [0] and resource leak fixes [1] merged.

Also in this prerelease:

- Clean up Location; fix 0.0 not being equal to 1.0.
- FCP: Return size values as bytes instead of formatting for display.
- Allow setting download bandwidth limit to the default of -1 for 4x
  upload.
- Improve Toadlet.showAsToadlet() documentation.
- Plot FOAF link length distribution. This should be helpful in
  determining the local impact of upcoming connection logic changes
  which are intended to avoid making more long links than is ideal.
- Include location in path folding and announcement noderefs. This is
  related to the above, and must go mandatory before it can be
  deployed.

Testing is appreciated.

Thank you for using Freenet!

- Steve Dougherty

[0] https://github.com/freenet/fred-staging/pull/246
[1] https://github.com/freenet/fred-staging/pull/235

(Continue reading)


Gmane