-
Notifications
You must be signed in to change notification settings - Fork 2k
Deprecate unencrypted storage #561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm missing it, but you should also mark it as deprecated in Cobra. @thaJeztah can you give guidance on where and how to do this?
cli/config/credentials/file_store.go
Outdated
| // FileStore implements a credentials store using | ||
| // the docker configuration file to keep the credentials in plain text. | ||
| type fileStore struct { | ||
| type FileStore struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of exporting this (something we want to deprecate) how about adding a new IsNotSecure() method to fileStore, and creating the interface in cli/command/registry/login.go to check it?
type notSecure interface {
IsNotSecure() bool
}
if _, isNotSecure := creds.(notSecure); isNotSecure {
...
}There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this, but as it stands there are two backends: fileStore and nativeStore, which is what implements the docker credential helpers interface. You could imagine a credential helper that just wrote plain text to a file, which would not be secure, but writing "!isNotSecure" seems to imply that the backend is secure, when it's not: nativeStore can't vouch for what's on the other end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, then how about IsDeprecated() and type deprecated interface{...} ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this too, but in the event that we don't deprecate this based on discussion, I think we should still merge this patch, but tagging it as deprecated would be incorrect. We could cast by GetFilename, since that is unique to the FileStore, but it doesn't really describe what we're trying to detect. So I dunno :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to pick some other interface, my concern is just that it doesn't make sense to export this entire struct if all we need is some way detect that it is of this type.
Another option is to export an IsFileStore(). That way we're only exporting one function and not the entire struct.
cli/command/registry/login.go
Outdated
| // logins and we don't want to break them. Maybe they'll see | ||
| // the warning in their logs and fix things. If it is | ||
| // interactive, let's ask them if they really want to do this. | ||
| if dockerCli.In().IsTerminal() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please extract the entire confirmation block into a new function so the comment can be a godoc string instead of inline comment.
cli/command/registry/login.go
Outdated
| for { | ||
|
|
||
| fmt.Fprintf(dockerCli.Err(), "Do you want to continue? (yes/no): ") | ||
| choice, _, err := bufio.NewReader(dockerCli.In()).ReadLine() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use PromptForConfirmation https://github.com/docker/cli/blob/master/cli/command/utils.go#L67-L72
|
@mstanleyjones I don't think this is related to a specific flag, so I don't know if there is anywhere in cobra to deprecate it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docs LGTM
|
FYI This is in design review phase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design LGTM
cli/command/registry/login.go
Outdated
| const unencryptedWarning = `WARNING! Your password will be stored unencrypted in %s. | ||
| Please configure a credential helper (see | ||
| https://docs.docker.com/engine/reference/commandline/login/#credentials-store) | ||
| to avoid this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about:
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Better without the "please"
docs/deprecated.md
Outdated
|
|
||
| Docker before v17.10 stored user credentials in `~/.docker/config.json` | ||
| unencrypted by default. As of v17.10 it prints a warning with a link to the | ||
| credentials helper page and asks users if they want to continue. Eventually, we |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd skip the niceties and just, e.g.: "Support for unencrypted password storage will be removed in Docker 18.10."
docs/deprecated.md
Outdated
|
|
||
| **Deprecated In Release: v17.10.0** | ||
|
|
||
| **Target For Removal In Release: v18.10** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this will be well received. As @cpuguy83 mentioned it, what about CI ? Same for any other situation where there is no secure alternative (pass, ...) and that it is run as a script (no tty)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. Warning about it being insecure is good, but I don't think we should actually set a target for removal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reasonable questions. I'm not sure what the threat model is here, I guess it must be people concerned about folks outside their organization reading their images off the docker (or other publicly accessible) hub? It seems that anyone who can commit code to the thing in CI can read out these passwords if they're stored in plaintext, so it can't be about internal threats.
If that's the model, perhaps we can do something a-la Google's app-specific passwords (which we could implement before deprecating this)? If it's not, then this is broken and we should in fact remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so after some discussions with @n4ss, it seems that this is exactly what people are doing. So without some reasonable replacement for this, we can't deprecate this bit. So, I'll just drop the second patch from this PR, and leave it with the big warning patch.
1d400f7 to
341de19
Compare
Codecov Report
@@ Coverage Diff @@
## master #561 +/- ##
=========================================
Coverage ? 49.47%
=========================================
Files ? 208
Lines ? 17159
Branches ? 0
=========================================
Hits ? 8490
Misses ? 8237
Partials ? 432 |
d71c206 to
bbcc7cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🐯
I'll rebase/fix conflict 👼
bbcc7cf to
da265c3
Compare
Signed-off-by: Tycho Andersen <tycho@docker.com>
da265c3 to
4290df3
Compare
|
@gbarr01 wondering if we should have special URLs that we can use when referring to the docs from the command-line. I know some URLs may move, and can become outdated; should we have (e.g.) docs URLs that redirect to where we want them? like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@thaJeztah, sure thing. To confirm, the benefit here that the developer can always use the same base URL ( |
|
@gbarr01 almost, yes; we could use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, we can have a look at better URLs later

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

This is an implementation of #559.
cc @n4ss @thaJeztah @vdemeester @dnephin @vieux @tiborvass @cpuguy83