Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Sep 2014 10:32:40 +0400
From: Loganaden Velvindron <>
Subject: Re: Re: [CVE Requests] rsync and librsync collisions

On Tue, Sep 16, 2014 at 9:47 AM, Michael Samuel <> wrote:
> On 13 September 2014 04:39,  <> wrote:
>> The short answer is that we neither agree nor disagree at present; we
>> think that either any required CVE assignment can be made by us after
>> a full public disclosure, or any required CVE assignment can be made
>> by a different CNA now.
> The bug is publicly disclosed.  The exploit isn't (and I believe list rules
> dictate that I can't post exploits here).
>> MITRE is not currently interested in receiving an advance copy of the
>> full public disclosure or any related PoC information from anyone.
>> We'll see whether the CNA process above can work.
> I don't care who assigns the CVE, but it would be nice to be able to link
> the tickets for this together somehow.
> An experimental branch of librsync that uses blake2 is available here:
> Dropbox have responded that they have fixed this bug independently, but
> have not pushed anything out to their forked librsync github repo.

Has Dropbox made a public statement regarding this ?

> I have not heard further from the rsync maintainer.  I will publicly release
> colliding blocks and construction details soon, so if you use rsync on
> untrusted files, consider using the -W option to avoid a DoS.

Has the rsync maintainer acknowledged the issue publicly ?

> Regards,
>   Michael

This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.