R devel - May 2015 - Wrongly checked MD5 checksums in R 3.2.0's windows binary

Hi Duncan,
Thank you for the clarification. :)

I ended up removing these files from being scanned in the updated version
of installr. I would rather focus on supporting an MD5 scan that is based
on what is listed in MD5 file itself (ignoring exceptions that are not
clearly stated in the file).









----------------Contact
Details:-------------------------------------------------------
Contact me: Tal.Galili at gmail.com |
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)
----------------------------------------------------------------------------------------------


On Mon, May 11, 2015 at 4:18 PM, Duncan Murdoch <murdoch.duncan at
gmail.com>
wrote:
> On 11/05/2015 8:35 AM, Tal Galili wrote:
>
>> Thank you Duncan, Peter and Martin for the responses.
>>
>> Just to mention that the code is based on tools::md5sum, and the issue
>> can be reproduced (in Windows) using:
>>
>> if(!require(installr)) install.packages("installr")
>> installr::checkMD5sums2(dir=R.home())
>>
>>  I think you didn't understand my post.  It's a bug in your
code: you
> need to compare the md5sum value to the ones I mentioned, not just to the
> one listed in the MD5 file.
>
> Duncan Murdoch
>
	[[alternative HTML version deleted]]

On 11/05/2015 9:35 AM, Tal Galili wrote:
> Hi Duncan,
> Thank you for the clarification. :)
>
> I ended up removing these files from being scanned in the updated 
> version of installr. I would rather focus on supporting an MD5 scan 
> that is based on what is listed in MD5 file itself (ignoring 
> exceptions that are not clearly stated in the file).
>
I'm not sure what the purpose is of your test, but if it is to detect 
modified files, that might not be a good strategy.  A malicious agent 
could install fake bin/R.exe or bin/Rscript.exe and not be caught.

Of course, if they knew to modify those two files but not any others, 
they would know enough to also install a fake MD5 file, and then there's 
basically nothing you could do.

Duncan

> On 11 May 2015, at 15:53 , Duncan Murdoch <murdoch.duncan at
gmail.com> wrote:
> 
> On 11/05/2015 9:35 AM, Tal Galili wrote:
>> Hi Duncan,
>> Thank you for the clarification. :)
>> 
>> I ended up removing these files from being scanned in the updated
version of installr. I would rather focus on supporting an MD5 scan that is
based on what is listed in MD5 file itself (ignoring exceptions that are not
clearly stated in the file).
>> 
> 
> I'm not sure what the purpose is of your test, but if it is to detect
modified files, that might not be a good strategy.  A malicious agent could
install fake bin/R.exe or bin/Rscript.exe and not be caught.
> 
> Of course, if they knew to modify those two files but not any others, they
would know enough to also install a fake MD5 file, and then there's
basically nothing you could do.
> 
> Duncan
As a general matter, checksumming is useless against tampering if you ship the
checksums with the files (that's why I put the checksums in the release
announcements: so that they travel alon a different route to the user). If you
do, they only make sense as safeguards against technical errors (such as the
infamous CR/CRLF conversions).

I still don't get why Tal refuses to work out the apparently quite simple
logic that decides which checksums should be used to check the installed R.exe
and Rscript.exe.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com