Re: [freenet-dev] Behind the times

[xor]

First of all let me say that I'm happy to see you participate again :)

If you feel like contributing some more, I can highly recommend IRC as the 
discussion there is nowadays very frequent and vivid.
The mailing list is usually used more as a fallback if people don't reply to 
very important stuff soon enough.


On Tuesday, September 29, 2015 02:50:27 PM Ian Clarke wrote:
> Unfortunately these aren't the only ways we've fallen behind the times
> (hard to believe we've been doing this for 15 years!).

I've recently been citing Freenet as 16 years old, based on the year of the 
Freenet whitepaper. What's the actual age? :)

>- Maven/Gradle are now de-facto standard build systems for Java apps,
>and yet we're still using Ant (I was never convinced by the security
>argument against these tools, since we don't audit 3rd-party libraries
>anyway)

There are 2 aspects here:

1) The security issue.

I understand that nobody would want to conduct man-in-the-middle via Maven to 
attack some random Android game developer or whatever. Attacks who are 
interested in using botnets for spam or whatever also probably even couldn't 
get access to the Internet backbones to inject their fake binaries.

However please look at *our* threat model:
Freenet is a highly political project, and thus our biggest threat is 
governments.
Governments control infrastructure, and this includes having access to the 
core Internet backbones.
Conducting MITM is trivial if you have backbone access, and so they're very 
likely to abuse it if our developers execute arbitrary binary code which is 
downloaded from the Internet without any verification whatsoever.

As you did argue against Ant, one could say that it is also trivial for them 
to maliciously inject *non*-binary code, i.e. alter the source code of third 
party projects which we pull without review. So we'd be in the same danger 
with Ant.
However this misses the fact that injecting source code *without getting 
noticed* is a lot more difficult than injecting binary code: Source code is 
human-readable, binary code is not. I mean who is going to shove a JAR into a 
disassembler and read the bytecode? I don't think anyone is going to do that.

With using Ant, we at least have the possibly that third-party projects review 
code on their own before merging it - just as we do.

And besides that, I think running arbitrary unsigned code off the Internet is 
really a core basic security mistake; and hence something which is just not by 
any means even up for discussion to be done on purpose by a security-focused 
project as we are. It's Maven's problem if they cannot keep up with industry 
security standards and thus are ditched in favor of Ant.
We shouldn't let ourselves be dragged down to such mistakes just because Maven 
is popular.


2) What can Maven do which Ant cannot do? Do we need those features?

I currently cannot recall anything severe which I'm missing from Ant.
It is critically important to notice that it must provide some kind of 
advantage before we consider changing it. This is because the imbalance 
between the size of our TODO list and the amount of developer force we have 
has grown very high - there are far too few developers. So we must avoid work 
which doesn't yield an immediate big benefit for our users; or potentially 
even is "only changing stuff around for the sake of changing stuff around".

Just have a look at how many subprojects we have:
https://wiki.freenetproject.org/Projects
Yet we currently only have the money for funding 1-2 persons.
And we spent years worth of work upon writing new core fred features, while 
mostly not dealing with deployment of sub-projects, i.e. client applications. 
So there is a huge lack of getting existing code out to the users. This makes 
both developers unhappy because their work is ignored, and Freenet users 
unhappy because Freenet has few actual features.
I'm happy that I've been given the opportunity to work with deployment as 
client application maintainer, thats a step in the very right direction IMHO.
But even if I continue to use all my available time on deployment, we still 
don't have enough workforce to get *all* apps polished to deploy-ableness any 
soon. It'll likely take a year for each.
So overall I think we should also stick to trying to motivate volunteers to 
deploy as much as possible - instead of merely dealing with changing things 
around such as Ant -> Maven.

>- Website badly needs an update, it looks very dated and frankly a bit
>spammy.  Bootstrap 
> anyone, or even the Github page generator
>
> would be a big improvement

Steve has been working on deploying the remake, and I'm confident he'll finish 
it soon:
https://testing.freenetproject.org/   (Username / Password = guest)

AFAIK this is a direct result of your mail, so thanks for motivating people to 
do this :)

Also, we've

Re: [freenet-dev] Behind the times

[Ian]

What's the username/pwd for https://testing.freenetproject.org/ ?

On Sun, Oct 4, 2015 at 10:40 PM, Steve Dougherty 
wrote:

> On 09/29/2015 07:26 PM, Arne Babenhauserheide wrote:
> > Am Dienstag, 29. September 2015, 14:50:27 schrieb Ian Clarke:
> >>- Website badly needs an update, it looks very dated and frankly a
> bit
> >>spammy.  Bootstrap 
> >> anyone, or even the Github page generator
> >>
> >> would be a big improvement
> >
> > Gerard created a new site a few months ago and we’ve been working on
> > finalizing it since then. Yesterday he uploaded a new test-version:
>
> I spent the weekend on this and I think it's almost ready. When I get
> more time to devote to it I'll upload it to Transifex and put out a call
> for translators. I'd like to avoid deploying it with fewer words
> translated than the current site, but I'll put a 2-week maximum on how
> long to wait.
>
> The current development state of the site remains here:
>
> https://testing.freenetproject.org/
>
> and my fork is
>
> https://github.com/Thynix/freenet-website
>
>
> ___
> Devl mailing list
> Devl@freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Behind the times

[Steve Dougherty]

On 09/29/2015 07:26 PM, Arne Babenhauserheide wrote:
> Am Dienstag, 29. September 2015, 14:50:27 schrieb Ian Clarke:
>>- Website badly needs an update, it looks very dated and frankly a bit
>>spammy.  Bootstrap 
>> anyone, or even the Github page generator
>>
>> would be a big improvement
> 
> Gerard created a new site a few months ago and we’ve been working on
> finalizing it since then. Yesterday he uploaded a new test-version:

I spent the weekend on this and I think it's almost ready. When I get
more time to devote to it I'll upload it to Transifex and put out a call
for translators. I'd like to avoid deploying it with fewer words
translated than the current site, but I'll put a 2-week maximum on how
long to wait.

The current development state of the site remains here:

https://testing.freenetproject.org/

and my fork is

https://github.com/Thynix/freenet-website



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Freenet/Tunnels 2015-08 paper: On the Impossibility of Efficient Self-Stabilization in Virtual Overlays with Churn

[Matthew Toseland]

On 27/09/15 20:17, xor wrote:
> http://www.researchgate.net/publication/280623435_On_the_Impossibility_of_Efficient_Self-Stabilization_in_Virtual_Overlays_with_Churn
>> Abstract
>> —Virtual overlays generate topologies for greedy rout-
>> ing, like rings or hypercubes, on connectivity restricted networks.
>> They  have  been  proposed  to  achieve  efficient  content  discovery
>> in  the  Darknet  mode  of  Freenet,  for  instance,  which  provides
>> a  private  and  secure  communication  platform  for  dissidents
>> and  whistle-blowers.  Virtual  overlays  create  tunnels  between
>> nodes  with  neighboring  addresses  in  the  topology.  The  routing
>> performance   hence   is   directly   related   to   the   length   of   the
>> tunnels,  which  have  to  be  set  up  and  maintained  at  the  cost  of
>> communication overhead in the absence of an underlying routing
>> protocol.
>> In this paper, we show the impossibility to efficiently maintain
>> sufficiently short tunnels. Specifically, we prove that in a dynamic
>> network either the maintenance or the routing eventually exceeds
>> polylog  cost  in  the  number  of  participants.  Our  simulations
>> additionally  show  that  the  length  of  the  tunnels  increases  fast
>> if  standard  maintenance  protocols  are  applied.  Thus,  we  show
>> that virtual overlays can only offer efficient routing at the price
>> of high maintenance costs.
I don't think this applies to Freenet at the moment, at least not
directly. Darknet-mode Freenet is an embedding, not a virtual overlay
(that is, we change the ID's to make routing based on ID work, rather
than establishing tunnels as virtual connections based on ID), and it
has relatively low churn.

It might apply to darknet Freenet if we adopted X-Vine for routing
rather than using location swapping. This might be necessary if we can't
make swapping scale. At the moment it looks like swapping doesn't scale
(that is, the stabilisation time is greater than polylog in the size of
the network), but Vilhelm Verendel identified several possibilities for
improving it.

It would be worth reading the wider literature, especially the thing
about hyperbolic space. Oskar has mentioned two other location
assignment/routing algorithms that try to achieve the same thing as our
Metropolis-Hastings swapping mechanism. The paper above dismisses work
on embeddings as not sufficiently proven.

Right now this is largely academic as there is no large darknet-mode
Freenet...



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Behind the times

[Florent Daigniere]

On Fri, 2015-10-02 at 08:48 -0400, Steve Dougherty wrote:
> On 10/02/2015 08:29 AM, Victor Denisov wrote:
> > > > How about a custom Maven repo with checked/approved
> > > > dependencies only?
> > > > Creating a Maven repo is trivial if a Web server is already
> > > > running; and
> > > > it can also be done in a GitHub repo - though GitHub certainly
> > > > wasn't
> > > > designed for such a use, I know a couple of projects which host
> > > > their
> > > > repos this way without problems.
> > > 
> > > While that could offer useful amounts of control, it seems likely
> > > to be
> > > against typical usage / culture around Maven, and unless I'm
> > > missing
> > > something wouldn't provide checksum / signature verification at
> > > time of use.
> > 
> > I wouldn't say that it is contrary to Maven culture (a lot of
> > open-source projects - i.e., Vaadin - run custom repos, and, of
> > course,
> > many larger companies with proprietary code run custom repos as
> > well).
> > The issue of signature verification should be researched further -
> > I
> > know there's a Maven plugin which can check dependency signatures
> > at
> > build time; but of course most of the libraries out there aren't
> > signed
> > - so maintainers will have to provide their own signatures (one
> > more
> > point for running a custom repo).
> 
> Unless I'm missing something the ant build is doing less verification
> than I thought. It looks like it's verifying the downloaded freenet
> -ext
> jar against a SHA-1 downloaded from the same server. [0] (As opposed
> to
> from the repo.)
> 
> I'd be perfectly happy with verifying against checksums committed to
> the
> repository, for instance.
> 
> [0] https://github.com/freenet/fred/blob/next/build.xml#L54
> 

It's not as braindead as it sounds; The data and checksums used to come
off different servers... Emu was redirecting the data download request 
to the mirror network

Florent

signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hi

[Florent Daigniere]

On Sun, 2015-10-04 at 14:16 +0100, Matthew Toseland wrote:
> On Sun, Oct 04, 2015 at 01:58:15AM -0400, Steve Dougherty wrote:
> > In the light of the elliptic curve attacks [0] are you interested
> > in
> > helping rekey the seed nodes? Does it require new code?
> > 
> > - Steve
> > 
> > [0] 
> > https://freenetproject.org/news.html#20150917-ecdsa-vulnerability
> 
> I don't think this affects us much actually. It only exposes the
> ephemeral
> ECDH keys, not the node private key. We don't need to change the
> ECDSA node 
> private keys because of a bug affecting ECDH, which uses different
> keys.
> 
> I guess if Mallory can crack the ECDH keys fast enough he might be
> able to do
> an MITM against the connections between his peers and their peers. Or
> maybe 
> just passively decrypt the connections?

Both.

>  JFK is designed to provide some 
> protection against DH bugs?

As far as I understand it doesn't help us here. With JFK we cache/reuse
the points across runs, making us potentially vulnerable to an active
oracle (what the attack is). The non-deterministic nature of which
exponential/point we use for which peer makes it only marginally harder
to attack than other protocols.

What may or may not save us is that we've been using different JCE
providers (including a patched version of BC)... If you care to explain
what the code you've ended up merging does, I'm sure we can give a
better explanation.

>  On darknet, Mallory can't get any further than his
> peers' peers. On opennet, he can add more connections, but there are
> easier
> attacks for that e.g. malicious seednodes.
> 

I don't do opennet :p
But yes, the naive (and probably best) attack is to go after the
seednodes.

Florent

signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hi

[Matthew Toseland]

On Sun, Oct 04, 2015 at 01:58:15AM -0400, Steve Dougherty wrote:
> In the light of the elliptic curve attacks [0] are you interested in
> helping rekey the seed nodes? Does it require new code?
> 
> - Steve
> 
> [0] https://freenetproject.org/news.html#20150917-ecdsa-vulnerability

I don't think this affects us much actually. It only exposes the ephemeral
ECDH keys, not the node private key. We don't need to change the ECDSA node 
private keys because of a bug affecting ECDH, which uses different keys.

I guess if Mallory can crack the ECDH keys fast enough he might be able to do
an MITM against the connections between his peers and their peers. Or maybe 
just passively decrypt the connections? JFK is designed to provide some 
protection against DH bugs? On darknet, Mallory can't get any further than his
peers' peers. On opennet, he can add more connections, but there are easier
attacks for that e.g. malicious seednodes.

Florent?


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl