- Change your password on https://hub.docker.com
- Check https://github.com/settings/security
- Reconnect oauth for Automated Builds
- Roll over effected passwords and API keys stored in private repos / containers
- Password hashes
- Github tokens
- Bitbucket tokens
- Your Automated Builds might need new tokens
Checking my github logs - It looks like they've known about this for at least a full 24 hours. Most people aren't going to have this looked at until Monday which kind of sucks. Hopefully there is more of a postmortem coming.
Is anyone from github able to comment on this as well?
There doesn't seem to be a way for us to tell if a repo was read by these keys over that time period.
The following SSH key was added to the foo/bar repository
Docker Cloud Build
If you believe this key was added in error, you can
remove the key and disable access...
It seems like Docker Hub is implemented as an OAuth app , where these granular options are not available and you have to grant access to all your repositories.
honest question, what's the point of using OAuth when the Authz is so coarse? Why not augment to have scopes per repo? Is it considered bad practice to have have a variable (repo name) as a scope?
> Service user (or machine/bot account) suggested
> Attaching your personal GitHub or Bitbucket account to this Docker Hub organization will allow other organization owners to create builds from your private repositories. We suggest using a service user (also referred to as a machine user or bot account).
Seems worthwhile to do this, if you're an enterprise or otherwise have sensitive private repos. But I agree that it would be better to have an easier per-repo authorization system, since many users won't bother going through the hassle of setting up a service account.
> c.f.: https://docs.docker.com/docker-cloud/builds/automated-build/....
Did they remove this language from your link? I don't see it anymore.
Also not sure what access permissions you need but deploy keys are repo level.
Machine users are another option.
- retrieve a list of all repos to display in the autobuild setup page
- setup webhooks for the gh repo that should be built via dockerhub autobuild
- setup a deploy key for said repo, so that it can be cloned
I removed the dockerhub oauth on github side, after setting up autobuild. My builds on push to master and tag are still working. So it seems possible to remove dockerhubs write access to your github repos after the autobuild setup, which really seems to be a good idea.
EDIT: it finally worked, 4th attempt, and very slowly. Looks like something isn't working 100% as it should
EDIT 2: aaaand I can't login now with the new password. A password reset did work, but it looks like their password database is under some stress at the moment.
Specifically to make the password database more secure, the generation of password hashes is very computationally intensive by design (e.g. that's the whole point of something like bcrypt vs. sha1)
Password systems really shouldn't be designed to handle a 10x or 100x load without some slowdown. If they could handle that, it means their password DB probably isn't as hardened as it should be.