search

nuest / ten-simple-rules-dockerfiles

Ten Simple Rules for Writing Dockerfiles for Reproducible Data Science
https://doi.org/10.1371/journal.pcbi.1008316
Creative Commons Attribution 4.0 International
64 stars 15 forks source link

"maintained by the Docker library" #30

Closed psychemedia closed 4 years ago

psychemedia commented 4 years ago

https://github.com/nuest/ten-simple-rules-dockerfiles/blob/4a87e3e3ad43feacd98722f1521e500191bb17bb/ten-simple-rules-dockerfiles.Rmd#L115

Docker Hub is a free for all. There are official images, identified by a_ in place of the repository name, built from Dockerfiles written according to best practices, which also benefit from things like vulnerability scanning.

(Official Dockerfiles, like conda recipes, ca be great things to crib from when trying to build something similar yourself.)

There are also repositories that are maintained by organisations for their own "official" containers. Note that when it comes to using trusted sources, there are also opportunities for associated maliciousness (example: Two malicious Python libraries caught stealing SSH and GPG keys.)

(By the by, I notice that Github is now warning me of, and automatically updating vulnerabilities in my repos (maybe I opted in to something?!) , an example of the repository environment modifying my repos in a way that may be helpful in terms of security, at least, but that may actually break something in the thing I'm trying to build.)

vsoch commented 4 years ago

For libraries, +1. For custom (user) containers, Docker has account tokens but still you cannot create robot tokens (which custom permissions for some repo). For this reason, and for getting security scanning, I have been using Quay.io instead.

GitHub acquired two companies (Semmle being one of them) to allow for security scanning and then automated PRs to fix them. I think this is hugely beneficial, and (imho) the maintainer should have suitable tests for the PR to ensure that nothing breaks.