Re: SHA-1 collision

2017-02-24 Thread Thomas Mueller
Hi,

I created OAK-5827 to track this.

The problem is not just that there exist two files. I think it is a real
security vulnerability, because:

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.htm
l


"we will wait 90 days before releasing code that allows anyone to create a
pair of PDFs that hash to the same SHA-1 sum given two distinct images
with some pre-conditions."

Regards,
Thomas




On 24/02/17 08:12, "Thomas Mueller" <muel...@adobe.com> wrote:

>Hi,
>
>A SHA-1 collision has been published:
>https://www.schneier.com/blog/archives/2017/02/sha-1_collision.html
>https://security.googleblog.com/2017/02/announcing-first-sha1-collision.ht
>ml
>
>Our FileDataStore and S3DataStore use SHA-1. For new binaries, we should
>use (for example) SHA-256.
>
>Right now, a content management system that uses Oak as the repository
>can't serve those two files at the same time, if it uses the
>FileDataStore or the S3DataStore.
>
>(The FileBlobStore, MongoDB BlobStore,..., are not affected)
>
>Regards,
>Thomas
>
>
>



SHA-1 collision

2017-02-23 Thread Thomas Mueller
Hi,

A SHA-1 collision has been published:
https://www.schneier.com/blog/archives/2017/02/sha-1_collision.html
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Our FileDataStore and S3DataStore use SHA-1. For new binaries, we should use 
(for example) SHA-256.

Right now, a content management system that uses Oak as the repository can't 
serve those two files at the same time, if it uses the FileDataStore or the 
S3DataStore.

(The FileBlobStore, MongoDB BlobStore,..., are not affected)

Regards,
Thomas