141–150 of 269 posts
Or did the get access to a partition of the user data? How is this even possible?
Some very old backup that had only 5% of earliest users?
Some log file which had plain-text creds of approx 5% users?
Or did they discover the attack as it was happening and kicked-out the attacker in the middle of a data download (only 5% complete)?
Official Article from Docker (Same Text as the email): https://success.docker.com/article/docker-hub-user-notificat...
Earlier quoted context omitted.
Both situations are bad, and people are upset over Docker Hub. It just happens to be Friday night so it's not getting as much attention. NPM is bad because the Javascript ecosystem is fast-moving with loose builds that have thousands of dependencies that are all bundled and run insider consumer's browsers.
I never complained and whined like a baby every time I install Gnome for example, using Debian's apt package manager where it fetches hundreds of packages worth of 1GB. Do you know how many Linux devs required you to use Lua libraries for example only for a single isolated piece of code just because they were too lazy to write it down in C.
It'd be a legit criticism of ruby gems or CPAN, but linux distros are an entirely different kettle of fish, and most of the mainstream distros take security pretty seriously
Why can’t these emails just come out and say it: “your account was affected”. It’s always implicit. Also, why rely on users to change their passwords? Is there a security log I can check?
Earlier quoted context omitted.
How could one verify ?
You can't. Not without end-to-end integrity with nonrepudiation. Checksums aren't anywhere near enough. But that's Docker.. security optional and run random, untrusted code from the internet.
And even if you hosted your own distribution and notary (like we now do for openSUSE and SUSE), you can't force Docker to check the signatures of all images from that server!
Only docker.io/library/* has enforced image signing and the only other option is to globally enforce image signing which means "docker build" will result in unusable images out-of-the-box.
If you look at something like OBS (the Open Build Service that openSUSE and SUSE use to provide packages as well as host user repos), the signing story is far better (and OBS was written a very long time ago). All packages are signed without exception, and each project gets it's own key that is managed and rotated by OBS. zypper will scream very loudly if you try to install a package that is unsigned or the key for a repo changes without the corresponding rollover setup. And keys are associated with projects so a valid rpm from a different project will also produce a warning and resolution prompt. That's how the Docker Hub should've been designed from the start.
(Disclaimer: I work for SUSE, on containers funnily enough.)
Earlier quoted context omitted.
I'd like to mention that Docker recently changed their automated builds to require giving them access to GitHub instead of just using a webhook. Glad I disabled access but no telling how long this was undiscovered.
Interesting. What’s their rationale?
If the passwords are hashed, just what are the likelihood of your passwords being decrypted? I’d also imagine it is a one way hash since that’s typically the norm so I don’t even know how it can get decrypted.
Hashes are not decrypted, they are bruteforced. > I imagine it is a one way hash All hashes are one way. If it's lossless and can be reverted, it's a compression algorithm or isomorphism or encryption or cipher or any of a number of other things, but not a hash. > I don’t even know how it can get decrypted. It is not decrypted, but brute forced. For example, even if you can't algorithmically figure out what the input…
Earlier quoted context omitted.
> Docker weakens trust because it lets anonymous people ... upload images that can be immediately run... but without a proper chain-of-custody, QA or assurance that an image hasn't been manipulated How is this github any different?
Many package managers that support git as source allow to pin to a specific commit sha. That's as far as I can see a quite secure way to keep using an uncompromised/verified version. It's not the most popular feature but people do it every now and then, probably it should be done more. I wonder if docker allows this and on the other hand if that's even feasible for say application images, given that applications must…
docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2