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.ooms at 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
Support for signing R packages with GPG
3 messages · Jeroen Ooms, Bob Rudis, Martyn Plummer
I suspected/hoped this was one reason for the new pkg ;-) I'm *100% in support of this* and will help as much as I can. I can see if my org (Rapid7) would be willing to be a trusted peer (given my position it's prbly more like "we will be doing this" vs an ask). Sonatype may also be willing to be one (I have contacts there). I might be able to convince Veracode, too. Given Microsoft's reliance on R, they might be willing to be one and I suspect TIBCO, Mango and other Consortium companies would gain some solid PR benefit & community good will from being trusted peers. With a similar purpose of integrity validation (not necessarily gpg-related), I've been contemplating a rationale write-up and PR for `base::source()` & `base::sys.source()` to support some type of signature verification parameter option (with a default warning issued when `source()` is used w/o the signature and a corresponding option string to mute the warnings. `devtools::source_gist()` ?well, really `devtools::source_url()` (which ultimately calls `base::source()`) would benefit from the check being in `base::source()` but I've been contemplating PR'ing a warning into them vs the easily ignorable message that is printed when no hash is provided. Neither may be accepted (and, yes, the `devtools` functions do have Description text which try to emphasize the need for integrity validation) but an explicit warning would (IMO) be a good way to really get folks to think start to think about security issues. Finally, it would also be nice to see RStudio team take advantage of this new gpg pkg to enable generation of PGP keys and signing of git commits. I'm personally at fault for not manually committing RStudio projects with `-S` since the GUI makes it way too easy to avoid going to the command-line. The Labs team at work is in the process of making signing mandatory for private prod repos, so there's some shameless personal benefit to this request ;-)
On Sun, Oct 23, 2016 at 12:37 PM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> 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.ooms at 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
2 days later
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.ooms at 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}