oo@lkXpu0~CDV6dh0Idyw4MBwkUSgn~h~Bs3qqVXYOXSaY wrote :
> The Seeker wrote:
>> On 7/11/2010 6:21 AM, oo@lkXpu0~CDV6dh0Idyw4MBwkUSgn~h~Bs3qqVXYOXSaY
>>> johnie@6kzjmQCFtZFFEJ0WThb29r63T5JkJg2Xy5hZSvItG1A wrote:
>>>> Matthew Toseland<toad@amph...>
>>>> IMHO we should attempt to fix, or at least realistically work around,
>>>> big known security issues for 0.8.0, and get a paper published at the
>>>> as the release. These are:
>>>> 1. The Pitch Black attack. Oskar has a good idea how to fix it but has
>>>> simulated a fix. This blocks publishing a paper, and it also prevents
>>>> darknet anywhere where there may be internal attackers. As I understand
>>>> implementation should not be particularly difficult - the main work
>>>> is to implement it in a simple simulator and tweak it until it works,
>>>> 2. The mobile attacker source tracing attack. What this means is an
>>>> knows what is to be inserted (or requested), and he is initially
>>>> the inserter. He recognises the blocks, and uses the keys' locations
>>>> folding, and possibly announcement) to move towards the originator,
>>>> and more of the stream as he moves closer. This is primarily a problem
>>>> opennet, but it is also feasible on darknet - it's just massively more
>>>> expensive. It can be worked around for inserts by:
>>>> i) Inserting with a random splitfile key. THIS IS IMPLEMENTED AS OF
>>>> provided you insert to SSK@, AND
>>>> ii) Providing an easy to use selective reinsert mechanism, AND
>>>> iii) Putting a timestamp on the inserts on any small reinsert, and only
>>>> to nodes that were connected prior to that timestamp.
>>>> IMHO the second and third items are relatively easy.
>>>> At the same time, we can substantially improve data persistence (1255
>>>> does that for big files, but the insert tweaks that are going to be
>>>> soon now would probably gain us a lot more), ship Freetalk, WoT and
>>>> for improved end-user functionality, a fixed wininstaller, lots of bug
>>>> minor usability tweaks, and everything else we've done since 0.7.5.
>>>> And having a paper published at the same time would surely help with
>>>> amongst certain kinds of folk.
>>> Is this the same Toad who managed to break all nodes since 1250+?
>>> Must have been fun for latest users, he will have to publish a lot of
>>> papers to attract more users than are currently leaving.
>>> New, promised features are worthless if the node is broken and resets
>>> datastore or up- and downloads.
>>> What is he smoking to call this *improved persistence*?
>> Thanks for all your hard work testing pre-release builds, it's thanks to
>> input of people like you during testing that we get the quality of
>> we do.
> If you tried being sarcastic you failed.
> We all are running pre-release builds, no matter what Toad calls them and
> no matter whether he declares a build to be 0.80.
> Is there any developer reading and writing here?
> Or maybe in Frost?
> Can you explain to me why Frost was secure enough for Toad on 0.5 but not
> on 0.7?
> If he is panicked by the bots (which bots btw.), shouldn't it at least be
> possible to announce a build in a keyed board if he still rejects to
> Do you think adding hashes to metadata was an improvement?
> As expected the real bug hasn't been fixed, files still get corrupted when
> being inserted, did I write already that this seems to be a bug in FEC
> (some downloaders are affected, some not, the older the file the lower the
> chance to get it uncorrupted)?
> True, the downloading node now detects this corruption and throws away all
> blocks, just saying hash mismatch.
> With previous builds one was able to repair corrupted files, read about
> Now your node says "sorry, this file is toad, I can't pass it on to you".
> Great improvement, isn't it?
> Can you please ask him to remove hash check as long as he doesn't fix the
> real bug?
> We know ourselves when a file is corrupted.
> We don't need the node to detect it when downloading the file, we need a
> node not corrupting the file when it is being inserted.
> I could continue my rant with p0's comment about NNTP not being of primary
> interest for Freetalk, Webinterface to be sufficient.
> Over and out.