It confuses me why they wouldn't just verify the images since they have the signature in the manifest. Is this because they don't want to wait for a complete image before the start streaming through the pipeline? Is this actually a significant time saver?
The entire model looks to me like it never had even the most superficial security analysis done. It's like a smorgasbord of insecure decisions:
* the false sense of security from putting signatures in the manifests then ignoring them
* loading signing certs via the network with no provision for pinning
* happily loading untrusted/unsigned images by default (npm, rubygems, installtools, etc. also do this but why repeat their awful design mistake?)
* running basically everything as root (because why deal with all those messy permissions?)
My sysadmin Spidey-sense has been tingling at the rate of change in the Docker ecosystem since it went from "interesting POC" to "we think it's production ready" in a shockingly short period of time. Things like this sadly confirm that initial pessimistic view.
Not at all related to docker, but this sort of thing is what makes me happy about communities like Rust. They are taking an incredibly long time to get to 1.0, but they've been progressing methodically and consistently and are trying to get something good out the door instead of bowing to any pressure to release early. Of course, Mozilla is a different beast compared to Docker, Inc., there is less of a profit motive more so than a need to create a revenue stream to stay maintainable and keep creating good new tech.
Things like this are really putting everything that is happening with Rocket and the drama around it in perspective.
If this is the case, it would seem pretty insulting to me as a developer and user of Docker that "time-saving" is more important that security and validating images. I'd rather use a slower tool that is secure.
Yes that makes sense, as tar is not fully deterministic, so untar and retar might give a different checksum on the same files (eg ordering). However it is generally better to keep the same bits people signed regardless.
Maybe you could use the Git packfile format; this is a self-contained compressed Merkle-tree. If you ever need to reconstruct deterministically the tar from that, you can use something like pristine-tar[0].
Sure, but it's not a post about the bestest solution. It's a post about how using more advanced math can ("can" not "will") lead to a worse solution for your context. Fibonacci numbers in a long int is certainly a toy example; but it's a toy example that had an actual reference.
I reread the article with that in mind, and it makes much more sense, to the point that I am inclined to agree with much of what you said now. I think you should highlight that difference closer to the beginning of the article. That is a nice, subtle play on words.
how much emphasis to give to which messages is always the hardest part for me to writing these posts. I'll keep in mind that at times I can be too subtle.
Twitter has a PIN code feature that requires every message to be prepended with a four-digit alphanumeric code. This feature mitigates the issue, but is not available to users inside the United States.
So they fixed the problem... but are withholding the fix from tons of users?
