On Thu, 2010-07-01 at 08:56 -0400, michael.fe...@evonik.com wrote:
> I better already start to run for it,
> when I ever approve the use of the current implementation of the
> representation cache.
Here's what this says to me: it doesn't matter what the real risks are;
it only matters that the q
Mark Mielke wrote on Thu, 1 Jul 2010 at 10:40 -0400:
> I read that article several years ago. Correct me if I am wrong - but the
> article does not describe a "real world collision". It describes how it is
> technically possible to find a collision in fewer than previous thought
> sample.
Yeah. A
On 07/01/2010 08:00 AM, michael.fe...@evonik.com wrote:
Thanks for your wishes,
but it seems that I will never be famous:
"Hash Function Update Due to Potential Weakness Found in SHA-1"
http://www.rsa.com/rsalabs/node.asp?id=2834
I read that article several years ago. Correct me if I am wrong
sion.apache.org" ,
michael.fe...@evonik.com
Thema: Re: Antwort: Re: ... Re: dangerous implementation of
rep-sharing cache for fsfs
On Wed, Jun 30, 2010 at 10:13 PM, Daniel Shahaf
wrote:
> [ trim CC ]
>
> Mark Mielke wrote on Wed, 30 Jun 2010 at 21:37 -:
>> On 0
t;dev@subversion.apache.org"
Kopie: michael.fe...@evonik.com
Thema: Re: Antwort: Re: ... Re: dangerous implementation of
rep-sharing cache for fsfs
[ trim CC ]
Mark Mielke wrote on Wed, 30 Jun 2010 at 21:37 -:
> On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote:
> >
dangerous implementation of
rep-sharing cache for fsfs
I think if you could find a real life collision - you might be able to
get some sort of award. Good luck. :-)
Cheers,
mark
On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote:
> Hello,
>
> O.K., it seems there is really a need to
On Wed, Jun 30, 2010 at 10:13 PM, Daniel Shahaf wrote:
> [ trim CC ]
>
> Mark Mielke wrote on Wed, 30 Jun 2010 at 21:37 -:
>> On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote:
>> > P.S. Thanks for the warning; we are not going to use 1.7.
>
> Did you check what is the probability of dyin
[ trim CC ]
Mark Mielke wrote on Wed, 30 Jun 2010 at 21:37 -:
> On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote:
> > P.S. Thanks for the warning; we are not going to use 1.7.
Did you check what is the probability of dying in a car accident?
> > At the Moment we are not using 1.6
I think if you could find a real life collision - you might be able to
get some sort of award. Good luck. :-)
Cheers,
mark
On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote:
Hello,
O.K., it seems there is really a need to discuss the problem of
SHA-1 collisions more deeply.
...
But one
edu,
Mark Phippard
Thema: Re: Antwort: Re: Re: dangerous implementation of
rep-sharing cache for fsfs
On 06/25/2010 03:34 PM, Daniel Shahaf wrote:
> [1] apparently, no SHA-1 collisions have been found to date. (see
> #svn-dev log today)
>
We know SHA-1 collisions must exist, howe
On 06/25/2010 03:34 PM, Daniel Shahaf wrote:
[1] apparently, no SHA-1 collisions have been found to date. (see
#svn-dev log today)
We know SHA-1 collisions must exist, however - they are also likely to
take unlikely form. The algorithms were specifically chosen so that
small changes in b
Daniel Shahaf wrote:
> Daniel Shahaf wrote on Fri, 25 Jun 2010 at 22:34 -:
>> If you have specific questions about FSFS internals, you can ask them on
>> this list.
>
> Why don't you just use BDB? Or use FSFS with rep-sharing disabled?
BDB does rep-sharing, too, and doesn't allow you to disa
Daniel Shahaf wrote on Fri, 25 Jun 2010 at 22:34 -:
> If you have specific questions about FSFS internals, you can ask them on
> this list.
Why don't you just use BDB? Or use FSFS with rep-sharing disabled?
michael.fe...@evonik.com wrote on Fri, 25 Jun 2010 at 19:33 -:
> Hello,
>
> Martin got my point:
> >> It's not the probability which concerns me, it's what happens when
> >> a file collides. If I understood the current algorithm right the
> >> new file will be silently replaced by an unrelated
Hello,
Martin got my point:
>> It's not the probability which concerns me, it's what happens when a
file
collides. If I understood the current algorithm right the new file will be
silently replaced by an unrelated one and there will be no error and no
warning at all. If it's some kind of mach
15 matches
Mail list logo
