On 24.02.2017 16:45, Bryan Quigley wrote: > I'm going to look at adding the SHA256SUM for all the files in > download.lst. It looks like we can add them without breaking > anything. Then we can test out how we want to switch or if we need to > support both for a bit (platform dependent?).
right, and as just discussed on IRC that can even be done without having to rename all the md5-containing filenames on the server, by adding a variable for the SHA256SUM and just ignoring the hash contained in the filename. > On Fri, Feb 24, 2017 at 10:25 AM, Stephan Bergmann <sberg...@redhat.com> > wrote: >> On 02/24/2017 03:47 PM, Norbert Thiebaud wrote: >>> >>> The situation with checksum of 'external' files is much worse that you >>> thought. >>> They are actually checked with md5. >>> That being said they are not truly external, since they are hosted on >>> the project infrastructure >>> and the original motivation was not so much malicious injection >>> detection but faulty transfer. >>> using sha1 there would actually be an 'improvement' :-) actually AFAICS the MD5 usage here is not currently a problem. there are 2 different problems with hash functions, collision attacks and preimage attacks. https://en.wikipedia.org/wiki/Preimage_attack the big news about SHA1 is that somebody successfully performed a collision attack, where they created 2 files from scratch that have the same SHA1. but here we have files that already exist and worry[1] that someone could create another file with the same hash - that is a preimage attack. https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability "In April 2009, a preimage attack against MD5 was published that breaks MD5's preimage resistance. This attack is only theoretical, with a computational complexity of 2^123.4 for full preimage." the SHA1 collision brute-force require 2^80, and less with some clever mathematical insight, so md5 preimage appears at least 2^43 harder. still, if somebody wants to implement using a better hash function, there is no reason to object :) [1] unless the upstream that creates the tarball is actively malicious, but in that case we have other problems _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
