Thanks Jeroen. The R Foundation has recently formed a working group to
look into package authentication. There are basically two models. One
is the GPG based model you describe; the other is to use X.509 as
implemented in the PKI package. It's not yet clear which way to go but
we are thinking about it.
Martyn
On Sun, 2016-10-23 at 18:37 +0200, Jeroen Ooms wrote:
> I would like to propose adding experimental support for including a
> PGP signature in R source packages. This would make it possible to
> verify the identity of the package author and integrity of the
> package
> sources.
>
> There are two ways to implement this. Assuming GnuPG is on the PATH,
> the CMD build script could call:
>
> gpg --clearsign MD5 -o MD5.gpg
>
> Alternatively the 'gpg' R package provides a more portable method via
> the gpgme C library. This method works on Windows / macOS as well.
>
> writeLines(gpg::gpg_sign("MD5"), "MD5.gpg")
>
> Attached is an example implementation of the latter (also available
> at
> https://git.io/vPb9G) which has been tested with several versions of
> GnuPG. It exposes an optional flag for CMD build, i.e:
>
> R CMD build somepkg --sign
> R CMD build somepkg --sign=jeroen.o...@stat.ucla.edu
>
> The --sign flag creates a signature for the MD5 file [1] in the
> source
> package and saves it as MD5.gpg (similar to a Debian 'Release.gpg'
> file [2]). Obviously the package author or build server needs to have
> a suitable private key in the local keyring.
>
>
> ## Signature verification
>
> Once R supports signed packages, we can develop a system to take
> advantage of such signatures. The verification itself can easily be
> implemented via 'gpg --verify' or via gpg::gpg_verify() and could be
> performed without changes in R itself. The difficult part in GPG
> comes
> from defining which peers should be trusted.
>
> But even without a 'web of trust' there are several ways one can
> immediately take advantage of signatures. For example, when a
> installing a package update or dev-version of a package, we can
> verify
> that the signature of the update matches that of the currently
> installed package. This would prevent the type of attacks where an
> intermediate party pushes a fake malicious update for a popular R
> package via e.g. a hacked CRAN mirror.
>
> Eventually, CRAN could consider allowing signatures as a secure
> alternative to confirmation emails, and signing packages on the build
> servers with a CRAN GPG key, similar to Debian repositories. For now,
> at least establishing a format for (optionally) signing packages
> would
> be a great first step.
>
>
> [1] Eventually we should add SHA256 and SHA256.sig in addition to MD5
> [2] https://cran.r-project.org/web/packages/gpg/vignettes/intro.html#
> debian_example
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
