Re: [bug-GNUnet] Serious vulnerabilities in GNUnet 0.6.4

[Christian Grothoff]

On Wednesday 01 Sep 2004 1:22 pm, Marcos D. Marado Torres wrote:
> On Tue, 31 Aug 2004, Christian Grothoff wrote:
> > security ("more random").  If you have some insight that changes this
> > perception, please share it (and I'll consider changing the protocol once
> > we break compatibility big time in the future).
>
> [...]
>
> > c) it is highly likely that this will be fixed once we break
> > compatibility (we have not done on this level since 0.4.x or so and I
> > still do not consider this attack 'strong' or serious enough to justify
> > breaking compatibilty to just fix this problem).
>
> Wouldn't be the right time to brak the compatibility sooner rather then
> later? I think that the best thing to do in GNUnet development is to set
> stuff that breaks  compatibility between versions as well as security
> issues as "critical changes" to do ASAP. While we're getting closer and
> closer to 1.0, more people are using GNUnet and inserting stuff, so the
> later (closer to 1.0) we break compatibility, less atractive it will be to
> users...

We know that there is a definitive point in the development where we will have 
to break compatibility that cannot be moved to earlier (because a lot of code 
& testing has to happen until then), it makes sense to delay other changes 
that break compatibility to that point (if possible). 

Let me give you an example. If you've followed the ECRS paper, you may have 
read about KBlocks.  They're not implemented yet (and somewhat break 
compatibility). For 0.6.4 the new 'gmp' dependency was introduced as a first 
step towards an implementation of KBlocks.  There are other such changes, all 
of which require still a lot of work.  Now, we could break compatibility each 
time we introduce such a feature (or discover how to do something a little 
bit better) or we can try to push the code as close as possible to the point 
where compatibility will break -- and break it once (as opposed to every 
other release).  

I currently see the big break happen 12/2004 or early in 2005 (the version 
will be called 0.7.0).  At that point I want to make *all* of the changes to 
the protocol, datastore, and so on that have been found to be suboptimal for 
some reason or other.  There'll be some more releases in the meantime that 
will push some of the existing features to their limits and cleanup the code 
to _prepare_ for breaking compatibility.  Hopefully this will be the last 
time this happens (at least before 1.0.0), but that depends in part on having 
a good idea of what are all of the problems with the current protocol, 
encoding, datastore format, etc.  Now, this kind of audit is good for that 
purpose (even if some of the things were known, it's often good to be 
reminded of them or to have such a summary at hand when the time comes :-)

Christian