Support for signing R packages with GPG

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Support for signing R packages with GPG

Jeroen Ooms.
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=[hidden email]

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
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for signing R packages with GPG

Bob Rudis
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 <[hidden email]> 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=[hidden email]
>
> 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
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for signing R packages with GPG

Martyn Plummer-3
In reply to this post by Jeroen Ooms.
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=[hidden email]
>
> 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
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for signing R packages with GPG

Jeroen Ooms.
On Tue, Oct 25, 2016 at 7:22 PM, Martyn Plummer <[hidden email]> 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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel