On 12 Aug, Dennis E. Hamilton wrote: > > >> -----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.
Adding the length definitely raises the bar. When downloading third-party source tarballs to build FreeBSD packages, both the hash and file size are checked. Even so, FreeBSD has switched from md5, to sha1, and now sha256 for the hash. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
