[Rd] Package integrity check via SHA256 or OpenPGP possible?

Simon Urbanek simon.urbanek at r-project.org
Thu Oct 15 16:52:41 CEST 2015


FWIW PKI supports signing and verification of tar balls based on X.509 (PKI.sign.tar/PKI.verify.tar) - the aim was to specifically support signing of packages so we could have infrastructure akin to the Apple developer code signing where the repository would be the CA (e.g., CRAN, RForge.net, etc.). Obviously, it's just one approach, but at least it is already implemented.

This is getting OT as others have pointed out since the purpose of the hashes is an integrity check, not security, but I absolutely agree that it would be nice to have some kind of signing to validate the source of packages (=verifiable authorship).

Cheers,
Simon


> On Oct 15, 2015, at 9:51 AM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote:
> 
> On Thu, Oct 15, 2015 at 9:11 AM, Philip Gillißen <guerda at freenet.de> wrote:
>> I'm using R in a corporate environment...
> 
> That's irrelevant.
> 
>> is possible to force R to verify integrity via SHA256 or even OpenPGP signatures? If not are there any plans to support better hashes than MD5? As the source code looks, an extension to support other (optional) hash values would be quite easy.
> 
> A hash is not the same thing as a signature. If you need an
> introduction to these topics I recommend www.crypto101.io.
> 
> Adding sha256 support would indeed be easy but we wouldn't gain much.
> Coincidental md5 collisions are very unlikely. If you are considering
> deliberate attacks on the network, a hash function is not going to
> help as the attacker can just recompute the hash along with the
> tampered package.
> 
> Also note that if you are using an https mirror, the connection
> between you and the mirror should be secure. But of course it is still
> possible that a mirror server itself gets hacked.
> 
> Now, signing packages with a private key would be useful against such
> attacks, but require quite a bit of work. If we would follow the
> Debian model, it would require that:
> 
> - Each of the PACKAGES files in the repository gains a secure hash
> (e.g. sha256) for each file in the directory.
> - A "Release" file [1] is added to the repository that includes a
> secure hash of each of the PACKAGES files.
> - A "Release.gpg" file [2] or equivalent is added which contains a
> signature of the "Release" file.
> - Each time "PACKAGES" and hence "Release" files are updated, the
> repository maintainers need to update "Release.gpg" by signing
> "Release" with their private key.
> - R installations would have to ship with the corresponding public
> key in order to verify the signature in Release.gpg before installing
> packages.
> - All of this would have to be implemented using a crypto library
> capable of public key signatures.
> - A policy is designed for rotating keys when they expire, or between
> R releases, or when one gets compromised, etc.
> 
> I have actually been looking into this over the past few months. On
> Linux it would be doable with gpg, but unfortunately gpg does not work
> very well on OSX and Windows, which make it impractical for R.
> 
> There are a few alternatives that are more portable. The PKI package
> uses openssl to do RSA signatures, which could work. The new 'sodium'
> package is probably the most advanced thing currently available. It
> uses the ed25519 public-key signature system with a very simple API.
> See the manual page for the 'sig_sign' and 'sig_verify' functions.
> 
> Either way, all this would require a substantial amount of work and
> additional ongoing maintenance in both R and CRAN, which is unlikely
> to happen given the limited resources.
> 
> 
> [1] http://http.us.debian.org/debian/dists/jessie/Release
> [2] http://http.us.debian.org/debian/dists/jessie/Release.gpg
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list