openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Lewis <truck...@apache.org>
Subject Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Date Fri, 12 Aug 2016 20:55:41 GMT
On 12 Aug, Dennis E. Hamilton wrote:
> 
> 
>> -----Original Message-----
>> From: Don Lewis [mailto:truckman@apache.org]
>> Sent: Thursday, August 11, 2016 14:41
>> To: dev@openoffice.apache.org; kschenk@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 Schenk@apache.org wrote:
>> >
>> >
>> > On 08/11/2016 12:50 PM, Kay Schenk@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message