helen whitter | 29 Jul 05:32 2014
Picon

Auto-response

   I am awayi? 1/2 at present but would love to hear from you when I get
   back Thank you
Steve Dougherty | 29 Jul 04:44 2014

1465 Prerelease

1465 prerelease is now available on the website: update.sh testing /
update.cmd testing. Inserts are pending.

If all goes well 1465 will be released on Sunday, August 2nd.

The release notes will look something like:

The major network structure change in this upcoming release is
preferential opennet peer acceptance based on link length. The Roos,
Schiller, Hacker, and Strufe paper [0] reports far too many long links.
The statistics we've been collecting observe this as well. This release
accepts comparatively few long links, which should allow much better
navigation of the local keyspace.

Java 6 has been EOL since February 2013. [1] This release adds an alert
when running with Java earlier than 1.7. [2] Freenet will require Java
1.7 or higher in a future release.

Also in this release:

* Add Russian Windows installer translation.
* Add permissions attribute to main jar manifest.
* Allow building with Bouncy Castle 1.50 and higher. 1.49 had a draft
implementation of OCBBlockCipher, and an updated draft in 1.50 limited
the key size below what Freenet was using.
* Add X-Content-Type-Options nosniff header.
* Disable negtypes before 9. Negtype 9 has been mandatory since build
1448 went mandatory on July 23rd, 2013. Future releases will remove the
code for these unused negtypes.
* Remove :visited from CSS to prevent pages from appearing differently
(Continue reading)

unixninja92 | 28 Jul 03:55 2014

[GSoC 2014 Crypto API] Status Update 7


Hi all,

I've been writing lots of unit tests and documentation these past two
weeks. As soon as KeyGenUtils is merged in, I will submit pull
requests for MessageAuthCode and CryptBitSet as they are both
complete. The only bug with CryptBitSet right now is that when I'm
encrypting BitSets with Rijndael in PCFB mode the first half of the
BitSet is encrypted and/or decrypted incorrectly. It works just fine
when using byte[]s, this bug only appears with BitSets. I have no idea
why this is happening. If you have any ideas about why this might be
happening let me know. [1][2]

I wrote an EncryptedRandomAccessThing for Toad's db4o replacement. It
requires BC 1.51 though, so we will have to wait for that to be
released. Should be soon as they recently released the last beta for
1.51.

I have started working on documenting, unit testing, and bug fixing
CryptSignature. DSA can now handle both SecureRandom and RandomSource
rather than just RandomSource. Sign and verify now have their own
addBytes methods rather than sharing them. This solves init issues
with the Signature class.

After some discussion on IRC I have upgraded all of my tests to use
JUnit 4. This has helped make them cleaner and easier to understand.

-Charles

[1]
(Continue reading)

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)


Gmane