On Fri, Aug 24, 2012 at 7:23 AM, sebb <seb...@gmail.com> wrote: > 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. >
Ideally we'd have a way for the user to verify this themselves, without getting into command-line tools. For example, a trusted website with an applet that would verify hash and signature for a local file. Or could this conceivably be doe with Javascript? >> >> -- >> Rory O'Farrell <ofarr...@iol.ie>
