Skip to content

SHA-1 Hash for R-3.5.0.pkg Incorrect

6 messages · Simon Urbanek, Peter Dalgaard, Marc Schwartz

Original
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
Simon Urbanek
# 
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
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 <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

  
  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

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

-pd

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Marc,

no, the hashes merely a legacy to check that you don't have a corrupted download. They are neither intended nor used for validation. To verify the validity you should use the signature check.

Cheers,
Simon

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
Hi Simon,

Understood, as the digital signature is superior to the stand alone hash value, since like the hash value, it provides a check against file modifications/corruption since being signed, and unlike the stand alone hash value, it provides source validation and non-repudiation.

In either case, I see that you have now changed the labeling of the SHA hash on CRAN, to indicate that it is SHA-1 specifically, and that hash value now checks locally. Thank you for making that change.

I wonder if it might make sense, given that the signature is superior to the stand alone hash values, to begin to drop the latter for signed PKG files intended for ongoing (non-legacy) binary versions of R for macOS, for the reasons below.

If so, it might make sense to also move in the same direction for the signed PKG files in the macOS tools folder on CRAN, which now just have the MD5 hash values.

Thanks again Simon.

Marc