The esteemed Ildi Czeller & I are slated for a community call in May (2019-05-07 1100 PDT) on “security”. The fist half will be Ildi showing off her AMAZING work on the ropsec package (she’s been an unstoppable force on it). The other half of the topic is currently a big amorphous blob (obviously my half, to wit you’re likely saying to yourselves “What was Stef thinking??!”).
I can literally talk for 12 hours straight on security topics, but we only have like 20m for my part tho.
So I either talk super fast and cram 12 hrs into 20m OR…what do you want to know about. What should I blather on and on and on and on about?
Given the forum it should be #rstats-related, but apart from that I’m open to anything.
I’ll give this topic a bump up in April and then right before the call.
I was hoping for was something like “How and in what contexts should I use packages such as secret, keyring, sodium, and cyphr?” For instance, I use sodium and cyphr to encrypt a token file for use in a CI pipeline to upload results to Dropbox, with the key saved in base64 as an environment variable. It seems to work, but I’m not sure if this one-key approach is best practice for something like this. A mapping of various packages to use-cases would be helpful.
I recognize that’s probably not a helpful attitude to have, but I honestly don’t know where to start. Should I teach students to use the new credentials package? Should I mention 2FA when I talk about GitHub? Should I comment on the use of SSH vs HTTPS? Should I say anything about encryption with regards to private data, or PL1-sensitive data? How do I do better than my current ostrich approach without sticking my foot in my mouth?
Would love to hear thoughts on package management and the security of the supply chain. What kind of setup would you advise for a security-conscious enterprise that also wants to maintain a fair amount of analyst flexibility? What lessons can we learn from other languages about trying to make it easier to secure the ecosystem?
“Security” can be a daunting, scary, and (frankly) quite often a very boring topic. BUT!, we promise that this Community Call on May 7th will be informative, engaging, and enlightening (or, at least not boring)!
Applying security best practices is essential not only for developers or sensitive data storage but also for the everyday R user installing R packages, contributing to open source, working with APIs or remote servers. However, keeping up-to-date with security best practices and applying them meticulously requires significant effort and is difficult without expert knowledge. On this Call you’ll hear about how the ropsec package can help you and you’ll learn the inner secrets of maintaining confidentiality, integrity, and availability throughout all your data science workflows.
Thanks for organising this! I’m interested in how to screen R packages before using them - what steps can we take to protect ourselves against malicious secrets hiding inside these bundles of joy?
https://github.com/ropenscilabs/defender is another “kinda-in-progress” pkg to help with that. it does some checks for not-so-safe practices in R code (I think this was in the link dump but just in case I wanted to point it out).
Is it “kinda-in-progress” as in “almost done” or “not really being worked on”? I’m only curious so that I can convey expected changes to my InfoSec department. 0% judgment to the package maintainers!
@hrbrmstr I think you’ve also written somewhere about CRAN’s code-practice scanning?
