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.o...@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.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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
