On Fri, Oct 14, 2016, at 02:37 PM, Daniel J Walsh wrote: > If we block the creation of the devices when exploding a OCI Image > Bundle, we end up with something that is different then what is > downloaded and this could potentially cause problems with mtree checking > of the image on disk versus the image as shipped.
https://github.com/ostreedev/ostree/pull/443 would be a good place to discuss this. > Is there a reason OSTree does not work with Device Inodes? Yes, I think there's no good reason to include devices in OS or container images. For OS images (i.e. ostree-as-base), all modern systems use devtmpfs. (Also for that matter, a bit more strictly, FIFOs either. OSTree very intentionally only supports regular files and symlinks) For the Ubuntu Docker image, the user can't even see them because Docker (correctly) mounts over /dev/ with the "API devices" as systemd calls them. So basically...my proposal would be that we ignore them, and that's indeed what the proposed OSTree API above does. If we implement any other verification layer like mtree, it should then just skip devices and FIFOs (or more generally anything except regular files and symlinks).