Re: [R-SIG-Mac] SHA-1 Hash for R-3.5.0.pkg Incorrect

[peter dalgaard]

For whatever it is worth, I am using shasum -a 256 for the source release 
announcements.

-pd

> On 25 Apr 2018, at 22:37 , Marc Schwartz  wrote:
> 
> Hi Simon,
> 
> Thanks for the explanation.
> 
> It did not occur to me that SHA-0 was being used, since it was withdrawn as a 
> standard circa early 90's, after significant flaws were identified.
> 
> Apple (and others) either have or are moving away from SHA-1 to SHA-2, at 
> least for TLS/PKI security:
> 
>  https://support.apple.com/en-us/HT207459 
> 
> 
> recognizing the differences between session specific TLS/PKI trust uses and 
> longer term file integrity checking. I know Linus is more "relaxed" regarding 
> SHA-1 and the implications for Git, or at least was last year, albeit 
> indicating a path away from it in time.
> 
> I guess the question boils down to, if we are going to provide hashes of the 
> files under the premise that it should offer a high level of comfort to useRs 
> that the file has not been modified/replaced since generation, presuming that 
> the published hash value itself was not altered, I would put forth for 
> further discussion, moving to SHA-2 and away from both MD5 and SHA-1 
> (certainly moving away from SHA-0), depending upon a more broad assessment of 
> the implications of doing so.
> 
> Thanks!
> 
> Marc
> 
> 
>> On Apr 25, 2018, at 2:54 PM, Simon Urbanek  
>> wrote:
>> 
>> Marc,
>> 
>> thanks, the issue is:
>> 
>> hagal:R-3.5.0$ openssl sha R-3.5.0-el-capitan-signed.pkg
>> SHA(R-3.5.0-el-capitan-signed.pkg)= 9f5f3365afee54d3fe3148a60c1405955916f076
>> 
>> hagal:R-3.5.0$ openssl sha1 R-3.5.0-el-capitan-signed.pkg
>> SHA1(R-3.5.0-el-capitan-signed.pkg)= 6e90d38892bb366630ae30c223a898e8af84dff7
>> 
>> so either we change the label to SHA (or SHA-0?) or change the checksum. In 
>> the root we actually provide both, even if that may or may not be relevant. 
>> For now I did the latter in the index.html.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>> 
>> 
>>> On Apr 25, 2018, at 7:57 AM, Marc Schwartz  wrote:
>>> 
>>> Hi All,
>>> 
>>> Last month:
>>> 
>>> https://stat.ethz.ch/pipermail/r-sig-mac/2018-March/012691.html
>>> 
>>> there was a report that the SHA-1 hash of the R-3.4.4.pkg, as listed on 
>>> CRAN, was not correct, even though the MD5 hash and the digital signature 
>>> appeared to be correct.
>>> 
>>> The same phenomenon is the case with R-3.5.0.pkg.
>>> 
>>> The MD5 hash on CRAN is:
>>> 
>>> MD5-hash: 414029c9c9f706d3d04baa887ccffbc4 
>>> 
>>> and I get:
>>> 
>>> md5 R-3.5.0.pkg
>>> MD5 (R-3.5.0.pkg) = 414029c9c9f706d3d04baa887ccffbc4
>>> 
>>> from the CLI on my Mac.
>>> 
>>> However, the SHA-1 hash on CRAN is:
>>> 
>>> SHA-hash: 9f5f3365afee54d3fe3148a60c1405955916f076 
>>> 
>>> and I get:
>>> 
>>> shasum R-3.5.0.pkg
>>> 6e90d38892bb366630ae30c223a898e8af84dff7  R-3.5.0.pkg
>>> 
>>> from the CLI on my Mac.
>>> 
>>> It would seem that there is a lingering issue with the generation of the 
>>> SHA-1 hash value on CRAN.
>>> 
>>> Thanks,
>>> 
>>> Marc Schwartz
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
> 
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] SHA-1 Hash for R-3.5.0.pkg Incorrect

[Marc Schwartz]

Hi Simon,

Thanks for the explanation.

It did not occur to me that SHA-0 was being used, since it was withdrawn as a 
standard circa early 90's, after significant flaws were identified.

Apple (and others) either have or are moving away from SHA-1 to SHA-2, at least 
for TLS/PKI security:

  https://support.apple.com/en-us/HT207459 


recognizing the differences between session specific TLS/PKI trust uses and 
longer term file integrity checking. I know Linus is more "relaxed" regarding 
SHA-1 and the implications for Git, or at least was last year, albeit 
indicating a path away from it in time.

I guess the question boils down to, if we are going to provide hashes of the 
files under the premise that it should offer a high level of comfort to useRs 
that the file has not been modified/replaced since generation, presuming that 
the published hash value itself was not altered, I would put forth for further 
discussion, moving to SHA-2 and away from both MD5 and SHA-1 (certainly moving 
away from SHA-0), depending upon a more broad assessment of the implications of 
doing so.

Thanks!

Marc


> On Apr 25, 2018, at 2:54 PM, Simon Urbanek  
> wrote:
> 
> Marc,
> 
> thanks, the issue is:
> 
> hagal:R-3.5.0$ openssl sha R-3.5.0-el-capitan-signed.pkg
> SHA(R-3.5.0-el-capitan-signed.pkg)= 9f5f3365afee54d3fe3148a60c1405955916f076
> 
> hagal:R-3.5.0$ openssl sha1 R-3.5.0-el-capitan-signed.pkg
> SHA1(R-3.5.0-el-capitan-signed.pkg)= 6e90d38892bb366630ae30c223a898e8af84dff7
> 
> so either we change the label to SHA (or SHA-0?) or change the checksum. In 
> the root we actually provide both, even if that may or may not be relevant. 
> For now I did the latter in the index.html.
> 
> Cheers,
> Simon
> 
> 
> 
> 
> 
>> On Apr 25, 2018, at 7:57 AM, Marc Schwartz  wrote:
>> 
>> Hi All,
>> 
>> Last month:
>> 
>> https://stat.ethz.ch/pipermail/r-sig-mac/2018-March/012691.html
>> 
>> there was a report that the SHA-1 hash of the R-3.4.4.pkg, as listed on 
>> CRAN, was not correct, even though the MD5 hash and the digital signature 
>> appeared to be correct.
>> 
>> The same phenomenon is the case with R-3.5.0.pkg.
>> 
>> The MD5 hash on CRAN is:
>> 
>> MD5-hash: 414029c9c9f706d3d04baa887ccffbc4 
>> 
>> and I get:
>> 
>> md5 R-3.5.0.pkg
>> MD5 (R-3.5.0.pkg) = 414029c9c9f706d3d04baa887ccffbc4
>> 
>> from the CLI on my Mac.
>> 
>> However, the SHA-1 hash on CRAN is:
>> 
>> SHA-hash: 9f5f3365afee54d3fe3148a60c1405955916f076 
>> 
>> and I get:
>> 
>> shasum R-3.5.0.pkg
>> 6e90d38892bb366630ae30c223a898e8af84dff7  R-3.5.0.pkg
>> 
>> from the CLI on my Mac.
>> 
>> It would seem that there is a lingering issue with the generation of the 
>> SHA-1 hash value on CRAN.
>> 
>> Thanks,
>> 
>> Marc Schwartz
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 


[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] R 3.5.0

[Roy Mendelssohn - NOAA Federal]

Hi Simon:

Perfect,  thank you for the info.  One of the reasons I was asking is in 
~/Library/R i have a umber of packages that in fact are in CRAN but what I have 
are the development versions.  Everything I have in /Library/Frameworks/R are 
the CRAN versions.  It is easier for me to do the ~/Library//R update myself 
through a script so I keep the development versions.

Mostly also thanks for all of your work on the Mac version.  Much appreciated.

-Roy

> On Apr 25, 2018, at 11:10 AM, Simon Urbanek  
> wrote:
> 
> Roy,
> 
> first, I'd recommend holding off with updating packages. Due to the number of 
> packages, updating all of them takes quite some time, so in order to use the 
> binaries that are built with the release version of R it will probably take 
> at least until tomorrow that they are propagated through the mirror network. 
> Hence you'll have to re-install them anyway if you do it now. 
> 
> That said, the "select packages from previous version" search function only 
> applies to the system library - the use library is not in scope. However, 
> where you install those packages is up to you depending on the selection in 
> the Package Installer - the two steps are separate in the GUI.
> 
> Cheers,
> Simon
> 
> 
> 
>> On Apr 25, 2018, at 11:26 AM, Roy Mendelssohn - NOAA Federal 
>>  wrote:
>> 
>> Hi All:
>> 
>> If I remember correctly how R release numbers work,  R 3.5.0 would mean best 
>> practice would be to re-install all packages,  is this correct?  The Mac 
>> version has had a mechanism that does helps automate this process,  but I 
>> have a few questions as to how this works.  Specifically:
>> 
>> 1.  In looking for packages to re-install, does it look just in the 
>> /LIbrary/Frameworks/R location for packages,  or does it look in 
>> ~/username/Library/R also?
>> 
>> 2.  If it does look at both locations,  does the re-install then put 
>> everything into  /LIbrary/Frameworks/R or is present location maintained?
>> 
>> I ask because I have a lot of packages in ~/username/Library/R and want to 
>> maintain things that way, so I want to be certain that I know what will 
>> happen fi I use the built-in mechanism.
>> 
>> Thanks,
>> 
>> -Roy
>> 
>> 
>> 
>> **
>> "The contents of this message do not reflect any position of the U.S. 
>> Government or NOAA."
>> **
>> Roy Mendelssohn
>> Supervisory Operations Research Analyst
>> NOAA/NMFS
>> Environmental Research Division
>> Southwest Fisheries Science Center
>> ***Note new street address***
>> 110 McAllister Way
>> Santa Cruz, CA 95060
>> Phone: (831)-420-3666
>> Fax: (831) 420-3980
>> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>> 
>> "Old age and treachery will overcome youth and skill."
>> "From those who have been given much, much will be expected" 
>> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
> 

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] R 3.5.0

[Simon Urbanek]

Roy,

first, I'd recommend holding off with updating packages. Due to the number of 
packages, updating all of them takes quite some time, so in order to use the 
binaries that are built with the release version of R it will probably take at 
least until tomorrow that they are propagated through the mirror network. Hence 
you'll have to re-install them anyway if you do it now. 

That said, the "select packages from previous version" search function only 
applies to the system library - the use library is not in scope. However, where 
you install those packages is up to you depending on the selection in the 
Package Installer - the two steps are separate in the GUI.

Cheers,
Simon



> On Apr 25, 2018, at 11:26 AM, Roy Mendelssohn - NOAA Federal 
>  wrote:
> 
> Hi All:
> 
> If I remember correctly how R release numbers work,  R 3.5.0 would mean best 
> practice would be to re-install all packages,  is this correct?  The Mac 
> version has had a mechanism that does helps automate this process,  but I 
> have a few questions as to how this works.  Specifically:
> 
> 1.  In looking for packages to re-install, does it look just in the 
> /LIbrary/Frameworks/R location for packages,  or does it look in 
> ~/username/Library/R also?
> 
> 2.  If it does look at both locations,  does the re-install then put 
> everything into  /LIbrary/Frameworks/R or is present location maintained?
> 
> I ask because I have a lot of packages in ~/username/Library/R and want to 
> maintain things that way, so I want to be certain that I know what will 
> happen fi I use the built-in mechanism.
> 
> Thanks,
> 
> -Roy
> 
> 
> 
> **
> "The contents of this message do not reflect any position of the U.S. 
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
> 
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected" 
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] R 3.5.0

[Roy Mendelssohn - NOAA Federal]

Hi All:

If I remember correctly how R release numbers work,  R 3.5.0 would mean best 
practice would be to re-install all packages,  is this correct?  The Mac 
version has had a mechanism that does helps automate this process,  but I have 
a few questions as to how this works.  Specifically:

1.  In looking for packages to re-install, does it look just in the 
/LIbrary/Frameworks/R location for packages,  or does it look in 
~/username/Library/R also?

2.  If it does look at both locations,  does the re-install then put everything 
into  /LIbrary/Frameworks/R or is present location maintained?

I ask because I have a lot of packages in ~/username/Library/R and want to 
maintain things that way, so I want to be certain that I know what will happen 
fi I use the built-in mechanism.

Thanks,

-Roy



**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] SHA-1 Hash for R-3.5.0.pkg Incorrect

[Marc Schwartz]

Hi All,

Last month:

  https://stat.ethz.ch/pipermail/r-sig-mac/2018-March/012691.html

there was a report that the SHA-1 hash of the R-3.4.4.pkg, as listed on CRAN, 
was not correct, even though the MD5 hash and the digital signature appeared to 
be correct.

The same phenomenon is the case with R-3.5.0.pkg.

The MD5 hash on CRAN is:

MD5-hash: 414029c9c9f706d3d04baa887ccffbc4 

and I get:

md5 R-3.5.0.pkg
MD5 (R-3.5.0.pkg) = 414029c9c9f706d3d04baa887ccffbc4

from the CLI on my Mac.

However, the SHA-1 hash on CRAN is:

SHA-hash: 9f5f3365afee54d3fe3148a60c1405955916f076 

and I get:

shasum R-3.5.0.pkg
6e90d38892bb366630ae30c223a898e8af84dff7  R-3.5.0.pkg

from the CLI on my Mac.

It would seem that there is a lingering issue with the generation of the SHA-1 
hash value on CRAN.

Thanks,

Marc Schwartz

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac