s-u / rsclient

Rserve client for R

RSclient

R-based client to Rserve

This R package provides a client for Rserve. It started as a simple proof of concept (the RSxx functions which bypass Rserve serialization), but was later re-written in C for high efficiency, full SSL/TLS and QAP support (the RS.xx functions).

It supports Rserve both in regular as well as in OCAP mode. The code could be used as a basis for C-level Rserve client if required.

To install the CRAN version, use simply

install.packages("RSclient")

For installation of the latest development version, use

install.packages("RSclient", repo="https://rforge.net")

but note that you will require OpenSSL library and headers.

rsclient's Issues

TLS code is not robust against SSL_ERROR_WANT_READ retry

Read operations on in SSL/TLS can return a retriable error SSL_ERROR_WANT_READ in which case the read operation should be repeated. The current implementation will fail with rsc_abort and treat it as read error, which it shouldn't.

Currently, it's possible to reproduce using RS.authkey() on a TLS connection since it takes some time for the server to generate a key.

no SSL certificate verify

Hi developers:
Nowadays we made a large scale security static analysis on several open source projects, and found some mistakes in r-cran-rsclient_0.7-3. In the @src/cli.c:146:
static int tls_upgrade(rsconn_t *c) {
SSL *ssl;
SSL_CTX ctx;
if (first_tls)
init_tls();
ctx = SSL_CTX_new(SSLv23_client_method());
SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY);
c->tls = ssl = SSL_new(ctx);
c->send = tls_send;
c->recv = tls_recv;
SSL_set_fd(ssl, c->s);
/ SSL_CTX_free(ctx) // check whether this is safe - it should be since ssl has the reference ... */
return SSL_connect(ssl);
}

When finish the SSL connect, you immedicately start to execute read/write operation without verify certificate,which can lead to MITM attack and cause leakage of sensitive data.We recommand you add verify operation such as SSL_CTX_set_verify or SSL_get_peer_certificate to guarantee the security.We have send the bug report to Ubuntu launchpad,and also inform you of such news.Here are the link:

https://bugs.launchpad.net/ubuntu/+source/r-cran-rsclient/+bug/1677493

Dead link to rosuda.org

See also this issue in Rserve. The link in this documentation file returns a 404 error.

Missing -lcrypto

rsclient directly uses libcrypto symbols, such as ERR_get_error, but does not link directly against libcrypto. The symbols "probably always" get resolved at runtime via R itself that has already loaded libcrypto, but it's fragile to rely on others' linking to resolve one's own symbol use. It would be safer to have rsclient's Makevars pass -lcrypto (as well as the existing -lssl).

Vectorized RS.* wrappers

I've made few wrappers on RS.* which accept list of rsc (referred later as rscl).
Usually it is only something like rscl.* = function(...) sapply(rscl, RS.*, ...).
Additionally there are some predefined defaults for arguments. Some other minor adjustments, like rscl.collect uses try() by default, to not interrupt collection from all Rserve machines after first error.

There are some extra wrappers:
rscl.require - require multiple packages on multiple nodes at once.
rscl.ls.str - capture output of ls.str(envir=.GlobalEnv) from multiple nodes and prints locally

All my codes related to RSclient wrappers can be found in rscl.R. Should not have any other dependency.

Are you interested in contribution? so such utilities would be part of RSclient, or you prefer to keep RSclient as a simple core interface and let user to write their wrappers.
Example use case of rscl.*: http://stackoverflow.com/a/35066323/2490497

Edit: just added parallel arg to rscl.eval so it can also auto collect results after sending with wait=FALSE.