-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential security issue in ESSR #429
Comments
This is high priority. We really need to do something about it. That probably means shipping a tar.gz with the distribution. |
Can we not just switch from http: to https: ? |
Ok. I have done that. There was a reason why it's fetched from a remote. Back then I couldn't find a satisfactory solution for the file transfer, but things might have changed. |
Out of interest, why pull a binary from a personal server containing an R environment, containing a single R function? Why not just include that function as part of ESS? (This behavior has spooked me a little.) |
It contains quite a bit more than one function. I think the right approach would be to send the archive through TRAMP. Current situation is clearly unsatisfactory. |
Instead of downloading ESSR.rda from a website, we'll transfer it from the local machine to the remote machine. This will probably be faster anyway if the two computers are on the same network. Closes emacs-ess#429
Instead of downloading ESSR.rda from a website, we'll transfer it from the local machine to the remote machine. This will probably be faster anyway if the two computers are on the same network. Closes emacs-ess#429
Hi!
While using ESS remotely (which worked great), I noticed that ESS instructs the remote server to load and execute a .rda file from a 3rd party server over HTTP (see
etc/ESSR/LOADREMOTE
) Since this file can contain arbitrary code, this could be an issue. Would it be possible to either load the .rda from a more secure address (e.g. https://raw.github...), or even better, just send the R source code over ssh? On my machine it takes <100 ms to parse, and I think this would increase reliability too, for example in cases where the remote server is behind a firewall.The text was updated successfully, but these errors were encountered: