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
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
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}}
On Tue, Oct 25, 2016 at 7:22 PM, Martyn Plummer <plummerm at iarc.fr> wrote:> 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.I look forward to hearing what the working group comes up with. I suppose if you go with x509, CRAN is going to perform CA duties? Let me know if I can help with implementation, either via gpg or x509. I am actively developing the openssl package which includes many more x509 utilities, supporting all common key types (dsa, rsa, ec), certificate bundles, ssl, etc. The main difference with PKI is that openssl uses the native pem/der parsers from libssl which are more robust and also recognize the less common formats, so that we don't have to deal with parsing/decoding ASN.1 in R. I will be happy to adapt/extend it further to fit the needs of the workgroup and help this move forward.