> -----Original Message----- > From: Don Lewis [mailto:truck...@apache.org] > Sent: Thursday, August 11, 2016 14:41 > To: dev@openoffice.apache.org; ksch...@apache.org > Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] > Applying openoffice-4.1.2-patch1 for Windows) > > On 11 Aug, Kay sch...@apache.org wrote: > > > > > > On 08/11/2016 12:50 PM, Kay sch...@apache.org wrote: > >> > >> > >> On 08/09/2016 02:12 PM, Kay Schenk wrote: > >>> [top posting] > >>> I'm in the process of trying to "sync" instructions for Linux32, > >>> Linux64, and MacOSX at the moment. As far as instructions on the > >>> actual HOTFIX page, we need to have just a "general" instruction for > >>> ALL zips that simply says -- "Unzip this package to some folder of > >>> your choosing and read the README that's included." Everything else > >>> should be in the various READMEs for each platform. > >>> > >>> I should be done with all edits by this evening for a final review > >>> before zipping and signing. > >> > >> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64 > >> and Mac. > >> > >> My openssl version on does NOT supply digest sha256. Is it OK to use > >> sha1? MD5 already computed for each of these. > > > > sha1 is referenced on the ASF code signing page so I decided it was > OK. :) > > I'm really surprised that ASF requires MD5 since it was broken long ago. > Even SHA1 is now regarded as a weak hash. [orcmid]
I think it depends on shrinking the attack surface and also what the MD5 is being used for. In the present case, it is extremely difficult to construct a Zip that has different usable content and the same hash. It would require adding extra content until the correct hash is duplicated despite alteration of the key payload, and that should become rather evident. I think the main reason for keeping it is that checking the MD5 is still more widely available to users. It may not be foolproof but it is better than not. And yes, collisions are possible and can be manufactured, but having one that accomplishes something can be rather tricky. The proofs-of-concept involve alterations that aren't visible and won't be noticed. Somebody will notice and it is not clear that the possible benefit is worth the effort to pull it off, especially against the risk of discovery. Hmm, one thing we could do is add the length of the zip in the README. (It takes a little work, but can be done, even when the (signed) README is inside the Zip. That's another nice reason for having the signed README also available for independent download outside of the Zip and only downloadable from the ASF archive site, along with the different hashes and the package's signature. [Anecdotal Side Note: I just discovered that the MD5 hash for the 4.1.2 Windows .exe fails to check on my Windows system because of a defect in the .md5 file. For reasons unknown, the md5sum tool that I have requires exactly two spaces between the hash value and the name of the file the hash is for. Once I fiddled around and added the second space, it all checks. What is intriguing to me is that this has not been reported by anyone, which is perhaps of greater concern than the fact that MD5 is used [;<]. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
