On 24 August 2012 11:51, Rory O'Farrell <ofarr...@iol.ie> wrote: > On Fri, 24 Aug 2012 11:31:05 +0100 > sebb <seb...@gmail.com> wrote: > >> On 24 August 2012 09:20, Rory O'Farrell <ofarr...@iol.ie> wrote: >> > On Thu, 23 Aug 2012 18:01:42 -0400 >> > "Maurice Howe" <maur...@stny.rr.com> wrote: >> > >> >> Got a warning msg that your product was unsafe, so I deleted the download. >> >> Here's the msg. >> > <snip> >> > >> > I have this morning scanned my Windows XP computer on which is installed >> > yesterday's release of AOO 3.4.1 using AVG Free edition 2012.0.2197 (this >> > morning's update) at the most detailed settings and it has received a >> > clean bill of health. >> > >> > The question that might arise in connection with the original post is that >> > of the filename/download site; if it is from a legitimate (i.e. Apache >> > controlled site) there should be no worries. >> > >> > It was in the past not unusual for new releases of OOo to give false >> > positives on many virus scanners - the hooks for online updating >> > registered sometimes as poentialy unwanted programs/possible trojans. >> > >> > As another poster (Dan?) pointed out, it is possible to check the Md5Sums >> > of the downloaded file against the MD5Sum list on the Apache site, to be >> > certain that it is exactly the file prepared and released by Apache. If >> > these sums check out then all should be well. >> >> AIUI that's not possible to be *certain* that the file is identical [1]. >> Hashes are fine for checking that a download has not been >> corrupted/truncated in transit, because the chance of a hash collision >> in such a case is vanishingly small. >> >> But they are not generally considered sufficiently robust to *prove* >> that the download is what it appears to be. >> It is theoretically possible to create two different downloads with >> the same hash. >> >> Obviously if the hash check fails, then there is a problem, but a >> successful check does not provide 100% proof. >> >> Checking the detached signature for the download is much more secure, >> but is of course a bit harder to do. >> >> [1] http://www.apache.org/dev/release-signing#secure-hash-algorithms >> >> > -- >> > Rory O'Farrell <ofarr...@iol.ie> >> > > I'm not doubting your remarks above about the possibility of duplicate > hashes, but for most purposes the hash check is probably sufficient.
Yes. > In any event, the timescale involved of some few hours after release would > make the possibility of a rogue hash matching file quite remote (I hope!). Actually there will be at least 3-4 days when the files and hashes are available during release votes. But more likely the rogue file would be published later when it would still catch some downloads. > > -- > Rory O'Farrell <ofarr...@iol.ie>
